From ietf@meetecho.com  Wed Aug  1 00:06:46 2012
Return-Path: <ietf@meetecho.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDEE21F853C for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 00:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.317
X-Spam-Level: 
X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.402,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-Q5ZmhRD4K5 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 00:06:44 -0700 (PDT)
Received: from smtplq02.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 244D721F8510 for <mmusic@ietf.org>; Wed,  1 Aug 2012 00:06:43 -0700 (PDT)
Received: (qmail 31282 invoked by uid 89); 1 Aug 2012 07:06:41 -0000
Received: from unknown (HELO smtp6.aruba.it) (62.149.158.226) by smtplq02.aruba.it with SMTP; 1 Aug 2012 07:06:41 -0000
Received: (qmail 17336 invoked by uid 89); 1 Aug 2012 07:06:41 -0000
Received: from unknown (HELO ?172.16.0.193?) (alex@meetecho.com@209.82.28.249) by smtp6.ad.aruba.it with ESMTPA; 1 Aug 2012 07:06:40 -0000
Message-ID: <5018D57D.2090804@meetecho.com>
Date: Wed, 01 Aug 2012 09:06:37 +0200
From: Meetecho IETF support <ietf@meetecho.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N
Subject: [MMUSIC] Meetecho support for MMUSIC WG
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 07:06:46 -0000

Hi all,

a virtual room has been reserved on the Meetecho system for Wednesday's
MMUSIC WG meeting session.

Access to the on-line session (including audio and video streams) will
be available at:
http://www.meetecho.com/ietf84/mmusic

The Meetecho session automatically logs you into the standard IETF
jabber room. So, from there, you can have an integrated experience
involving all media and allowing you to interact with the room.
Remote participants might also send their own voice to the room, if they
want to, by either calling a landline phone number, or using our
embedded VoIP applet (in this last case they are *strongly* advised to
use a headset).

A tutorial of interactivity features of the tool can be found at:
http://www.meetecho.com/ietf84

Cheers,
the Meetecho team

-- 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

From kyunghun.jung@samsung.com  Wed Aug  1 01:47:41 2012
Return-Path: <kyunghun.jung@samsung.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6364321F86BD for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 01:47:41 -0700 (PDT)
X-Quarantine-ID: <gHTXhmV-AJnd>
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.05
X-Spam-Level: 
X-Spam-Status: No, score=-2.05 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, MSGID_FROM_MTA_HEADER=0.803, 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 gHTXhmV-AJnd for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 01:47:40 -0700 (PDT)
Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1E21F8699 for <mmusic@ietf.org>; Wed,  1 Aug 2012 01:47:39 -0700 (PDT)
Received: from epcpsbge3.samsung.com (mailout4.samsung.com [203.254.224.34]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0M82003T9J1ZV1I0@mailout4.samsung.com> for mmusic@ietf.org; Wed, 01 Aug 2012 17:47:37 +0900 (KST)
Message-id: <0M82003UQJ3DV1I0@mailout4.samsung.com>
X-AuditID: cbfee60d-b7f4f6d000006353-32-5018ed299f08
Received: from epextmailer01 ( [203.254.219.151]) by epcpsbge3.samsung.com (EPCPMTA) with SMTP id 00.3B.25427.92DE8105; Wed, 01 Aug 2012 17:47:37 +0900 (KST)
Date: Wed, 01 Aug 2012 08:47:37 +0000 (GMT)
From: =?euc-kr?B?waSw5sjG?= <kyunghun.jung@samsung.com>
To: "mmusic (E-mail)" <mmusic@ietf.org>
MIME-version: 1.0
X-MTR: 20120801082551437@kyunghun.jung
Msgkey: 20120801082551437@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: 20120801082551437@kyunghun.jung
X-ParentMTR: 
X-ArchiveUser: 
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+NgFrrHIsWRmVeSWpSXmKPExsVy+t/t6bqabyUCDH60cVtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGU1vrrEV3PKp+PLoBnsD4w2vLkZODiEBDYnGZROZQWwJAROJ s3OPsULYYhIX7q1n62LkAqqZzyjRvnoLI0iCRUBFYuuvCSwgNpuAhUTPzUXsILawQIDEtJWr wGpEBNQlWjf3sYI0Mwv8Y5RYeW4jI8Q2ZYnWSdfANvAKCEqcnPmEBWKbmsTeffNZIOLqEq8W H2KEiEtIzJp+AeoiXokZ7U+h6uUkpn1dA3W1tMT5WRsYYa5e/P0xVJxf4tjtHUxdjBxgvU/u B8OM2b35CxuELSAx9cxBqFZtidMLTkC18kmsWfiWBWbMrlPLmWF672+Zy4TufGag3tY3H5kg bEWJKd0P2SHqNSVeH37MMoFRbhaSFnQ2TPssJO0LGFlWMYqmFiQXFCelpxrrFSfmFpfmpesl 5+duYgTH+jPeHYxzGywOMQpwMCrx8L4+IxEgxJpYVlyZe4hRgoNZSYS34CZQiDclsbIqtSg/ vqg0J7X4EKM0B4uSOO8Xr6/+QgLpiSWp2ampBalFMFkmDk6pBka7D6Y8jrf5qk/2rGtQbZjk 8Zk7vp7jzpHDH688Osp/fuvHaTu/6HV/WJLfV6RdbvhoId+qzV0PFtnn/0pNvbScW1TxSrLM ZIe1x8+4LPBpP5rQd3rRcWlXhpJzgU92nnF78+Jc3OX/M94G35hsnONSWDs1ufP8n+8Mi+Iy MqbaJE/0WbrnPm+EEktxRqKhFnNRcSIAMP86BfECAAA=
X-TM-AS-MML: No
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, =?euc-kr?Q?=C3=D6=BC=BA=C8=A3?= <schoi@samsung.com>, "nleung@QUALCOMM.COM" <nleung@QUALCOMM.COM>, =?euc-kr?Q?=C3=D6=C1=BE=BC=F6?= <jos.choi@samsung.com>
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
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 <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 08:47:41 -0000

PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ
VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciIgaHR0cC1lcXVp
dj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGU+UCB7DQoJTUFSR0lOLVRP
UDogNXB4OyBGT05ULUZBTUlMWTogsby4ssO8LCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDlwdA0KfQ0KVEQgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6ILG8
uLLDvCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkxJIHsN
CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBNQVJHSU4tQk9U
VE9NOiA1cHg7IEZPTlQtU0laRTogOXB0DQp9DQpCT0RZIHsNCglMSU5FLUhFSUdIVDogMS40OyBN
QVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiCxvLiyw7wsIGFyaWFsOyBGT05ULVNJWkU6IDlwdA0K
fQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD1BY3RpdmVTcXVhcmU+
PC9IRUFEPg0KPEJPRFk+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PUFjdGl2ZVNxdWFy
ZT4NCjxQPkRlYXIgTWFnbnVzIGFuZCBNTVVTSUMgY29sbGVhZ3Vlczo8L1A+DQo8UD4mbmJzcDs8
L1A+DQo8UD5UaGFuayB5b3UgZm9yIGRyYWZ0aW5nIHRoZSByZXBseSBMUyB0byAzR1BQLjwvUD4N
CjxQPiZuYnNwOzwvUD4NCjxQPkFsdGhvdWdoIHRoZSBuZWVkIGZvciBzdWNoIGEgbmVnb3RpYXRp
b24mbmJzcDtjYXBhYmlsaXR5IG9yaWdpbmFsbHkgc3RhcnRlZCB0byBzZXR1cCBhIHZvaWNlLW9u
bHkgc2Vzc2lvbjwvUD4NCjxQPndpdGhvdXQgUlRDUCBhdCBhbiBlYXJsaWVzdCBvcHBvcnR1bml0
eSwgaW4gc2VydmljZXMgc3VjaCBhcyBWb2ljZSBvdmVyIExURSAoVm9MVEUpLCB0byBzYXZlIGEg
ZmV3IGticHMsPC9QPg0KPFA+dGhpbmdzIGNhbiBnZXQgc2VyaW91cyBpZiB3IGNvbnNpZGVyIHRo
ZSBSVENQIGJpdC1yYXRlIGZvciBoaWdoLXF1YWxpdHkgdmlkZW8uIElmIHRoZSA1ICUgcnVsZXMg
YWNjZXB0ZWQ8L1A+DQo8UD5pbiBzb21lIGluZHVzdHJpZXMgYXJlIGFwcGxpZWQsIFJUQ1AgYml0
LXJhdGUgZm9yIGEgdmlkZW8gc2Vzc2lvbiBjYW4gY29uc3VtZSBtb3JlIHRoYW4gYSBmZXcgdm9p
Y2Ugc2Vzc2lvbnMuPC9QPg0KPFA+SWYgdGhlIHJlY2VpdmVkIFJUQ1AgYml0LXJhdGUgaXMgY29u
c2lkZXJlZCZuYnNwO3VubmVjZXNzYXJpbHkgaGlnaCwgdGhlIHNlc3Npb24gbWlnaHQgbm9lIGJl
IHNldCB1cDwvUD4NCjxQPmlmIHRoZSBhbnN3ZXJlciBoYWQgbm8gb3RoZXIgbWVhbnMgdG8gcmVk
dWNlIHRoZSBSVENQIGJpdC1yYXRlLjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPldlIGFyZSBvLmsu
IGlmIE1NVVNJQyBhbHNvIGFsbG93cyB0aGUgYW5zd2VyZXIgdG8gcmFpc2UgdXAgUlRDUCBiaXQt
cmF0ZS48L1A+DQo8UD5JbXBsZW1lbnRhdGlvbnMsIGluIGZhY3QsIHByb2R1Y3QgcmVxdWlyZW1l
bnRzIGZyb20gc2VydmljZSBwcm92aWRlcnMsJm5ic3A7d2lsbCB0cmFkZSBkZWxheSBmb3ImbmJz
cDthY2N1cmFjeSBpbjwvUD4NCjxQPnNlc3Npb24gbmVnb3RpYXRpb24gYW5kJm5ic3A7dGhlIGNh
cGFiaWxpdHkgd2lsbCBiZSB1c2VkIHdoZXJlIHN1Y2ggZmVhdHVyZSBpcyBlc3NlbnRpYWwsIGZv
ciBleGFtcGxlLCBhIHZlcnkgdGlnaHQ8L1A+DQo8UD5iaXQtcmF0ZSBjb250cm9sIGhhcyBhIGhp
Z2hlciBwcmlvcml0eSB0aGFuIGRlbGF5LiBDdXJyZW50IGltcGxlbWVudGF0aW9ucyB1c3VhbGx5
IHVzZSBub24temVybyBSUiB2YWx1ZXM8L1A+DQo8UD53aGljaCBpcyBuZWdsaWdpYmxlLCAyLTMg
a2JwcywgYW5kIGZpeGVkIGR1cmluZyBzZXNzaW9uIG5lZ290aWF0aW9uIG9mIGNvdXJzZS48L1A+
DQo8UD4mbmJzcDs8L1A+DQo8UD5CZXN0IHJlZ2FyZHMsPC9QPg0KPFA+S3l1bmdodW4gSnVuZzwv
UD4NCjxQPlNhbXN1bmcgRWxlY3Ryb25pY3MgQ28uLCBMdGQuPC9QPg0KPFA+Jm5ic3A7PC9QPg0K
PFA+LS0tLS0tLSA8Qj5PcmlnaW5hbCBNZXNzYWdlPC9CPiAtLS0tLS0tPC9QPg0KPFA+PEI+U2Vu
ZGVyPC9CPiA6IE1hZ251cyBXZXN0ZXJsdW5kJmx0O21hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u
LmNvbSZndDs8L1A+DQo8UD48Qj5EYXRlPC9CPiA6IDIwMTItMDgtMDEgMTA6MzUgKEdNVCswOTow
MCk8L1A+DQo8UD48Qj5UaXRsZTwvQj4gOiBbTU1VU0lDXSBQcm9wb3NhbCBmb3IgTFMgcmVwbHkg
cmVnYXJkaW5nIFJUQ1AgYmFuZHdpZHRoIG5lZ290aWF0aW9uPC9QPg0KPFA+Jm5ic3A7PC9QPk1N
VVNJQyBXRyw8QlI+PEJSPkJlbG93IHlvdSBmaW5kIG15IHByb3Bvc2FsIGZvciBhIHJlcGx5IHRv
IHRoZSBMUyB3ZSByZWNlaXZlZCBmcm9tIDNHUFA8QlI+U0E0IFdHLjxCUj5odHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTE1OS88QlI+PEJSPlRoaXMgaXMgaW50ZW5kZWQgYXMg
YSBzdGFydGluZyBwb2ludCBmb3IgYSBkaXNjdXNzaW9uIG9mIHdoYXQgcmVwbHkgd2U8QlI+YXMg
V0cgd2FudCB0byBzZW5kLiBTbyBwbGVhc2UgcmV2aWV3IGl0IGFuZCBzZW5kIGNvbW1lbnRzIG9u
IHRoaXMuPEJSPjxCUj5JIHdvdWxkIGhpZ2hseSBhcHByZWNpYXRlIGFueSBpbnNpZ2h0cyBob3cg
dGhpcyBpc3N1ZXMgaXMgY3VycmVudGx5PEJSPmRlYWx0IHdpdGggaW4gYW55IGltcGxlbWVudGF0
aW9ucy4gSWYgd2UgaGF2ZSBrbm93bGVkZ2Ugb2YgbXVsdGlwbGU8QlI+ZGlmZmVyZW50IHNvbHV0
aW9ucyB0aGVuIHRoYXQgaXMgc29tZXRoaW5nIHdlIHNob3VsZCBpbmRpY2F0ZS4gQWxzbyBpZjxC
Uj5hbnkgZXhpc3Rpbmcgc29sdXRpb24gY2xhc2hlcyB3aXRoIFNBNCdzIHByb3Bvc2VkIHNvbHV0
aW9uLjxCUj48QlI+SSBhbHNvIHJhaXNlIHRoZSBxdWVzdGlvbiBpZiB3ZSBzaG91bGQgaW5pdGlh
dGUgYW55IHVwZGF0ZSBvZiBSRkMgMzU1Ni48QlI+QW5kIGlmIHdlIGNhbiBjb21lIHRvIHN1Y2gg
YW4gYWdyZWVtZW50IGFuZCBoYXZlIHZvbHVudGVlcnMgd2UgbWF5IGJlPEJSPmFibGUgdG8gc3Ry
ZW5ndGhlbiB0aGUgbGFuZ3VhZ2UgaW4gdGhlIGxhc3QgcGFyYWdyYXBoLiBPdGhlcndpc2UgdGhh
dDxCUj5sYW5ndWFnZSBpcyBpbnRlbmRlZCB0byBzaWduYWwgYSBwcmVmZXJlbmNlIGZvciB0aGUg
ZHJpdmluZyBwYXJ0aWVzIGluPEJSPlNBNCB0byBjb21lIGhlbHAgdXMgdXBkYXRlIHRoZSBSRkMg
aW4gTU1VU0lDIFdHLjxCUj48QlI+PT09PEJSPlNvdXJjZTogSUVURiBNTVVTSUMgV0c8QlI+VG86
IDNHUFAgVFNHIFNBIFdHNCAoU0E0KTxCUj48QlI+VGl0bGU6IFJlcGx5IHJlZ2FyZGluZyBPbiBS
VENQIEJhbmR3aWR0aCBOZWdvdGlhdGlvbjxCUj48QlI+PEJSPk1NVVNJQyBXRyB0aGFua3MgU0E0
IGZvciBzZWVraW5nIG91ciBpbnB1dCBvbiB0aGlzIHRvcGljLiBXZSBhZ3JlZSB3aXRoPEJSPlNB
NCdzIGlkZW50aWZpY2F0aW9uIHRoYXQgdGhlcmUgZXhpc3Qgbm8gd2VsbCBkZWZpbmVkIGJlaGF2
aW9yIGZvciB0aGU8QlI+bmVnb3RpYXRpb24gb2YgdGhlIFJUQ1AgYmFuZHdpZHRoIHBhcmFtZXRl
cnMgUlIgYW5kIFJTIHdoZW4gdXNlZCBpbjxCUj5PZmZlci9BbnN3ZXIgY29udGV4dCB0byBuZWdv
dGlhdGUgYSB1bmljYXN0IHRyYW5zcG9ydGVkIFJUUCBzZXNzaW9uLiBJdDxCUj5pcyBjbGVhciB0
aGF0IHRoZSBSVFAgc2Vzc2lvbiBwYXJ0aWNpcGF0aW5nIGVuZC1wb2ludHMgZG8gbmVlZCB0byBh
Z3JlZTxCUj5vbiBjb21tb24gdmFsdWVzIG9yIHRoZXJlIGV4aXN0IGEgcG90ZW50aWFsIGZvciBp
bnRlcm9wZXJhYmlsaXR5IGZhaWx1cmVzLjxCUj48QlI+UmVnYXJkaW5nIHRoZSBwcm9wb3NlZCBy
ZWNvbW1lbmRhdGlvbnMgZm9yIG5lZ290aWF0aW9uIE1NVVNJQyBXRyBoYXMgdGhlPEJSPmZvbGxv
d2luZyBjb21tZW50cy48QlI+PEJSPjEuIEJhc2VkIG9uIHRoZSBsaW1pdGF0aW9ucyBvZiBPZmZl
ci9BbnN3ZXIgYW5kIHRoZSByZXF1aXJlbWVudCBvbjxCUj5hcnJpdmluZyBhdCBhIGNvbW1vbiBS
VENQIGJhbmR3aWR0aCB2YWx1ZSBmb3IgUlIgYW5kIFJTIHJlc3BlY3RpdmVseTxCUj50aGVyZSBl
eGlzdCBvbmx5IHR3byBwb3NzaWJsZSBjaG9pY2VzLiBBLiB0aGF0IHRoZSBPZmZlcmVyIGRpY3Rh
dGVzIHRoZTxCUj5iYW5kd2lkdGggdmFsdWVzIHdpdGhvdXQgYW55IHBvc3NpYmlsaXRpZXMgZm9y
IEIgdG8gY2hhbmdlIHRoZSB2YWx1ZXMsPEJSPm9yIEIuIGFzIHByb3Bvc2VkIGluIHRoZSBMUyB0
aGF0IHRoZSBPZmZlcmVyIHN1Z2dlc3QgYSB2YWx1ZSB0aGF0PEJSPnRoZSBBbnN3ZXJlciBtYXkg
bW9kaWZ5LiBPbiB0aGF0IGhpZ2ggbGV2ZWwgTU1VU0lDIFdHIGNvbnNpZGVycyB0aGU8QlI+cHJv
cG9zZWQgc29sdXRpb24gYXBwcm9wcmlhdGU8QlI+PEJSPjIuIEhvd2V2ZXIsIHdlIGRvIGNvbnNp
ZGVyIHRoZSBsaW1pdGF0aW9uIHRoYXQgdGhlIGFuc3dlcmVyIG9ubHkgY2FuPEJSPmtlZXAgb3Ig
cmVkdWNlIHRoZSBiYW5kd2lkdGggdmFsdWVzIHRvIGEgYmUgYSBwb3RlbnRpYWwgaXNzdWUgaW4g
dGhlPEJSPnByb3Bvc2VkIHJlY29tbWVuZGF0aW9uLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhlIGFu
c3dlcmluZyBwYXJ0eSB0aGVuPEJSPmhhdmUgbm8gd2F5IG9mIGluY3JlYXNpbmcgdGhlIHZhbHVl
IGlmIHRoZSBwZWVyIGFnZW50IGlzIG5vdCB3aWxsaW5nIHRvPEJSPmFjY2VwdCB0aGUgaGlnaGVy
IHN1Z2dlc3RlZCB2YWx1ZXMgaW4gYSBzdWJzZXF1ZW50IE9mZmVyLiBUaGlzIG1heTxCUj5hcHBl
YXIgYSByZWFzb25hYmxlIGJlaGF2aW9yIGluIG1hbnkgY2FzZXMgYW5kIGNvbnNpZGVyaW5nIGxp
bWl0ZWQgdG90YWw8QlI+YmFuZHdpZHRoIG9uIHRoZSBwYXRoIGJldHdlZW4gdGhlIGFnZW50cy4g
SG93ZXZlciwgd2hlbiBhbiBhZ2VudDxCUj5yZXF1aXJlcyBhIGhpZ2hlciBSVENQIGJhbmR3aWR0
aCBkdWUgdG8gaXRzIHVzYWdlIG9mIHNvbWUgUlRDUCBiYXNlZDxCUj5leHRlbnNpb25zIHRoaXMg
Y291bGQgcHJldmVudCBzdWNoIGZ1bmN0aW9uYWxpdHkgZnJvbSBiZWluZyB1c2VkLiBBbmQ8QlI+
dGhlIGJhbmR3aWR0aCB1c2FnZSBjb3VsZCBiZSBhZGRyZXNzZWQgYnkgaGF2aW5nIHRoZSBhbnN3
ZXJpbmcgcGFydHkgdG88QlI+cmVkdWNlIHRoZSB0b3RhbCBSVFAgc2Vzc2lvbiBiYW5kd2lkdGgg
aW4gaXRzIGFuc3dlciBhbmQgYmUgZm9yY2VkIHRvPEJSPnJlZHVjZSB0aGUgYml0LXJhdGUgZGVs
aXZlcmVkIHRvIHRoZSBvdGhlciBhZ2VudCBpbiBwcm9wb3J0aW9uIHRvIHRoZTxCUj5pbmNyZWFz
ZSBvZiB0aGUgUlRDUCBiYW5kd2lkdGguPEJSPjxCUj4zLiBIYXMgYW55IHNwZWNpYWwgY29uc2lk
ZXJhdGlvbiBiZWVuIHRha2VuIGFyb3VuZCB0aGUgdXNhZ2Ugb2YgUlIgb3IgUlM8QlI+cGFyYW1l
dGVyIHZhbHVlcyBvZiAwLiBJZiBlaXRoZXIgb2ZmZXJlciBvciBhbnN3ZXJlciBpbnRlbmRlZCB0
byB0dXJuPEJSPm9mZiBSVENQIGNvbXBsZXRlbHkgb3IgZm9yIHJlY2VpdmVycyBvbmx5LCBpdCBp
cyBxdWVzdGlvbmFibGUgdGhhdCB0aGlzPEJSPnNob3VsZCBoYXZlIHByZWNlZGVuY2Ugb3ZlciB0
aGUgb3RoZXIgYWdlbnRzIGRlc2lyZSB0byB1c2UgUlRDUC48QlI+PEJSPk1NVVNJQyBtYXkgY29u
c2lkZXIgdG8gdXBkYXRlIFJGQyAzNTU2IHRvIGFtZW5kIHRoZSBsYWNrIG9mIE9mZmVyL0Fuc3dl
cjxCUj5ydWxlcyBmb3IgdGhlIFJSIGFuZCBSUyBiYW5kd2lkdGggcGFyYW1ldGVycy4gVGhpcyB3
b3VsZCBiZSB0byBwcm92aWRlPEJSPmFsbCB1c2VycyBvZiB0aGUgUlRDUCBiYW5kd2lkdGggcGFy
YW1ldGVyIHdpdGggZ3VpZGFuY2Ugb24gdGhpcyBpc3N1ZS48QlI+SWYgdGhlIHBhcnRpY2lwYW50
cyBpbiBTQTQgV0cgY29uc2lkZXJzIHRoYXQgYXBwcm9wcmlhdGUsIE1NVVNJQyBXRzxCUj53b3Vs
ZCBoaWdobHkgYXBwcmVjaWF0ZSBhbnkgZW5nYWdlbWVudCBmcm9tIHRoZSBTQTQgcGFydGljaXBh
bnRzIGluPEJSPnRoZSBNTVVTSUMgV0cuPEJSPjxCUj5BY3Rpb25zOiBOb25lPEJSPjxCUj4tLSBl
bmQgb2YgcHJvcG9zZWQgTFMgcmVwbHkgLS08QlI+PEJSPkNoZWVyczxCUj48QlI+TWFnbnVzIFdl
c3Rlcmx1bmQ8QlI+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+TXVsdGltZWRpYSBUZWNobm9sb2dpZXMs
IEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk08QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5Fcmljc3NvbiBB
QiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgUGhvbmUmbmJzcDsmbmJz
cDsrNDYgMTAgNzE0ODI4NzxCUj5GYXJvZ2F0YW4gNiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO3wgTW9iaWxlICs0NiA3MyAwOTQ5MDc5PEJSPlNFLTE2NCA4MCBTdG9ja2hv
bG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208QlI+LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLTxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188QlI+bW11c2ljIG1haWxpbmcgbGlzdDxCUj5tbXVzaWNAaWV0Zi5vcmc8QlI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8QlI+DQo8UD4mbmJzcDs8
L1A+PC9CT0RZPjwvSFRNTD48aW1nIHNyYz0naHR0cDovL2V4dC5zYW1zdW5nLm5ldC9tYWlsY2hl
Y2svU2VlblRpbWVDaGVja2VyP2RvPWU0MzZjMDU2NGEzNGYwMGRhM2IyZjA2NDk1YmEyMzQ0YTc2
N2UwYjNjY2M5NGVjOGFiYTg5ZWFlZjYwM2M4MTg3OGQ3YzUwYWU5NzczYjU1MmE1YTZiN2Q0MjZk
MDFlMzFiMjA5MDlhMDRlZmQ0ZDI3NDhjZmUxZDRlODQ3NDE5Y2Y4NzhmOWEyNmNlMTVhMCcgYm9y
ZGVyPTAgd2lkdGg9MCBoZWlnaHQ9MCBzdHlsZT0nZGlzcGxheTpub25lJz4=




From ron.even.tlv@gmail.com  Wed Aug  1 10:51:31 2012
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DD211E83B3 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 10:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001,  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 CAa-XENshLRY for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 10:51:30 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4F11E83B2 for <mmusic@ietf.org>; Wed,  1 Aug 2012 10:51:30 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so1464810pbb.31 for <mmusic@ietf.org>; Wed, 01 Aug 2012 10:51:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=qt+cae3R83mZ7iFUqYrt387ygvdrTouxqOZKYDe5Vhw=; b=F134VnLP7rOPogk3pCUOQ8LbcKDmKN/Fem3RXMtv7K1e1yvDd6OQ4fu6od6B1IKSVo l0zLHqGL0FtJq24kzrnsM+s5YaOoDhC9IRj7t+6ABg91qepkN0mbezYD0aZiG1fRyzhq 6VWIjM5RR/mvLp7Yw/X4/2ew0/cRcBAU6frHpK2zjN562affuNKhnKKAJHBmISxilorY ur4twFBMss0vfzIucVefHFjXSTunW/E2YSHUd331C/Bvfi51co6wDYBlrwVzGEV9TWMH buBeb6gv0tbezNQS6WUNv/+95yVZrkbumhIoI+SUO8HT3Uoyxg7YSZ3VdN2Oo2MV1beQ JlsA==
Received: by 10.68.189.162 with SMTP id gj2mr53496913pbc.153.1343843490169; Wed, 01 Aug 2012 10:51:30 -0700 (PDT)
Received: from RoniE ([2001:df8:0:16:3424:a76a:4bd6:e1bf]) by mx.google.com with ESMTPS id qx9sm3005721pbc.8.2012.08.01.10.51.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 10:51:29 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>, "'mmusic \(E-mail\)'" <mmusic@ietf.org>
References: <501887FF.7020203@ericsson.com>
In-Reply-To: <501887FF.7020203@ericsson.com>
Date: Wed, 1 Aug 2012 20:50:21 +0200
Message-ID: <004f01cd7016$83580e70$8a082b50$@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: AQD8I46QGr1zZSaKGiBCtHZbX0DPa5jn3+jw
Content-Language: en-us
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 17:51:31 -0000

Hi,
The liaison looks OK to me.
I agree with using option B in the first comment and to allow increasing =
BW
in the answer.=20
As for comment 2 I assume that you are saying that the tradeoffs between
increasing RTCP and reducing RTP bw using same session bw, or increasing =
the
total session bw can be used to provide more RTCP bw with or without =
chaning
RTP bw. These options should be documented.

On the RR and SR value 0 are you suggesting to change RFC 3556.  I am =
not
sure it is a good question to ask 3GPP if they did not mention it
themselves; I am not supportive of the topic of negotiation of the use =
of
RTCP. So suggest to remove this comment
Roni




-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf =
Of
Magnus Westerlund
Sent: 01 August, 2012 3:36 AM
To: mmusic (E-mail)
Subject: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth =
negotiation

MMUSIC WG,

Below you find my proposal for a reply to the LS we received from 3GPP
SA4 WG.
https://datatracker.ietf.org/liaison/1159/

This is intended as a starting point for a discussion of what reply we =
as WG
want to send. So please review it and send comments on this.

I would highly appreciate any insights how this issues is currently =
dealt
with in any implementations. If we have knowledge of multiple different
solutions then that is something we should indicate. Also if any =
existing
solution clashes with SA4's proposed solution.

I also raise the question if we should initiate any update of RFC 3556.
And if we can come to such an agreement and have volunteers we may be =
able
to strengthen the language in the last paragraph. Otherwise that =
language is
intended to signal a preference for the driving parties in
SA4 to come help us update the RFC in MMUSIC WG.

=3D=3D=3D
Source: IETF MMUSIC WG
To: 3GPP TSG SA WG4 (SA4)

Title: Reply regarding On RTCP Bandwidth Negotiation


MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
SA4's identification that there exist no well defined behavior for the
negotiation of the RTCP bandwidth parameters RR and RS when used in
Offer/Answer context to negotiate a unicast transported RTP session. It =
is
clear that the RTP session participating end-points do need to agree on
common values or there exist a potential for interoperability failures.

Regarding the proposed recommendations for negotiation MMUSIC WG has the
following comments.

1. Based on the limitations of Offer/Answer and the requirement on =
arriving
at a common RTCP bandwidth value for RR and RS respectively there exist =
only
two possible choices. A. that the Offerer dictates the bandwidth values
without any possibilities for B to change the values, or B. as proposed =
in
the LS that the Offerer suggest a value that the Answerer may modify. On
that high level MMUSIC WG considers the proposed solution appropriate

2. However, we do consider the limitation that the answerer only can =
keep or
reduce the bandwidth values to a be a potential issue in the proposed
recommendation. The reason is that the answering party then have no way =
of
increasing the value if the peer agent is not willing to accept the =
higher
suggested values in a subsequent Offer. This may appear a reasonable
behavior in many cases and considering limited total bandwidth on the =
path
between the agents. However, when an agent requires a higher RTCP =
bandwidth
due to its usage of some RTCP based extensions this could prevent such
functionality from being used. And the bandwidth usage could be =
addressed by
having the answering party to reduce the total RTP session bandwidth in =
its
answer and be forced to reduce the bit-rate delivered to the other agent =
in
proportion to the increase of the RTCP bandwidth.

3. Has any special consideration been taken around the usage of RR or RS
parameter values of 0. If either offerer or answerer intended to turn =
off
RTCP completely or for receivers only, it is questionable that this =
should
have precedence over the other agents desire to use RTCP.

MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
rules for the RR and RS bandwidth parameters. This would be to provide =
all
users of the RTCP bandwidth parameter with guidance on this issue.
If the participants in SA4 WG considers that appropriate, MMUSIC WG =
would
highly appreciate any engagement from the SA4 participants in the MMUSIC =
WG.

Actions: None

-- end of proposed LS reply --

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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


From magnus.westerlund@ericsson.com  Wed Aug  1 11:01:27 2012
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86E011E8295 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.198
X-Spam-Level: 
X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 d8OwQlzZGlyJ for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:01:27 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B0BC611E8173 for <mmusic@ietf.org>; Wed,  1 Aug 2012 11:01:26 -0700 (PDT)
X-AuditID: c1b4fb25-b7f236d000005cde-ab-50196ef5b68c
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D4.B7.23774.5FE69105; Wed,  1 Aug 2012 20:01:25 +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.264.0; Wed, 1 Aug 2012 20:01:24 +0200
Message-ID: <50196EF0.2050207@ericsson.com>
Date: Wed, 1 Aug 2012 11:01:20 -0700
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <501887FF.7020203@ericsson.com> <004f01cd7016$83580e70$8a082b50$@gmail.com>
In-Reply-To: <004f01cd7016$83580e70$8a082b50$@gmail.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre7XPMkAgysPVS2mLn/MYvG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyrhzcjZ7wXueinez3rI1MM7j6mLk4JAQMJGY 8zyhi5ETyBSTuHBvPVsXIxeHkMApRoll/9czgSSEBJYxSqz7xwFi8wpoS1xpnc8OYrMIqEhs PvaQDcRmE7CQuPmjEcwWFQiU+Lb1OCtEvaDEyZlPWEBsEQE1iddrP4PVMAtoSuyY9BNsvrBA gMS0lasYIXaFS2x7NQeslxNo5sxfa1gh7pSUuH0gBaJVT2LK1RZGCFteonnrbGaIVm2JhqYO 1gmMQrOQbJ6FpGUWkpYFjMyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzECg/fglt+qOxjvnBM5 xCjNwaIkzmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsb0sxF//+xZk/XpX0in6fst 8RzK356ULv0ye4rv//7v9/3PRM075lHo/eup9L1+vin/VmTK75Y/vm/eB4u0MyGNWvt05SMW hZqf7V8rc0zS84nXlO8V0//eqjGc9SL0mEDGI8tlIcZmNyJY2rjsNbn718SVpil2+its93Od MVX93b9OQbWd938osRRnJBpqMRcVJwIApVyhuSwCAAA=
Cc: "'mmusic \(E-mail\)'" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 18:01:27 -0000

On 2012-08-01 11:50, Roni Even wrote:
> Hi,
> The liaison looks OK to me.
> I agree with using option B in the first comment and to allow increasing BW
> in the answer. 
> As for comment 2 I assume that you are saying that the tradeoffs between
> increasing RTCP and reducing RTP bw using same session bw, or increasing the
> total session bw can be used to provide more RTCP bw with or without chaning
> RTP bw. These options should be documented.

I wanted to point out that you can allow increasing the value in a
response without affecting the total bandwidth as that is likely a
concern for the offerer.

> 
> On the RR and SR value 0 are you suggesting to change RFC 3556.  I am not
> sure it is a good question to ask 3GPP if they did not mention it
> themselves; I am not supportive of the topic of negotiation of the use of
> RTCP. So suggest to remove this comment

I don't quite understand what you are trying to say. My intention was to
try to request that it is clarified about the usage of 0. So if I offer
a non-zero value are the answer really allowed to turn off RTCP? The
3GPP proposal do allow for turning off RTCP as proposed.

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 jmpolk@cisco.com  Wed Aug  1 11:28:48 2012
Return-Path: <jmpolk@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474EB11E810B for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.507
X-Spam-Level: 
X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 TUiRLQ1fiZtB for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:28:47 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0311E83C8 for <mmusic@ietf.org>; Wed,  1 Aug 2012 11:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=915; q=dns/txt; s=iport; t=1343845727; x=1345055327; h=message-id:date:to:from:subject:mime-version; bh=A4/D0SrxsCmBBZGG6TAnkcS/j+bFxzFJHFyCdOBHY98=; b=fVvhRc5WJDwTqHjI0o8Bsyh2r3MhiFp9e39IyQRUbaszvwPUdwHbr18J jN1/xySGYQATe75zH827XowxwFQw2IVn4BmVchvhyAHM1IFgklNjBOdaX i20bohCdbXRWCvpDkWjfB+qwqJ34qU2F5NxffGH/dM99NBO+x59N5xCmb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGV0GVCrRDoJ/2dsb2JhbABFuRCBB4I5ASUCVjopRDWHaptBgSigS5JSA4hNmyGBZoJ9
X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208";a="51217030"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 01 Aug 2012 18:28:46 +0000
Received: from jmpolk-WS.cisco.com ([10.21.169.169]) (authenticated bits=0) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q71ISiWg020077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mmusic@ietf.org>; Wed, 1 Aug 2012 18:28:45 GMT
Message-Id: <201208011828.q71ISiWg020077@mtv-core-4.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 01 Aug 2012 13:28:44 -0500
To: mmusic <mmusic@ietf.org>
From: James Polk <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
Subject: [MMUSIC] Confirming comments about Traffic class label preso
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 18:28:48 -0000

WG

I'm confirming two points made during MMUSIC this morning:

#1 - that there is no disagreement to remove the '_' prefix for 
proprietary label components, such as

     category.application._foo._bar

where foo and bar are not IANA registered.

#2 - that there is no disagreement that as a result of #1 being 
acceptable, the bar to IANA register new label components will be no 
lower than "specification required".

Additionally, I will work to resolve each of the known open items 
stated in the preso:

- new ABNF (get with Paul K.)
- separate label component into clearer sections
- clearly state which applications go with which categories, and 
which adjectives go with which applications.

I'll also look into writing a short section on guidelines for how to 
properly extend or register new label components for future work.

Comments and questions are appreciated.

james


From ron.even.tlv@gmail.com  Wed Aug  1 11:28:54 2012
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFF011E83D0 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 LeSHNlEsxqvz for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:28:53 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C85B711E83DF for <mmusic@ietf.org>; Wed,  1 Aug 2012 11:28:53 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so1509467pbb.31 for <mmusic@ietf.org>; Wed, 01 Aug 2012 11:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=sTBXjMOBhgiiOYk0fe8QEXG25uF8aiqdvNoN/Wy9HAw=; b=Upy4XBr2YduCi0O9v/GQycSlhjP7Jg05WabCQBjeR+GMaLGdItVxfxw39G3Sgd7iub cMXH3xzO9uQ3hrQhDSBuDZRAC/PggHTmq1QJDYWMEKGWkWwMXQDeOvcd0vg874SLzvW6 y/tuJiCY0BjTMRBXUdwvpDBhBNQk30nm4XpZYfwwJxRocmkB7YPSMMOHPZ5Xu9bt7Ldf 8KX4n17tUqo1jB23aPYZjaJ+WX7+VMnW1d/U2go/U7nKQXe9SXwTjX65W3S5q4vl7CnQ 6QRrcu8Mwc5LeZ5ALGXA//GSRrXKOa9N5BwXK1Ojwc/IBK0+QVr8mWbxNP6YdZPl3nlP U7eg==
Received: by 10.68.241.41 with SMTP id wf9mr54753715pbc.41.1343845733548; Wed, 01 Aug 2012 11:28:53 -0700 (PDT)
Received: from RoniE ([2001:df8:0:16:3424:a76a:4bd6:e1bf]) by mx.google.com with ESMTPS id ot4sm3045185pbb.65.2012.08.01.11.28.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 11:28:52 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
References: <501887FF.7020203@ericsson.com> <004f01cd7016$83580e70$8a082b50$@gmail.com> <50196EF0.2050207@ericsson.com>
In-Reply-To: <50196EF0.2050207@ericsson.com>
Date: Wed, 1 Aug 2012 21:27:45 +0200
Message-ID: <005f01cd701b$bc78be70$356a3b50$@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: AQD8I46QGr1zZSaKGiBCtHZbX0DPawDidzeoAOGd52eY2c52YA==
Content-Language: en-us
Cc: "'mmusic \(E-mail\)'" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 18:28:54 -0000

Magnus,
Inline
Roni

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: 01 August, 2012 8:01 PM
To: Roni Even
Cc: 'mmusic (E-mail)'
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth
negotiation

On 2012-08-01 11:50, Roni Even wrote:
> Hi,
> The liaison looks OK to me.
> I agree with using option B in the first comment and to allow=20
> increasing BW in the answer.
> As for comment 2 I assume that you are saying that the tradeoffs=20
> between increasing RTCP and reducing RTP bw using same session bw, or=20
> increasing the total session bw can be used to provide more RTCP bw=20
> with or without chaning RTP bw. These options should be documented.

I wanted to point out that you can allow increasing the value in a =
response
without affecting the total bandwidth as that is likely a concern for =
the
offerer.

RE: this was not clear to me from the text since you talk also about
increasing or decreasing the total bw.

>=20
> On the RR and SR value 0 are you suggesting to change RFC 3556.  I am=20
> not sure it is a good question to ask 3GPP if they did not mention it=20
> themselves; I am not supportive of the topic of negotiation of the use =

> of RTCP. So suggest to remove this comment

I don't quite understand what you are trying to say. My intention was to =
try
to request that it is clarified about the usage of 0. So if I offer a
non-zero value are the answer really allowed to turn off RTCP? The 3GPP
proposal do allow for turning off RTCP as proposed.

RE: maybe point in the answer to RFC3556 for this comment " Has any =
special
consideration been taken around the usage of RR or RS parameter values =
of 0
as specified in RFC3556"

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From zhou.sujing@zte.com.cn  Wed Aug  1 11:48:57 2012
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB39A11E80DC for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.996
X-Spam-Level: 
X-Spam-Status: No, score=-97.996 tagged_above=-999 required=5 tests=[AWL=3.842, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPVM-3V+GQO8 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:48:56 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 388AA11E809B for <mmusic@ietf.org>; Wed,  1 Aug 2012 11:48:56 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723978252052; Thu, 2 Aug 2012 02:37:43 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 47492.978252052; Thu, 2 Aug 2012 02:48:41 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q71ImkbF054752 for <mmusic@ietf.org>; Thu, 2 Aug 2012 02:48:46 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
To: mmusic@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF54E2C800.D1135322-ON48257A4D.00672623-48257A4D.00674B7D@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Thu, 2 Aug 2012 02:48:35 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-02 02:48:41, Serialize complete at 2012-08-02 02:48:41
Content-Type: multipart/alternative; boundary="=_alternative 00674B7748257A4D_="
X-MAIL: mse01.zte.com.cn q71ImkbF054752
Subject: [MMUSIC] I don't understand why work on SDES should be reviewed by TLS people
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 18:48:57 -0000

This is a multipart message in MIME format.
--=_alternative 00674B7748257A4D_=
Content-Type: text/plain; charset="US-ASCII"

Regards~~~

-Sujing Zhou
--=_alternative 00674B7748257A4D_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Regards~~~<br>
<br>
-Sujing Zhou</font>
--=_alternative 00674B7748257A4D_=--


From jonathan@vidyo.com  Wed Aug  1 11:56:32 2012
Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D234011E831C for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=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 V26xK2LC3r8k for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 11:56:32 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id EB38A11E829A for <mmusic@ietf.org>; Wed,  1 Aug 2012 11:56:31 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8B036556C1F for <mmusic@ietf.org>; Wed,  1 Aug 2012 14:56:31 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2F073556C1B for <mmusic@ietf.org>; Wed,  1 Aug 2012 14:56:28 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Wed, 1 Aug 2012 14:56:08 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Date: Wed, 1 Aug 2012 14:56:33 -0400
Thread-Topic: Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac1wF0+T5NaAB5VuSRCtWQNsyZAJTw==
Message-ID: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 18:56:32 -0000

As I mentioned at the mic, BUNDLE currently generates an implicit combined =
description of the bundled RTP session, and a lot of the problems and stand=
ardization issues we're having relate to the fact that the bundled session'=
s media description is implicit.  Therefore, you need a lot of language spe=
cifying when parts of bundled m=3Dlines must be the same, when they must be=
 different, and when they may be independent.  Such specifications would ne=
ed to be defined for every existing SDP attribute used in offer-answer, and=
 every new SDP attribute going forward.

The alternative to having an implicit description, I think, would be to hav=
e an explicit description.  The basic idea is to have a new m-line represen=
ting the bundled session explicitly, defined in a way that a non-bundle-awa=
re endpoint should see it as an unknown type of m-line and reject it.  The =
BUNDLE grouping semantic then says that you either use all the traditional =
m-lines, rejecting the bundled one, or you use the one bundled m-line, reje=
cting all the others.

As a straw man example, a variant of bundle-negotiation-00's example offer =
with ICE:

       v=3D0
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=3D
       c=3DIN IP4 host.atlanta.com
       t=3D0 0
       a=3Dgroup:BUNDLE foo bar baz
       m=3Daudio 10000 RTP/AVP 0 8 97
       a=3Dmid:foo
       b=3DAS:200
       a=3Drtpmap:0 PCMU/8000
       a=3Drtpmap:8 PCMA/8000
       a=3Drtpmap:97 iLBC/8000
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=3Dvideo 10002 RTP/AVP 31 32
       a=3Dmid:bar
       b=3DAS:1000
       a=3Drtpmap:31 H261/90000
       a=3Drtpmap:32 MPV/90000
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
       m=3Dbundle 10000 RTP/AVP 0 8 97 31 32
       a=3Dmid:baz
       b=3DAS:1200
       a=3Dfull-rtpmap:0 audio/PCMU/8000
       a=3Dfull-rtpmap:8 audio/PCMA/8000
       a=3Dfull-rtpmap:97 audio/iLBC/8000
       a=3Dfull-rtpmap:31 video/H261/90000
       a=3Dfull-rtpmap:32 video/MPV/90000
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host

Points to note:

* Outside the m=3Dbundle line and its attributes, this is entirely current-=
standard SDP.

* The m=3Dbundle is a complete description of an entirely separate m-line; =
if it's used, the other m-lines in the group are rejected and the informati=
on they carry is ignored.

* We'll need to make sure that we have a syntax for this new m-line (what I=
've called m=3Dbundle) that existing implementations will reject (with port=
 0), rather than interpreting as an SDP syntax error.  We'll need input fro=
m interop people to know what's safe to do here.

* The ports and ICE candidates specified in the m=3Dbundle line are entirel=
y up to the whim of the offerer; they may overlap with one of the other m-l=
ines, but don't have to.

* Because the media type of the payload types isn't given by the m-line, we=
 need new syntax to specify the top-level media type.  I've called this "fu=
ll-rtpmap", but this is just a strawman.

* Because there's one list of payload types, the RFC 3264 payload preferenc=
e order needs a bit of finessing. I'd suggest saying that the preference or=
der should be interpreted independently per media type.

* There's obviously no way to do a=3Dsendonly/recvonly independently for au=
dio and video; you'd need to do it on the source level, with (if you're doi=
ng it in SDP) something like my source-selection draft.

* There's an obvious syntax to send an offer that means "support BUNDLE, or=
 fail" -- just send the m=3Dbundle line, without the grouped independent li=
nes.  Whether we'd want to allow such an offer is a separate question.

--
Jonathan Lennox
jonathan@vidyo.com



From miguel.a.garcia@ericsson.com  Wed Aug  1 12:36:23 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E9F11E80A3 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 12:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.93
X-Spam-Level: 
X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=-0.281,  BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_62=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 OyTcDQIMp0jA for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 12:36:23 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8660511E809B for <mmusic@ietf.org>; Wed,  1 Aug 2012 12:36:22 -0700 (PDT)
X-AuditID: c1b4fb25-b7f236d000005cde-79-50198535cb99
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A0.6C.23774.53589105; Wed,  1 Aug 2012 21:36:21 +0200 (CEST)
Received: from [159.107.48.10] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Wed, 1 Aug 2012 21:36:20 +0200
Message-ID: <50198530.1070806@ericsson.com>
Date: Wed, 1 Aug 2012 21:36:16 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <501887FF.7020203@ericsson.com>
In-Reply-To: <501887FF.7020203@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3Vte0VTLAYN1McYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr48Oa34wF91Uqvu57xtLAeFS2i5GTQ0LAROLvhFPMELaYxIV7 69m6GLk4hAROMUpMubueHcJZxShxfuMOFpAqXgFtiTevzoB1sAioSGy+tIIdxGYTMJdo3bgR zBYVCJR4PnsLO0S9oMTJmU/AekUEzCQeTtjPBmIzC6hL9PxuAZsjLBAgMW3lKsYuRg6gZdoS VyZbgYQ5BXQkejauYYIot5W4MOc6C4QtL9G8dTZYq5CApsTkm0uZJzAKzkKybRaSlllIWhYw Mq9iFM5NzMxJLzfSSy3KTC4uzs/TK07dxAgMy4NbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGOvmZultMTzC4KI1M+j0tNrvvcXNsefOn7I8xL/0Hbtf 9z4Z46TdgUVvf4rsEj465QvHIo9/qyOd7J8kNt1cGjChXF11S1xh8q5qrYtxdh1LNjuJvjuw qPrV6W2LWtvvrincNdeO7f+8u5Fuehx3XSdYmEm8XG63LnidZOiGzrmyV/p2ftjY/FOJpTgj 0VCLuag4EQBGuv0sGQIAAA==
Cc: "mmusic \(E-mail\)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 19:36:24 -0000

A reminder to the WG.

We indicated earlier in the meeting that we have only 2 additional days 
for commenting Magnus'es proposed answer to this LS. We are aiming to get 
an agreed response by this Friday August 3rd.

/Miguel

On 01/08/2012 3:35, Magnus Westerlund wrote:
> MMUSIC WG,
>
> Below you find my proposal for a reply to the LS we received from 3GPP
> SA4 WG.
> https://datatracker.ietf.org/liaison/1159/
>
> This is intended as a starting point for a discussion of what reply we
> as WG want to send. So please review it and send comments on this.
>
> I would highly appreciate any insights how this issues is currently
> dealt with in any implementations. If we have knowledge of multiple
> different solutions then that is something we should indicate. Also if
> any existing solution clashes with SA4's proposed solution.
>
> I also raise the question if we should initiate any update of RFC 3556.
> And if we can come to such an agreement and have volunteers we may be
> able to strengthen the language in the last paragraph. Otherwise that
> language is intended to signal a preference for the driving parties in
> SA4 to come help us update the RFC in MMUSIC WG.
>
> ===
> Source: IETF MMUSIC WG
> To: 3GPP TSG SA WG4 (SA4)
>
> Title: Reply regarding On RTCP Bandwidth Negotiation
>
>
> MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
> SA4's identification that there exist no well defined behavior for the
> negotiation of the RTCP bandwidth parameters RR and RS when used in
> Offer/Answer context to negotiate a unicast transported RTP session. It
> is clear that the RTP session participating end-points do need to agree
> on common values or there exist a potential for interoperability failures.
>
> Regarding the proposed recommendations for negotiation MMUSIC WG has the
> following comments.
>
> 1. Based on the limitations of Offer/Answer and the requirement on
> arriving at a common RTCP bandwidth value for RR and RS respectively
> there exist only two possible choices. A. that the Offerer dictates the
> bandwidth values without any possibilities for B to change the values,
> or B. as proposed in the LS that the Offerer suggest a value that
> the Answerer may modify. On that high level MMUSIC WG considers the
> proposed solution appropriate
>
> 2. However, we do consider the limitation that the answerer only can
> keep or reduce the bandwidth values to a be a potential issue in the
> proposed recommendation. The reason is that the answering party then
> have no way of increasing the value if the peer agent is not willing to
> accept the higher suggested values in a subsequent Offer. This may
> appear a reasonable behavior in many cases and considering limited total
> bandwidth on the path between the agents. However, when an agent
> requires a higher RTCP bandwidth due to its usage of some RTCP based
> extensions this could prevent such functionality from being used. And
> the bandwidth usage could be addressed by having the answering party to
> reduce the total RTP session bandwidth in its answer and be forced to
> reduce the bit-rate delivered to the other agent in proportion to the
> increase of the RTCP bandwidth.
>
> 3. Has any special consideration been taken around the usage of RR or RS
> parameter values of 0. If either offerer or answerer intended to turn
> off RTCP completely or for receivers only, it is questionable that this
> should have precedence over the other agents desire to use RTCP.
>
> MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
> rules for the RR and RS bandwidth parameters. This would be to provide
> all users of the RTCP bandwidth parameter with guidance on this issue.
> If the participants in SA4 WG considers that appropriate, MMUSIC WG
> would highly appreciate any engagement from the SA4 participants in
> the MMUSIC WG.
>
> Actions: None
>
> -- end of proposed LS reply --
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From eckelcu@cisco.com  Wed Aug  1 13:41:29 2012
Return-Path: <eckelcu@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AF011E8283 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 13:41:29 -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 rGkOfzVFEXUY for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 13:41:28 -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 AEC4811E819B for <mmusic@ietf.org>; Wed,  1 Aug 2012 13:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1540; q=dns/txt; s=iport; t=1343853688; x=1345063288; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CFXXO2GEeuApGpPyN/cy0APiMiWKsYDqw6X+XfqjCjI=; b=nG2Gx8KNrfxbUbWmsLAw7KZo+6XOD78WgcRT9AFj5MWdc4WpveEV++6e pkRQPxVXajlom2rDL88cp1moRvzPlPyuxi4b9e/je+ZK9urpe/uX3GO/G FyyYM4ZXTv8Ow7p5sxoQRycRD+vcsRNwjbSB33Zn4DNKoYfAk5+9Ndn7W g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACmTGVCtJV2Y/2dsb2JhbABFuRGBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHawuca6A+BItJhilgA6NugWaCXw
X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="107602384"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2012 20:41:28 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71KfSOD025018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Wed, 1 Aug 2012 20:41:28 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.143]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 15:41:28 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "James Polk (jmpolk)" <jmpolk@cisco.com>, mmusic <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Confirming comments about Traffic class label preso
Thread-Index: AQHNcBODuCayklYOkE+pf6VCIR6iv5dFa1ZA
Date: Wed, 1 Aug 2012 20:41:27 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C088280664E3@xmb-aln-x08.cisco.com>
References: <201208011828.q71ISiWg020077@mtv-core-4.cisco.com>
In-Reply-To: <201208011828.q71ISiWg020077@mtv-core-4.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.150.184]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.004
x-tm-as-result: No--41.645000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Confirming comments about Traffic class label preso
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 20:41:30 -0000

#1 and #2 address my concern and are consistent with my recollection of the=
 agreement reached in the meeting.

Cheers,
Charles

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of James Polk (jmpolk)
> Sent: Wednesday, August 01, 2012 11:29 AM
> To: mmusic
> Subject: [MMUSIC] Confirming comments about Traffic class label preso
>=20
> WG
>=20
> I'm confirming two points made during MMUSIC this morning:
>=20
> #1 - that there is no disagreement to remove the '_' prefix for
> proprietary label components, such as
>=20
>      category.application._foo._bar
>=20
> where foo and bar are not IANA registered.
>=20
> #2 - that there is no disagreement that as a result of #1 being
> acceptable, the bar to IANA register new label components will be no
> lower than "specification required".
>=20
> Additionally, I will work to resolve each of the known open items
> stated in the preso:
>=20
> - new ABNF (get with Paul K.)
> - separate label component into clearer sections
> - clearly state which applications go with which categories, and
> which adjectives go with which applications.
>=20
> I'll also look into writing a short section on guidelines for how to
> properly extend or register new label components for future work.
>=20
> Comments and questions are appreciated.
>=20
> james
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From ari.keranen@nomadiclab.com  Wed Aug  1 16:35:28 2012
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2760911E840D for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 16:35:28 -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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay38WdGNHobj for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 16:35:27 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7032111E841B for <mmusic@ietf.org>; Wed,  1 Aug 2012 16:35:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 616554E6E9 for <mmusic@ietf.org>; Thu,  2 Aug 2012 02:35:25 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ek2qpi9OuDV for <mmusic@ietf.org>; Thu,  2 Aug 2012 02:35:24 +0300 (EEST)
Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 670434E67A for <mmusic@ietf.org>; Thu,  2 Aug 2012 02:35:24 +0300 (EEST)
Message-ID: <5019BD3A.6020907@nomadiclab.com>
Date: Wed, 01 Aug 2012 16:35:22 -0700
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 23:35:28 -0000

Folks,

Unfortunately there was not enough time to present the updated ICE 
address selection draft during the WG session today. You can still check 
out the slides from here:
http://tools.ietf.org/agenda/84/slides/slides-84-mmusic-7.pdf

And the draft here:
http://tools.ietf.org/html/draft-keranen-mmusic-ice-address-selection-01

The draft seems to be pretty mature, is fixing a known problem, and the 
MMUSIC WG is the obvious place to do the work, so WG adoption would be 
the natural next step.

Give the doc a quick read if you already haven't (it's only couple of 
pages), let us know if there's something to fix, and if you think it's a 
good idea, feel free to +1 for WG adoption.


Cheers,
Ari

From simon.perreault@viagenie.ca  Wed Aug  1 16:54:21 2012
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86CE21F8999 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 16:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level: 
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057,  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 pb5prIbyUUKT for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 16:54:21 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D35BD21F8995 for <mmusic@ietf.org>; Wed,  1 Aug 2012 16:54:20 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:34aa:41c2:abef:4aa7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B467B448B0 for <mmusic@ietf.org>; Wed,  1 Aug 2012 19:54:19 -0400 (EDT)
Message-ID: <5019C1AB.1030709@viagenie.ca>
Date: Wed, 01 Aug 2012 16:54:19 -0700
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5019BD3A.6020907@nomadiclab.com>
In-Reply-To: <5019BD3A.6020907@nomadiclab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 23:54:22 -0000

Le 2012-08-01 16:35, Ari Keranen a écrit :
> And the draft here:
> http://tools.ietf.org/html/draft-keranen-mmusic-ice-address-selection-01
>
> Give the doc a quick read if you already haven't (it's only couple of
> pages), let us know if there's something to fix, and if you think it's a
> good idea, feel free to +1 for WG adoption.

+1 for WG adoption

I just read the draft. It's simple, it makes sense, and it fixes a real 
bug in the ICE spec.

One comment:

>    o  Candidate addresses from Unique Local Addresses (ULAs) MUST NOT be
>       combined with any other candidates except other ULA candidates.

That would fail if you're behind an NPTv6 thingie that maps the ULA to a 
global prefix. So maybe remove that rule.

>    o  Local relayed candidates MUST NOT be combined with remote host
>       candidates from IPv4 private address space [RFC1918] or IPv6 link-
>       local addresses or ULAs.

Same comment here about the "or ULAs" part.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From ari.keranen@nomadiclab.com  Wed Aug  1 19:00:30 2012
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9B11E8175 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 19:00:30 -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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPxn9S9-jbqr for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 19:00:29 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73821F8769 for <mmusic@ietf.org>; Wed,  1 Aug 2012 19:00:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 714894E6EC; Thu,  2 Aug 2012 05:00:22 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbKAppH4F-HG; Thu,  2 Aug 2012 05:00:21 +0300 (EEST)
Received: from dhcp-4320.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id F2AF44E6EB; Thu,  2 Aug 2012 05:00:20 +0300 (EEST)
Message-ID: <5019DF32.80603@nomadiclab.com>
Date: Wed, 01 Aug 2012 19:00:18 -0700
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca>
In-Reply-To: <5019C1AB.1030709@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 02:00:30 -0000

Hi Simon,

Thanks for the review!

On 8/1/12 4:54 PM, Simon Perreault wrote:
> Le 2012-08-01 16:35, Ari Keranen a écrit :
>> And the draft here:
>> http://tools.ietf.org/html/draft-keranen-mmusic-ice-address-selection-01
>>
>> Give the doc a quick read if you already haven't (it's only couple of
>> pages), let us know if there's something to fix, and if you think it's a
>> good idea, feel free to +1 for WG adoption.
>
> +1 for WG adoption
>
> I just read the draft. It's simple, it makes sense, and it fixes a real
> bug in the ICE spec.
>
> One comment:
>
>> o Candidate addresses from Unique Local Addresses (ULAs) MUST NOT be
>> combined with any other candidates except other ULA candidates.
>
> That would fail if you're behind an NPTv6 thingie that maps the ULA to a
> global prefix. So maybe remove that rule.

(Without going into discussion why an NPTv6 thingie is probably a bad 
idea :) running STUN should give one the global address. Then, that 
address should be used instead of the ULA with peer's global addresses.


Cheers,
Ari

From simon.perreault@viagenie.ca  Wed Aug  1 21:58:33 2012
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72D421F8AD5 for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 21:58:33 -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 ucMFrEQVMr2n for <mmusic@ietfa.amsl.com>; Wed,  1 Aug 2012 21:58:33 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D49D221F8AD0 for <mmusic@ietf.org>; Wed,  1 Aug 2012 21:58:32 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:64:34aa:41c2:abef:4aa7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A41DE415E5; Thu,  2 Aug 2012 00:58:31 -0400 (EDT)
Message-ID: <501A08F4.9050609@viagenie.ca>
Date: Wed, 01 Aug 2012 21:58:28 -0700
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Ari Keranen <ari.keranen@nomadiclab.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com>
In-Reply-To: <5019DF32.80603@nomadiclab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 04:58:34 -0000

Le 2012-08-01 19:00, Ari Keranen a écrit :
>>> o Candidate addresses from Unique Local Addresses (ULAs) MUST NOT be
>>> combined with any other candidates except other ULA candidates.
>>
>> That would fail if you're behind an NPTv6 thingie that maps the ULA to a
>> global prefix. So maybe remove that rule.
>
> (Without going into discussion why an NPTv6 thingie is probably a bad
> idea :) running STUN should give one the global address. Then, that
> address should be used instead of the ULA with peer's global addresses.

Hmmm... Right so STUN will never give a ULA. The only time you will have 
a ULA candidate will be for host addresses. And you still want to try 
those matched with your peer's global addresses.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From palmarti@cisco.com  Thu Aug  2 05:33:58 2012
Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9321F8A1D for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 05:33:58 -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 gezhGt0gzh4w for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 05:33:57 -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 B28CC21F8A17 for <mmusic@ietf.org>; Thu,  2 Aug 2012 05:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1019; q=dns/txt; s=iport; t=1343910837; x=1345120437; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=reJsM5MgEsLWvAA6snwp+5OGwmYyVVAkI1RJ/wasqL0=; b=YGGrTcIIa/Vk/NCWWLwWqoxvTAcVE4PjHOqb/i6njUjc/5lVbcRc9Mhd kd5a3ksddQDMeWtUFDMW4YwSh8NB8ih/kxjPy/3yVFSD1calfaUYd96LJ rOjl+GDUfsDWTnw6T9fexRsu/JnPddmXF+V2tGNZOz2dIp7fZTrh5iMY3 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At0KAMpyGlCtJXG9/2dsb2JhbABFuAcEAn+BB4IgAQEBAgEBAQEBDwFbCwULAgEIRicLJQIEDgUih2UGC5xloDeLSYYkYAOIGI0vgRSNE4Fmgl8
X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208";a="104819854"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 02 Aug 2012 12:33:57 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72CXvsu003759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 12:33:57 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.184]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 07:33:57 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Ari Keranen <ari.keranen@nomadiclab.com>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdGyYIA
Date: Thu, 2 Aug 2012 12:33:56 +0000
Message-ID: <8F1FB666-2BC1-42A2-9D67-9E73E4C5FA79@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com>
In-Reply-To: <5019BD3A.6020907@nomadiclab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.154.69]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004
x-tm-as-result: No--38.479100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <201CD1EB07040B4D9ACE34F3AB2FCDDD@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 12:33:58 -0000

+1

.-.
P=E5l-Erik

On Aug 2, 2012, at 1:35 AM, Ari Keranen <ari.keranen@nomadiclab.com> wrote:

> Folks,
>=20
> Unfortunately there was not enough time to present the updated ICE addres=
s selection draft during the WG session today. You can still check out the =
slides from here:
> http://tools.ietf.org/agenda/84/slides/slides-84-mmusic-7.pdf
>=20
> And the draft here:
> http://tools.ietf.org/html/draft-keranen-mmusic-ice-address-selection-01
>=20
> The draft seems to be pretty mature, is fixing a known problem, and the M=
MUSIC WG is the obvious place to do the work, so WG adoption would be the n=
atural next step.
>=20
> Give the doc a quick read if you already haven't (it's only couple of pag=
es), let us know if there's something to fix, and if you think it's a good =
idea, feel free to +1 for WG adoption.
>=20
>=20
> Cheers,
> Ari
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From fandreas@cisco.com  Thu Aug  2 15:58:55 2012
Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C45F21E8047 for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 15:58:55 -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 Vz4xUNXvhrCR for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 15:58:54 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 94DFF21E8039 for <mmusic@ietf.org>; Thu,  2 Aug 2012 15:58:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=446; q=dns/txt; s=iport; t=1343948334; x=1345157934; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=gpQ6tN6OZSkkYW4sl0PSmSzs/8kLuxOTVnUmb+dtdRA=; b=HHqlJBgpudMTSgOji71H3oSzpuWT+DR4ZFPDiLZUFZlE4FpUoDRGGF0i vSK0O/skEWojERRw8h4R0cilvBK4OR6tCUvsqASO0FL7Pe+EWyOxKnOVf 6iyTUTQQQ/2TqIVMW7q9gC/O4qX8BcQRVKHaWicedcrY3p8u4k2g4+r4f Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAM8FG1CrRDoI/2dsb2JhbABFuRuBB4I5ASVAATwWGAMCAQIBTAwBBwEBHodqnQKgRpJOA5VHjieBZoJ7
X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="51355800"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 02 Aug 2012 22:58:51 +0000
Received: from bxb-vpn3-137.cisco.com (bxb-vpn3-137.cisco.com [10.86.248.137]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72MwnFc031319; Thu, 2 Aug 2012 22:58:50 GMT
Message-ID: <501B0629.3020903@cisco.com>
Date: Thu, 02 Aug 2012 18:58:49 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: zhou.sujing@zte.com.cn, tian.tian1@zte.com.cn, xie.zhenhua@zte.com.cn
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] IPR clarification on draft-zhou-mmusic-sdes-keymod-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 22:58:55 -0000

Dear authors of draft-zhou-mmusic-sdes-keymod-01

Following up on the presentation of the above draft in the MMUSIC WG 
yesterday, could each of you please confirm that you are not aware of 
any Intellectual Property Rights (IPR) associated with the above draft 
(in accordance with RFC 3979 and in particular in accordance with the 
procedures stated in Section 6.2.1 of RFC 3979)

Thanks

     Miguel and Flemming (MMUSIC co-chairs)



From christer.holmberg@ericsson.com  Thu Aug  2 16:32:02 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC8611E8129 for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 16:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.882
X-Spam-Level: 
X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 6lsbRh1RpVUA for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 16:32:02 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A511F11E80F0 for <mmusic@ietf.org>; Thu,  2 Aug 2012 16:32:01 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fd66d0000004ad-31-501b0df0a9c5
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.99.01197.0FD0B105; Fri,  3 Aug 2012 01:32:00 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 3 Aug 2012 01:32:00 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Date: Fri, 3 Aug 2012 01:31:59 +0200
Thread-Topic: Simultanous usage of a=rtcp and a=rtcp-mux
Thread-Index: AQHNcQNY0hgh5d0YIEer0pxA+0dG7g==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086835E5@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvre4HXukAg61tphZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuHr8QWbOCpm7brK1sB4nq2LkZNDQsBEonPjSmYIW0ziwr31 YHEhgVOMEsevhXYxcgHZ8xkl5nRvZOli5OBgE7CQ6P6nDVIjIqAu8XVvD1gvi4CKxOKt98Bs YQFjiQM/37FA1FhIHGu7xgph60k8vPwDLM4rEC7x5nYrmM0ItPf7qTVMIDazgLjErSfzmSDu EZBYsuc81G2iEi8f/2OFqBeVuNO+nhGiXk/ixtQpbBC2tsSyha+ZIeYLSpyc+YRlAqPwLCRj ZyFpmYWkZRaSlgWMLKsYhXMTM3PSyw31Uosyk4uL8/P0ilM3MQJD++CW37o7GE+dEznEKM3B oiTOy5W0319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY8gqhw3PDlxIc2k6+njKjSdHDOzF z83mnmcgfba7327d1x5Vk02N+f2Lwg7UXFGPPdgb/f/a09SmtrNrctsLWyZPba56cnvxhqqJ u52exTcklXOtzjMqfZUq0v5CkXdeR63vjy9/nkZqzvWMOur9P49Xme95+TOu7lfWgc9djwnI eDg9P3frlxJLcUaioRZzUXEiAJ6b37o7AgAA
Subject: [MMUSIC] Simultanous usage of a=rtcp and a=rtcp-mux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 23:32:02 -0000

Hi,

One of the issues which was raised during the MMUSIC BUNDLE presentation, b=
ut which is not BUNDLE specfic, was the case when an offer contains both a=
=3Drtcp and a=3Drtcp-mux.

A case where this can happen is ICE, which requires the inclusion of the a=
=3Drtcp attribute.

      "If the agent is utilizing RTCP, it MUST encode the RTCP candidate us=
ing the a=3Drtcp attribute as defined in RFC 3605 [RFC3605]." (RFC 5245/Sec=
tion 4.3)

Example:

m=3Daudio 20000
a=3Drtcp: 25000
a=3Drtcp-mux


Q: If the receiver supports both attributes, to which port would it send RT=
CP?

As indicated during the meeting, in theory this could be solved by using a=
=3Drtcp: 20000 (ie same port as RTP), but people indicated that it is not a=
llowed (eventhough not explicitly forbidden, afaik).

As also indicated, another way to solve this could be by saying: "If the re=
ceiver supports a=3Drtcp-mux, use that, otherwise use a=3Drtcp". But, I hav=
e not found any text which would support such intepretion.

Opinions?

Regards,

Christer


From pkyzivat@alum.mit.edu  Thu Aug  2 19:41:07 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9009311E8072 for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 19:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.221
X-Spam-Level: 
X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[AWL=-0.542,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_14=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 fR1EkGQNLbNm for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 19:41:07 -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 0128411E80A4 for <mmusic@ietf.org>; Thu,  2 Aug 2012 19:41:06 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id i2ex1j00B0QuhwU512h9nJ; Fri, 03 Aug 2012 02:41:09 +0000
Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:19d6:c06f:f140:d490]) by omta02.westchester.pa.mail.comcast.net with comcast id i2gu1j00E3NDGqc3N2gvm0; Fri, 03 Aug 2012 02:40:55 +0000
Message-ID: <501B3A40.9020403@alum.mit.edu>
Date: Thu, 02 Aug 2012 19:41:04 -0700
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A058534086835E5@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534086835E5@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Simultanous usage of a=rtcp and a=rtcp-mux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 02:41:07 -0000

On 8/2/12 4:31 PM, Christer Holmberg wrote:
> Hi,
>
> One of the issues which was raised during the MMUSIC BUNDLE presentation, but which is not BUNDLE specfic, was the case when an offer contains both a=rtcp and a=rtcp-mux.
>
> A case where this can happen is ICE, which requires the inclusion of the a=rtcp attribute.
>
>        "If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 [RFC3605]." (RFC 5245/Section 4.3)
>
> Example:
>
> m=audio 20000
> a=rtcp: 25000
> a=rtcp-mux
>
>
> Q: If the receiver supports both attributes, to which port would it send RTCP?
>
> As indicated during the meeting, in theory this could be solved by using a=rtcp: 20000 (ie same port as RTP), but people indicated that it is not allowed (eventhough not explicitly forbidden, afaik).
>
> As also indicated, another way to solve this could be by saying: "If the receiver supports a=rtcp-mux, use that, otherwise use a=rtcp". But, I have not found any text which would support such intepretion.

RFC 5761 says:

    If the answerer wishes to multiplex RTP and RTCP onto a single port,
    it MUST include a media-level "a=rtcp-mux" attribute in the answer.
    The RTP payload types used in the answer MUST conform to the rules in
    Section 4.

    If the answer does not contain an "a=rtcp-mux" attribute, the offerer
    MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
    it should send and receive RTCP on a port allocated according to the
    usual port-selection rules (either the port pair, or a signalled port
    if the "a=rtcp:" attribute [10] is also included).  This will occur
    when talking to a peer that does not understand the "a=rtcp-mux"
    attribute.

Seems pretty explicit to me. Also, I don't see how it could work 
otherwise and still obey the standard SDP backward compatibility rule 
for unknown attributes.

	Thanks,
	Paul

From xie.zhenhua@zte.com.cn  Thu Aug  2 20:00:31 2012
Return-Path: <xie.zhenhua@zte.com.cn>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4F11E80B8 for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 20:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.221
X-Spam-Level: 
X-Spam-Status: No, score=-95.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nfjPfJm6wzm for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 20:00:30 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1325111E80AE for <mmusic@ietf.org>; Thu,  2 Aug 2012 20:00:29 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723978252052; Fri, 3 Aug 2012 10:49:06 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 37953.1596979186; Fri, 3 Aug 2012 11:00:23 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7330DcB065756; Fri, 3 Aug 2012 11:00:13 +0800 (GMT-8) (envelope-from xie.zhenhua@zte.com.cn)
In-Reply-To: <501B0629.3020903@cisco.com>
To: Flemming Andreasen <fandreas@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF18DAD241.E26F52F5-ON48257A4F.000FEAC2-48257A4F.00107FE5@zte.com.cn>
From: xie.zhenhua@zte.com.cn
Date: Fri, 3 Aug 2012 10:59:32 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-03 11:00:04, Serialize complete at 2012-08-03 11:00:04
Content-Type: multipart/alternative; boundary="=_alternative 00107FE148257A4F_="
X-MAIL: mse02.zte.com.cn q7330DcB065756
X-Mailman-Approved-At: Thu, 02 Aug 2012 20:32:37 -0700
Cc: tian.tian1@zte.com.cn, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] IPR clarification on draft-zhou-mmusic-sdes-keymod-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 03:00:31 -0000

This is a multipart message in MIME format.
--=_alternative 00107FE148257A4F_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGksIEZsZW1taW5nIGFuZCBNTVVTSUMgZ3V5cw0KDQpBcyB0aGlzIGlzIGEgdGVhbSB3b3JrLCBw
ZXJhc29uYWxseSBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFzc29jaWF0ZWQgDQp3aXRoIHRo
ZSBhYm92ZSBkcmFmdC4NCg0KVGhhbmtzDQpCZXN0IHJlZ2FyZHMNCg0KWGllIFpoZW5odWEgICAg
ICDQu9Xxu6oNCqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqDQpTeXN0ZW0gQXJjaGl0
ZWN0dXJlIERlcHQuDQpaVEUgQ2VudHJhbCBSJkQNClRlbDogICArODYtMjUtNTI4NzEyODcNCkZh
eDogICArODYtMjUtNTI4NzEwMDANCqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqDQoN
Cg0KDQpGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbT4gDQoyMDEyLzA4LzAz
IDA2OjU4DQoNCsrVvP7Iyw0KemhvdS5zdWppbmdAenRlLmNvbS5jbiwgdGlhbi50aWFuMUB6dGUu
Y29tLmNuLCB4aWUuemhlbmh1YUB6dGUuY29tLmNuDQqzrcvNDQptbXVzaWMgPG1tdXNpY0BpZXRm
Lm9yZz4NCtb3zOINCklQUiBjbGFyaWZpY2F0aW9uIG9uIGRyYWZ0LXpob3UtbW11c2ljLXNkZXMt
a2V5bW9kLTAxDQoNCg0KDQoNCg0KDQpEZWFyIGF1dGhvcnMgb2YgZHJhZnQtemhvdS1tbXVzaWMt
c2Rlcy1rZXltb2QtMDENCg0KRm9sbG93aW5nIHVwIG9uIHRoZSBwcmVzZW50YXRpb24gb2YgdGhl
IGFib3ZlIGRyYWZ0IGluIHRoZSBNTVVTSUMgV0cgDQp5ZXN0ZXJkYXksIGNvdWxkIGVhY2ggb2Yg
eW91IHBsZWFzZSBjb25maXJtIHRoYXQgeW91IGFyZSBub3QgYXdhcmUgb2YgDQphbnkgSW50ZWxs
ZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyAoSVBSKSBhc3NvY2lhdGVkIHdpdGggdGhlIGFib3ZlIGRy
YWZ0IA0KKGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMzk3OSBhbmQgaW4gcGFydGljdWxhciBpbiBh
Y2NvcmRhbmNlIHdpdGggdGhlIA0KcHJvY2VkdXJlcyBzdGF0ZWQgaW4gU2VjdGlvbiA2LjIuMSBv
ZiBSRkMgMzk3OSkNCg0KVGhhbmtzDQoNCiAgICAgTWlndWVsIGFuZCBGbGVtbWluZyAoTU1VU0lD
IGNvLWNoYWlycykNCg0KDQoNCg0KDQo=
--=_alternative 00107FE148257A4F_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBGbGVtbWluZyBhbmQgTU1V
U0lDIGd1eXM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PkFzIHRoaXMgaXMgYSB0ZWFtIHdvcmssIHBlcmFzb25hbGx5DQpJIGFtIG5vdCBhd2FyZSBvZiBh
bnkgSVBSIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWJvdmUgZHJhZnQuPC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGFua3M8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkczxicj4NCjxicj4NClhpZSBaaGVu
aHVhICZuYnNwOyAmbmJzcDsgJm5ic3A70LvV8buqPGJyPg0KoaqhqqGqoaqhqqGqoaqhqqGqoaqh
qqGqoaqhqqGqoao8YnI+DQpTeXN0ZW0gQXJjaGl0ZWN0dXJlIERlcHQuPGJyPg0KWlRFIENlbnRy
YWwgUiZhbXA7RDxicj4NClRlbDogJm5ic3A7ICs4Ni0yNS01Mjg3MTI4Nzxicj4NCkZheDogJm5i
c3A7ICs4Ni0yNS01Mjg3MTAwMDxicj4NCqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGq
PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu
PXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkZs
ZW1taW5nIEFuZHJlYXNlbiAmbHQ7ZmFuZHJlYXNAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9udD4N
CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLzA4LzAzIDA2OjU4PC9mb250
Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8
dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+
yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24sIHRpYW4udGlhbjFAenRlLmNvbS5jbiwNCnhpZS56aGVuaHVhQHp0
ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+
PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv
bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1tdXNpYyAmbHQ7bW11c2ljQGlldGYub3JnJmd0
OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz
aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl
PTEgZmFjZT0ic2Fucy1zZXJpZiI+SVBSIGNsYXJpZmljYXRpb24gb24gZHJhZnQtemhvdS1tbXVz
aWMtc2Rlcy1rZXltb2QtMDE8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp
Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTI+PHR0PkRlYXIgYXV0aG9ycyBvZiBkcmFmdC16aG91LW1tdXNpYy1zZGVz
LWtleW1vZC0wMTxicj4NCjxicj4NCkZvbGxvd2luZyB1cCBvbiB0aGUgcHJlc2VudGF0aW9uIG9m
IHRoZSBhYm92ZSBkcmFmdCBpbiB0aGUgTU1VU0lDIFdHIDxicj4NCnllc3RlcmRheSwgY291bGQg
ZWFjaCBvZiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCB5b3UgYXJlIG5vdCBhd2FyZSBvZiA8YnI+
DQphbnkgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyAoSVBSKSBhc3NvY2lhdGVkIHdpdGgg
dGhlIGFib3ZlIGRyYWZ0DQo8YnI+DQooaW4gYWNjb3JkYW5jZSB3aXRoIFJGQyAzOTc5IGFuZCBp
biBwYXJ0aWN1bGFyIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgPGJyPg0KcHJvY2VkdXJlcyBzdGF0
ZWQgaW4gU2VjdGlvbiA2LjIuMSBvZiBSRkMgMzk3OSk8YnI+DQo8YnI+DQpUaGFua3M8YnI+DQo8
YnI+DQogJm5ic3A7ICZuYnNwOyBNaWd1ZWwgYW5kIEZsZW1taW5nIChNTVVTSUMgY28tY2hhaXJz
KTxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K
--=_alternative 00107FE148257A4F_=--


From tian.tian1@zte.com.cn  Thu Aug  2 20:15:52 2012
Return-Path: <tian.tian1@zte.com.cn>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B058811E80B8 for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 20:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.301
X-Spam-Level: 
X-Spam-Status: No, score=-91.301 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHc80jFjHjSI for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 20:15:52 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id ACB4011E80AE for <mmusic@ietf.org>; Thu,  2 Aug 2012 20:15:51 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723978252052; Fri, 3 Aug 2012 11:04:32 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 23705.1596979186; Fri, 3 Aug 2012 11:15:34 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q733FdZQ099221; Fri, 3 Aug 2012 11:15:39 +0800 (GMT-8) (envelope-from tian.tian1@zte.com.cn)
In-Reply-To: <501B0629.3020903@cisco.com>
To: Flemming Andreasen <fandreas@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF0E1DFADF.1D22F42F-ON48257A4F.00119898-48257A4F.0011E8DA@zte.com.cn>
From: tian.tian1@zte.com.cn
Date: Fri, 3 Aug 2012 11:15:12 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-03 11:15:30, Serialize complete at 2012-08-03 11:15:30
Content-Type: multipart/alternative; boundary="=_alternative 0011E8D748257A4F_="
X-MAIL: mse01.zte.com.cn q733FdZQ099221
X-Mailman-Approved-At: Thu, 02 Aug 2012 20:32:37 -0700
Cc: xie.zhenhua@zte.com.cn, mmusic <mmusic@ietf.org>
Subject: [MMUSIC] =?gb2312?b?tPC4tDogSVBSIGNsYXJpZmljYXRpb24gb24gZHJhZnQt?= =?gb2312?b?emhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDE=?=
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 03:15:52 -0000

This is a multipart message in MIME format.
--=_alternative 0011E8D748257A4F_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

RGVhciBGbGVtaW5nIGFuZCBkZWFyIGFsbCwNCg0KSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFz
c29jaWF0ZWQgd2l0aCB0aGUgZHJhZnQgDQpkcmFmdC16aG91LW1tdXNpYy1zZGVzLWtleW1vZC0w
MS4NClRoYW5rcw0KDQpCUiwNClRpYW4NCg0KDQoNCg0KRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5k
cmVhc0BjaXNjby5jb20+IA0KMjAxMi0wOC0wMyAwNjo1OA0KDQrK1bz+yMsNCnpob3Uuc3VqaW5n
QHp0ZS5jb20uY24sIHRpYW4udGlhbjFAenRlLmNvbS5jbiwgeGllLnpoZW5odWFAenRlLmNvbS5j
bg0Ks63LzQ0KbW11c2ljIDxtbXVzaWNAaWV0Zi5vcmc+DQrW98ziDQpJUFIgY2xhcmlmaWNhdGlv
biBvbiBkcmFmdC16aG91LW1tdXNpYy1zZGVzLWtleW1vZC0wMQ0KDQoNCg0KDQoNCg0KRGVhciBh
dXRob3JzIG9mIGRyYWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAxDQoNCkZvbGxvd2luZyB1
cCBvbiB0aGUgcHJlc2VudGF0aW9uIG9mIHRoZSBhYm92ZSBkcmFmdCBpbiB0aGUgTU1VU0lDIFdH
IA0KeWVzdGVyZGF5LCBjb3VsZCBlYWNoIG9mIHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IHlvdSBh
cmUgbm90IGF3YXJlIG9mIA0KYW55IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQUikg
YXNzb2NpYXRlZCB3aXRoIHRoZSBhYm92ZSBkcmFmdCANCihpbiBhY2NvcmRhbmNlIHdpdGggUkZD
IDM5NzkgYW5kIGluIHBhcnRpY3VsYXIgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSANCnByb2NlZHVy
ZXMgc3RhdGVkIGluIFNlY3Rpb24gNi4yLjEgb2YgUkZDIDM5NzkpDQoNClRoYW5rcw0KDQogICAg
IE1pZ3VlbCBhbmQgRmxlbW1pbmcgKE1NVVNJQyBjby1jaGFpcnMpDQoNCg0KDQoNCg0KDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa
VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp
cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj
bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k
ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g
b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls
IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoN
Cg==
--=_alternative 0011E8D748257A4F_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgRmxlbWluZyBhbmQgZGVh
ciBhbGwsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5J
J20gbm90IGF3YXJlIG9mIGFueSBJUFIgYXNzb2NpYXRlZA0Kd2l0aCB0aGUgZHJhZnQgZHJhZnQt
emhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDEuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPkJSLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp
ZiI+VGlhbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAl
Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5z
LXNlcmlmIj48Yj5GbGVtbWluZyBBbmRyZWFzZW4gJmx0O2ZhbmRyZWFzQGNpc2NvLmNvbSZndDs8
L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0w
MyAwNjo1ODwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2
YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z
LXNlcmlmIj56aG91LnN1amluZ0B6dGUuY29tLmNuLCB0aWFuLnRpYW4xQHp0ZS5jb20uY24sDQp4
aWUuemhlbmh1YUB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2
IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv
ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5tbXVzaWMgJmx0O21tdXNp
Y0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249
cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8
dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPklQUiBjbGFyaWZpY2F0aW9uIG9uIGRy
YWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAxPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi
bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8
YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5EZWFyIGF1dGhvcnMgb2YgZHJhZnQtemhv
dS1tbXVzaWMtc2Rlcy1rZXltb2QtMDE8YnI+DQo8YnI+DQpGb2xsb3dpbmcgdXAgb24gdGhlIHBy
ZXNlbnRhdGlvbiBvZiB0aGUgYWJvdmUgZHJhZnQgaW4gdGhlIE1NVVNJQyBXRyA8YnI+DQp5ZXN0
ZXJkYXksIGNvdWxkIGVhY2ggb2YgeW91IHBsZWFzZSBjb25maXJtIHRoYXQgeW91IGFyZSBub3Qg
YXdhcmUgb2YgPGJyPg0KYW55IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQUikgYXNz
b2NpYXRlZCB3aXRoIHRoZSBhYm92ZSBkcmFmdA0KPGJyPg0KKGluIGFjY29yZGFuY2Ugd2l0aCBS
RkMgMzk3OSBhbmQgaW4gcGFydGljdWxhciBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIDxicj4NCnBy
b2NlZHVyZXMgc3RhdGVkIGluIFNlY3Rpb24gNi4yLjEgb2YgUkZDIDM5NzkpPGJyPg0KPGJyPg0K
VGhhbmtzPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgTWlndWVsIGFuZCBGbGVtbWluZyAoTU1V
U0lDIGNvLWNoYWlycyk8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4N
Cjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3Rp
Y2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNw
O3RoaXMmbmJzcDttYWlsJm5ic3A7KGFuZCZuYnNwO2FueSZuYnNwO2F0dGFjaG1lbnQmbmJzcDt0
cmFuc21pdHRlZCZuYnNwO2hlcmV3aXRoKSZuYnNwO2lzJm5ic3A7cHJpdmlsZWdlZCZuYnNwO2Fu
ZCZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2lzJm5ic3A7aW50ZW5kZWQmbmJzcDtm
b3ImbmJzcDt0aGUmbmJzcDtleGNsdXNpdmUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNw
O2FkZHJlc3NlZShzKS4mbmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO25vdCZu
YnNwO2FuJm5ic3A7aW50ZW5kZWQmbmJzcDtyZWNpcGllbnQsJm5ic3A7YW55Jm5ic3A7ZGlzY2xv
c3VyZSwmbmJzcDtyZXByb2R1Y3Rpb24sJm5ic3A7ZGlzdHJpYnV0aW9uJm5ic3A7b3ImbmJzcDtv
dGhlciZuYnNwO2Rpc3NlbWluYXRpb24mbmJzcDtvciZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl
Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpcyZuYnNwO3N0cmljdGx5Jm5i
c3A7cHJvaGliaXRlZC4mbmJzcDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl
aXZlZCZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aW4mbmJzcDtlcnJvciwmbmJzcDtwbGVhc2Um
bmJzcDtkZWxldGUmbmJzcDtpdCZuYnNwO2FuZCZuYnNwO25vdGlmeSZuYnNwO3VzJm5ic3A7aW1t
ZWRpYXRlbHkuDQoNCjwvcHJlPg==
--=_alternative 0011E8D748257A4F_=--


From pkyzivat@alum.mit.edu  Thu Aug  2 23:33:19 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673D621E8041 for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 23:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.566
X-Spam-Level: 
X-Spam-Status: No, score=0.566 tagged_above=-999 required=5 tests=[AWL=-0.797,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=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 1N03nHSjwBBi for <mmusic@ietfa.amsl.com>; Thu,  2 Aug 2012 23:33:18 -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 4C52821E8039 for <mmusic@ietf.org>; Thu,  2 Aug 2012 23:33:10 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id i6XY1j0020QuhwU516ZC1k; Fri, 03 Aug 2012 06:33:12 +0000
Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:19d6:c06f:f140:d490]) by omta02.westchester.pa.mail.comcast.net with comcast id i6Yu1j0093NDGqc3N6YvJw; Fri, 03 Aug 2012 06:32:58 +0000
Message-ID: <501B70A0.5000507@alum.mit.edu>
Date: Thu, 02 Aug 2012 23:33:04 -0700
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>
In-Reply-To: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 06:33:20 -0000

Jonathan,

This proposal is interesting.

IIUC, if answerer supports and accepts the bundle, then everything from 
the other bundled m-lines is ignored. Right?

If so, then *everything* that would have been specified in each of those 
media sections is ignored, and must be restated after the bundle m-line. 
But isn't one of the points of this allow separate settings for things 
per-m-line? The directionality is one of those things that you mention, 
but there are lots of others. I think we decided there were at least 
three categories:
- those that are independent for each bundled media sections
- those that are summed across all the bundled media sections
- those that are the max across each of the bundled media sections
- (are there other possibilities?)

Clearly your proposal can handle those that are summed, and those where 
the max is used. But not those that are independent. (The directionality 
attributes are an example that you mentioned.)

A potential alternative would be for the answer to reject the bundled 
m-lines other than m=bundle, but then both sides would still honor the 
attributes and other things from the rejected bundled m-lines. But this 
might not be feasible, since I think there is a normative requirement in 
O/A to ignore all the stuff from rejected m-lines.

Another possibility: your proposal is starting to smell a bit like 
cap-neg. Maybe we could make cap-neg serve for this.

	Thanks,
	Paul

On 8/1/12 11:56 AM, Jonathan Lennox wrote:
> As I mentioned at the mic, BUNDLE currently generates an implicit combined description of the bundled RTP session, and a lot of the problems and standardization issues we're having relate to the fact that the bundled session's media description is implicit.  Therefore, you need a lot of language specifying when parts of bundled m=lines must be the same, when they must be different, and when they may be independent.  Such specifications would need to be defined for every existing SDP attribute used in offer-answer, and every new SDP attribute going forward.
>
> The alternative to having an implicit description, I think, would be to have an explicit description.  The basic idea is to have a new m-line representing the bundled session explicitly, defined in a way that a non-bundle-aware endpoint should see it as an unknown type of m-line and reject it.  The BUNDLE grouping semantic then says that you either use all the traditional m-lines, rejecting the bundled one, or you use the one bundled m-line, rejecting all the others.
>
> As a straw man example, a variant of bundle-negotiation-00's example offer with ICE:
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>         t=0 0
>         a=group:BUNDLE foo bar baz
>         m=audio 10000 RTP/AVP 0 8 97
>         a=mid:foo
>         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
>         m=video 10002 RTP/AVP 31 32
>         a=mid:bar
>         b=AS:1000
>         a=rtpmap:31 H261/90000
>         a=rtpmap:32 MPV/90000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
>         m=bundle 10000 RTP/AVP 0 8 97 31 32
>         a=mid:baz
>         b=AS:1200
>         a=full-rtpmap:0 audio/PCMU/8000
>         a=full-rtpmap:8 audio/PCMA/8000
>         a=full-rtpmap:97 audio/iLBC/8000
>         a=full-rtpmap:31 video/H261/90000
>         a=full-rtpmap:32 video/MPV/90000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>
> Points to note:
>
> * Outside the m=bundle line and its attributes, this is entirely current-standard SDP.
>
> * The m=bundle is a complete description of an entirely separate m-line; if it's used, the other m-lines in the group are rejected and the information they carry is ignored.
>
> * We'll need to make sure that we have a syntax for this new m-line (what I've called m=bundle) that existing implementations will reject (with port 0), rather than interpreting as an SDP syntax error.  We'll need input from interop people to know what's safe to do here.
>
> * The ports and ICE candidates specified in the m=bundle line are entirely up to the whim of the offerer; they may overlap with one of the other m-lines, but don't have to.
>
> * Because the media type of the payload types isn't given by the m-line, we need new syntax to specify the top-level media type.  I've called this "full-rtpmap", but this is just a strawman.
>
> * Because there's one list of payload types, the RFC 3264 payload preference order needs a bit of finessing. I'd suggest saying that the preference order should be interpreted independently per media type.
>
> * There's obviously no way to do a=sendonly/recvonly independently for audio and video; you'd need to do it on the source level, with (if you're doing it in SDP) something like my source-selection draft.
>
> * There's an obvious syntax to send an offer that means "support BUNDLE, or fail" -- just send the m=bundle line, without the grouped independent lines.  Whether we'd want to allow such an offer is a separate question.
>
> --
> Jonathan Lennox
> jonathan@vidyo.com
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From miguel.a.garcia@ericsson.com  Fri Aug  3 07:27:27 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1922721F8D06 for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 07:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.214
X-Spam-Level: 
X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035,  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 p3wP0CfG0V62 for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 07:27:26 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4121F8D15 for <mmusic@ietf.org>; Fri,  3 Aug 2012 07:27:26 -0700 (PDT)
X-AuditID: c1b4fb25-b7f236d000005cde-05-501bdfccb999
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1A.FF.23774.CCFDB105; Fri,  3 Aug 2012 16:27:25 +0200 (CEST)
Received: from [159.107.48.10] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Fri, 3 Aug 2012 16:27:22 +0200
Message-ID: <501BDFC6.6070600@ericsson.com>
Date: Fri, 3 Aug 2012 16:27:18 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvre7Z+9IBBrcOcFu8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2Pd+omsBSuYKl7syWhg/MzYxcjJISFgIvFm zVJmCFtM4sK99WxdjFwcQgKnGCXOPPnLBOGsYpTYMO8ZWBWvgLZEw/OZrCA2i4CKxL2la9lB bDYBc4nWjRvBbFGBQInns7ewQ9QLSpyc+YQFxBYRkJHYu2kz2BxmoDmz78xiArGFBWwkfkz7 ygIRt5W4MOc6lC0vsf3tHLB6IQFNick3lzJPYOSfhWTsLCQts5C0LGBkXsUonJuYmZNebqSX WpSZXFycn6dXnLqJERh4B7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUw5ssG586Q1Xh19e5v+7xrLmqSz+//uPHCpHL7iRnBu0q/KKcKuDD6V6069zQo tUmslWH+jmVmbl+LLSrcrnbEX2NeODlHjJPFr17bOoBTU6CTrzHi9+WpH9fzN+euPRi488PT F48VdGL/bu7ZI/B16svabm0fu+l7p1gKn1j8kbVIW2eHq9gLJZbijERDLeai4kQAOqnfWAoC AAA=
Cc: Flemming Andreasen <fandreas@cisco.com>
Subject: [MMUSIC] Minutes of the MMUSIC meeting at IETF 84, Vancouver
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 14:27:27 -0000

The minutes of the MMUSIC meeting at IETF 84 in Vancouver are already 
uploaded to the Meeting Materials web site:

http://www.ietf.org/proceedings/84/minutes/minutes-84-mmusic

Please review and comment them.

/Flemming and Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From zhou.sujing@zte.com.cn  Fri Aug  3 09:43:02 2012
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817B621F8E6F for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 09:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.97
X-Spam-Level: 
X-Spam-Status: No, score=-92.97 tagged_above=-999 required=5 tests=[AWL=-2.039, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rglqlu1-4au for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 09:43:02 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5FC21F8E4C for <mmusic@ietf.org>; Fri,  3 Aug 2012 09:43:00 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723978252052; Sat, 4 Aug 2012 00:31:33 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 2435.1596979186; Sat, 4 Aug 2012 00:42:40 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q73GgqCR074039; Sat, 4 Aug 2012 00:42:52 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <501B0629.3020903@cisco.com>
To: Flemming Andreasen <fandreas@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFDF78C7D4.3E6C916E-ON48257A4F.005BA228-48257A4F.005BCF10@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Sat, 4 Aug 2012 00:42:35 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-04 00:42:44, Serialize complete at 2012-08-04 00:42:44
Content-Type: multipart/alternative; boundary="=_alternative 005BCF0D48257A4F_="
X-MAIL: mse01.zte.com.cn q73GgqCR074039
Cc: xie.zhenhua@zte.com.cn, tian.tian1@zte.com.cn, mmusic <mmusic@ietf.org>
Subject: [MMUSIC] =?gb2312?b?tPC4tDogSVBSIGNsYXJpZmljYXRpb24gb24gZHJhZnQt?= =?gb2312?b?emhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDE=?=
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 16:43:02 -0000

This is a multipart message in MIME format.
--=_alternative 005BCF0D48257A4F_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGksQWxsIA0KICBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFzc29jaWF0ZWQgd2l0aCB0aGlz
IGRyYWZ0IGFzIEmhoWhhdmUgc3RhdGVkIA0KYXQgdGhlIG1lZXRpbmcuDQpSZWdhcmRzfn5+DQoN
Ci1TdWppbmcgWmhvdQ0KDQoNCg0KRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5j
b20+IA0KMjAxMi8wOC8wMyAwNjo1OA0KDQrK1bz+yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24s
IHRpYW4udGlhbjFAenRlLmNvbS5jbiwgeGllLnpoZW5odWFAenRlLmNvbS5jbg0Ks63LzQ0KbW11
c2ljIDxtbXVzaWNAaWV0Zi5vcmc+DQrW98ziDQpJUFIgY2xhcmlmaWNhdGlvbiBvbiBkcmFmdC16
aG91LW1tdXNpYy1zZGVzLWtleW1vZC0wMQ0KDQoNCg0KDQoNCg0KRGVhciBhdXRob3JzIG9mIGRy
YWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAxDQoNCkZvbGxvd2luZyB1cCBvbiB0aGUgcHJl
c2VudGF0aW9uIG9mIHRoZSBhYm92ZSBkcmFmdCBpbiB0aGUgTU1VU0lDIFdHIA0KeWVzdGVyZGF5
LCBjb3VsZCBlYWNoIG9mIHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IHlvdSBhcmUgbm90IGF3YXJl
IG9mIA0KYW55IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQUikgYXNzb2NpYXRlZCB3
aXRoIHRoZSBhYm92ZSBkcmFmdCANCihpbiBhY2NvcmRhbmNlIHdpdGggUkZDIDM5NzkgYW5kIGlu
IHBhcnRpY3VsYXIgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSANCnByb2NlZHVyZXMgc3RhdGVkIGlu
IFNlY3Rpb24gNi4yLjEgb2YgUkZDIDM5NzkpDQoNClRoYW5rcw0KDQogICAgIE1pZ3VlbCBhbmQg
RmxlbW1pbmcgKE1NVVNJQyBjby1jaGFpcnMpDQoNCg0KDQoNCg0K
--=_alternative 005BCF0D48257A4F_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLEFsbCA8L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIGFtIG5vdCBhd2FyZSBvZiBh
bnkgSVBSIGFzc29jaWF0ZWQNCndpdGggdGhpcyBkcmFmdCBhcyBJoaFoYXZlIHN0YXRlZCBhdCB0
aGUgbWVldGluZy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJl
Z2FyZHN+fn48YnI+DQo8YnI+DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+
DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RmxlbW1pbmcgQW5kcmVhc2VuICZsdDtmYW5k
cmVhc0BjaXNjby5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPjIwMTIvMDgvMDMgMDY6NTg8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxl
IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv
bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhvdS5zdWppbmdAenRlLmNvbS5jbiwgdGlhbi50
aWFuMUB6dGUuY29tLmNuLA0KeGllLnpoZW5odWFAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxp
Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z
ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp
ZiI+bW11c2ljICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+
DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W
98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5JUFIg
Y2xhcmlmaWNhdGlvbiBvbiBkcmFmdC16aG91LW1tdXNpYy1zZGVzLWtleW1vZC0wMTwvZm9udD48
L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs
ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+RGVhciBh
dXRob3JzIG9mIGRyYWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAxPGJyPg0KPGJyPg0KRm9s
bG93aW5nIHVwIG9uIHRoZSBwcmVzZW50YXRpb24gb2YgdGhlIGFib3ZlIGRyYWZ0IGluIHRoZSBN
TVVTSUMgV0cgPGJyPg0KeWVzdGVyZGF5LCBjb3VsZCBlYWNoIG9mIHlvdSBwbGVhc2UgY29uZmly
bSB0aGF0IHlvdSBhcmUgbm90IGF3YXJlIG9mIDxicj4NCmFueSBJbnRlbGxlY3R1YWwgUHJvcGVy
dHkgUmlnaHRzIChJUFIpIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWJvdmUgZHJhZnQNCjxicj4NCihp
biBhY2NvcmRhbmNlIHdpdGggUkZDIDM5NzkgYW5kIGluIHBhcnRpY3VsYXIgaW4gYWNjb3JkYW5j
ZSB3aXRoIHRoZSA8YnI+DQpwcm9jZWR1cmVzIHN0YXRlZCBpbiBTZWN0aW9uIDYuMi4xIG9mIFJG
QyAzOTc5KTxicj4NCjxicj4NClRoYW5rczxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7IE1pZ3Vl
bCBhbmQgRmxlbW1pbmcgKE1NVVNJQyBjby1jaGFpcnMpPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PC90dD48L2ZvbnQ+DQo8YnI+DQo=
--=_alternative 005BCF0D48257A4F_=--


From christer.holmberg@ericsson.com  Fri Aug  3 11:54:57 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2321F8DBA for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 11:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.277
X-Spam-Level: 
X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPbZUrtDhJcH for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 11:54:56 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9942321F8D9D for <mmusic@ietf.org>; Fri,  3 Aug 2012 11:54:54 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fd66d0000004ad-c2-501c1e7d26c5
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 39.D5.01197.D7E1C105; Fri,  3 Aug 2012 20:54:53 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 3 Aug 2012 20:54:53 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Fri, 3 Aug 2012 20:54:52 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac1xQeMAOq/xcN7sQxWbf/5GiHpQ8gAZgqb4
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086835F5@ESESSCMS0356.eemea.ericsson.se>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>, <501B70A0.5000507@alum.mit.edu>
In-Reply-To: <501B70A0.5000507@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW6tnEyAQct6KYupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo3dDPXHDSoGJbfzdLA+Mb1S5GTg4JAROJ C4fXsULYYhIX7q1n62Lk4hASOMUoMfXzAhYIZz6jxOOGmYxdjBwcbAIWEt3/tEEaRAR8JZ49 vs0GYrMIqEj8/DUBzBYWiJdYsW0pM0RNgsSuSWsZIWwjiQV9p8DivALhEt9fnwZbLCQQI3Hk TQ87iM0poCMxZctzsDgj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9B1YtK3Glf zwhRryOxYPcnNghbW2LZwtdQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenl hnqpRZnJxcX5eXrFqZsYgTFycMtv3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFRvGyb9t2HD+t1+n6wOk3MW3Cq5mHPNfePeqvnL9H+XhacxtW+aJrZ5pQ3 D2fyJ6leKloU8LluZruF32Tj6oWF/aonyp6HhnVXmb1+t+7QtMbGMypch9aFVl1evSso7Hdc 7N+tN3I9L/Js1+ta/nqxkuL3HzN2/pp8xSAnUPEKa+feu/ttlIPTlFiKMxINtZiLihMBKSpY 7F8CAAA=
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 18:54:57 -0000

Hi,

> This proposal is interesting.
>
> IIUC, if answerer supports and accepts the bundle, then everything from
> the other bundled m-lines is ignored. Right?
>
> If so, then *everything* that would have been specified in each of those
> media sections is ignored, and must be restated after the bundle m-line.
>
> But isn't one of the points of this allow separate settings for things
> per-m-line? The directionality is one of those things that you mention,
> but there are lots of others. I think we decided there were at least
> three categories:
> - those that are independent for each bundled media sections
> - those that are summed across all the bundled media sections
> - those that are the max across each of the bundled media sections
> - (are there other possibilities?)
>
> Clearly your proposal can handle those that are summed, and those where
> the max is used. But not those that are independent. (The directionality
> attributes are an example that you mentioned.)
>
> A potential alternative would be for the answer to reject the bundled
> m-lines other than m=3Dbundle, but then both sides would still honor the
> attributes and other things from the rejected bundled m-lines. But this
> might not be feasible, since I think there is a normative requirement in
> O/A to ignore all the stuff from rejected m-lines.

I am not sure whether there is such requirement, but I guess it depends on =
how one reads the spec and how you define "ignore" :)

But, it IS an issue that we need to think about, whether we "duplicate" inf=
ormation into the m=3Dbundle line, or whether we
can "reference" information in the other m=3D lines (even if their ports ar=
e set to zero).

In any case I do think that we will need SOME information in the m=3Dbundle=
 line, e.g. information that intermedairies need (bandwidth etc

Regards,

Christer




On 8/1/12 11:56 AM, Jonathan Lennox wrote:
> As I mentioned at the mic, BUNDLE currently generates an implicit combine=
d description of the bundled RTP session, and a lot of the problems and sta=
ndardization issues we're having relate to the fact that the bundled sessio=
n's media description is implicit.  Therefore, you need a lot of language s=
pecifying when parts of bundled m=3Dlines must be the same, when they must =
be different, and when they may be independent.  Such specifications would =
need to be defined for every existing SDP attribute used in offer-answer, a=
nd every new SDP attribute going forward.
>
> The alternative to having an implicit description, I think, would be to h=
ave an explicit description.  The basic idea is to have a new m-line repres=
enting the bundled session explicitly, defined in a way that a non-bundle-a=
ware endpoint should see it as an unknown type of m-line and reject it.  Th=
e BUNDLE grouping semantic then says that you either use all the traditiona=
l m-lines, rejecting the bundled one, or you use the one bundled m-line, re=
jecting all the others.
>
> As a straw man example, a variant of bundle-negotiation-00's example offe=
r with ICE:
>
>         v=3D0
>         o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=3D
>         c=3DIN IP4 host.atlanta.com
>         t=3D0 0
>         a=3Dgroup:BUNDLE foo bar baz
>         m=3Daudio 10000 RTP/AVP 0 8 97
>         a=3Dmid:foo
>         b=3DAS:200
>         a=3Drtpmap:0 PCMU/8000
>         a=3Drtpmap:8 PCMA/8000
>         a=3Drtpmap:97 iLBC/8000
>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>         m=3Dvideo 10002 RTP/AVP 31 32
>         a=3Dmid:bar
>         b=3DAS:1000
>         a=3Drtpmap:31 H261/90000
>         a=3Drtpmap:32 MPV/90000
>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
>         m=3Dbundle 10000 RTP/AVP 0 8 97 31 32
>         a=3Dmid:baz
>         b=3DAS:1200
>         a=3Dfull-rtpmap:0 audio/PCMU/8000
>         a=3Dfull-rtpmap:8 audio/PCMA/8000
>         a=3Dfull-rtpmap:97 audio/iLBC/8000
>         a=3Dfull-rtpmap:31 video/H261/90000
>         a=3Dfull-rtpmap:32 video/MPV/90000
>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>
> Points to note:
>
> * Outside the m=3Dbundle line and its attributes, this is entirely curren=
t-standard SDP.
>
> * The m=3Dbundle is a complete description of an entirely separate m-line=
; if it's used, the other m-lines in the group are rejected and the informa=
tion they carry is ignored.
>
> * We'll need to make sure that we have a syntax for this new m-line (what=
 I've called m=3Dbundle) that existing implementations will reject (with po=
rt 0), rather than interpreting as an SDP syntax error.  We'll need input f=
rom interop people to know what's safe to do here.
>
> * The ports and ICE candidates specified in the m=3Dbundle line are entir=
ely up to the whim of the offerer; they may overlap with one of the other m=
-lines, but don't have to.
>
> * Because the media type of the payload types isn't given by the m-line, =
we need new syntax to specify the top-level media type.  I've called this "=
full-rtpmap", but this is just a strawman.
>
> * Because there's one list of payload types, the RFC 3264 payload prefere=
nce order needs a bit of finessing. I'd suggest saying that the preference =
order should be interpreted independently per media type.
>
> * There's obviously no way to do a=3Dsendonly/recvonly independently for =
audio and video; you'd need to do it on the source level, with (if you're d=
oing it in SDP) something like my source-selection draft.
>
> * There's an obvious syntax to send an offer that means "support BUNDLE, =
or fail" -- just send the m=3Dbundle line, without the grouped independent =
lines.  Whether we'd want to allow such an offer is a separate question.
>
> --
> 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=

From ari.keranen@nomadiclab.com  Fri Aug  3 11:58:05 2012
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B721F8E06 for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 11:58:05 -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 Oh1fBJ+gr6lm for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 11:58:04 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 647B921F8DD4 for <mmusic@ietf.org>; Fri,  3 Aug 2012 11:58:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B9DCF4E6F0; Fri,  3 Aug 2012 21:58:02 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwIIAeagW--5; Fri,  3 Aug 2012 21:58:02 +0300 (EEST)
Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id B6DE24E6F1; Fri,  3 Aug 2012 21:58:01 +0300 (EEST)
Message-ID: <501C1F38.8050307@nomadiclab.com>
Date: Fri, 03 Aug 2012 11:58:00 -0700
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca>
In-Reply-To: <501A08F4.9050609@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 18:58:05 -0000

On 8/1/12 9:58 PM, Simon Perreault wrote:
> Le 2012-08-01 19:00, Ari Keranen a écrit :
>>>> o Candidate addresses from Unique Local Addresses (ULAs) MUST NOT be
>>>> combined with any other candidates except other ULA candidates.
>>>
>>> That would fail if you're behind an NPTv6 thingie that maps the ULA to a
>>> global prefix. So maybe remove that rule.
>>
>> (Without going into discussion why an NPTv6 thingie is probably a bad
>> idea :) running STUN should give one the global address. Then, that
>> address should be used instead of the ULA with peer's global addresses.
>
> Hmmm... Right so STUN will never give a ULA. The only time you will have
> a ULA candidate will be for host addresses. And you still want to try
> those matched with your peer's global addresses.

Yes, you should not get ULAs from the STUN server as long as the STUN 
server is properly located (on the Internet, outside of the organization 
perimeter and on the other side of any NATs). And the peer reflexive 
candidate (which would be global address) can be then matched with 
peer's globals.


Cheers,
Ari

From ari.keranen@nomadiclab.com  Fri Aug  3 12:01:35 2012
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F56A21F8D8D for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 12:01:35 -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 iut564BI+MC6 for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 12:01:35 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id DBA3421F8DAE for <mmusic@ietf.org>; Fri,  3 Aug 2012 12:01:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 302844E6F1; Fri,  3 Aug 2012 22:01:32 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0YydcWgYMGW; Fri,  3 Aug 2012 22:01:31 +0300 (EEST)
Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 3D7114E6F0; Fri,  3 Aug 2012 22:01:31 +0300 (EEST)
Message-ID: <501C2009.8090306@nomadiclab.com>
Date: Fri, 03 Aug 2012 12:01:29 -0700
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com>
In-Reply-To: <501C1F38.8050307@nomadiclab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 19:01:35 -0000

On 8/3/12 11:58 AM, Ari Keranen wrote:
> And the peer reflexive candidate

...meant to say "server reflexive candidate"

From simon.perreault@viagenie.ca  Fri Aug  3 12:03:42 2012
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F8121F8D5A for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 12:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052,  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 z9gvJAjTczLm for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 12:03:41 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id BB85C21F8D69 for <mmusic@ietf.org>; Fri,  3 Aug 2012 12:03:41 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:75b4:324b:9269:c984]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 26EBF415AC; Fri,  3 Aug 2012 15:03:41 -0400 (EDT)
Message-ID: <501C208C.1060207@viagenie.ca>
Date: Fri, 03 Aug 2012 12:03:40 -0700
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Ari Keranen <ari.keranen@nomadiclab.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com>
In-Reply-To: <501C1F38.8050307@nomadiclab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 19:03:42 -0000

Le 2012-08-03 11:58, Ari Keranen a écrit :
> Yes, you should not get ULAs from the STUN server as long as the STUN
> server is properly located (on the Internet, outside of the organization
> perimeter and on the other side of any NATs). And the peer reflexive
> candidate (which would be global address) can be then matched with
> peer's globals.

But reflexive candidates don't always work. I know I said NPTv6, but we 
shouldn't prevent ICE from working behind evil NAT66. And an ICE client 
may not be able to reach a STUN server so you can't rely on having 
reflexive candidates. So you should still try to match ULAs with globals.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From ari.keranen@nomadiclab.com  Fri Aug  3 12:28:00 2012
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF9E21E8042 for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 12:28: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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqQOJmfviULP for <mmusic@ietfa.amsl.com>; Fri,  3 Aug 2012 12:28:00 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id B06A421E8041 for <mmusic@ietf.org>; Fri,  3 Aug 2012 12:27:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4D9624E6F1; Fri,  3 Aug 2012 22:27:57 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZyDNAx2YJPh; Fri,  3 Aug 2012 22:27:56 +0300 (EEST)
Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 2CDDE4E6F0; Fri,  3 Aug 2012 22:27:55 +0300 (EEST)
Message-ID: <501C2639.60000@nomadiclab.com>
Date: Fri, 03 Aug 2012 12:27:53 -0700
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca>
In-Reply-To: <501C208C.1060207@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 19:28:00 -0000

On 8/3/12 12:03 PM, Simon Perreault wrote:
> Le 2012-08-03 11:58, Ari Keranen a écrit :
>> Yes, you should not get ULAs from the STUN server as long as the STUN
>> server is properly located (on the Internet, outside of the organization
>> perimeter and on the other side of any NATs). And the peer reflexive
>> candidate (which would be global address) can be then matched with
>> peer's globals.
>
> But reflexive candidates don't always work. I know I said NPTv6, but we
> shouldn't prevent ICE from working behind evil NAT66. And an ICE client
> may not be able to reach a STUN server so you can't rely on having
> reflexive candidates. So you should still try to match ULAs with globals.

OK, this is quite a corner case, but I'm afraid you're right. However, 
if you have a global address on the interface (i.e., you're not behind 
an evil NAT66), matching ULAs with globals doesn't make sense. So, I'd 
suggest text along the lines of:

    o  Candidate addresses from Unique Local Addresses (ULAs) SHOULD NOT
       be combined with any other candidates except other ULA candidates.
       However, if an interface does not have any global addresses, the
       ULA SHOULD be used.

(changed MUST to SHOULD and added the second sentence)


Cheers,
Ari

From jonathan@vidyo.com  Sat Aug  4 01:09:49 2012
Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8621F8777 for <mmusic@ietfa.amsl.com>; Sat,  4 Aug 2012 01:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 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 1EH2LDmy1xXM for <mmusic@ietfa.amsl.com>; Sat,  4 Aug 2012 01:09:48 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4633A21F8773 for <mmusic@ietf.org>; Sat,  4 Aug 2012 01:09:48 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 78E62A686C1; Sat,  4 Aug 2012 03:48:21 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 11C68A684C4; Sat,  4 Aug 2012 03:48:21 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Sat, 4 Aug 2012 04:09:31 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Ari Keranen <ari.keranen@nomadiclab.com>
Date: Sat, 4 Aug 2012 04:09:55 -0400
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: Ac1yGHbg+j0mH/CkTgGo7qxjihndOA==
Message-ID: <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com>
In-Reply-To: <501C2639.60000@nomadiclab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Aug 2012 08:09:49 -0000

On Aug 3, 2012, at 12:27 PM, Ari Keranen wrote:

> On 8/3/12 12:03 PM, Simon Perreault wrote:
>> Le 2012-08-03 11:58, Ari Keranen a =E9crit :
>>> Yes, you should not get ULAs from the STUN server as long as the STUN
>>> server is properly located (on the Internet, outside of the organizatio=
n
>>> perimeter and on the other side of any NATs). And the peer reflexive
>>> candidate (which would be global address) can be then matched with
>>> peer's globals.
>>=20
>> But reflexive candidates don't always work. I know I said NPTv6, but we
>> shouldn't prevent ICE from working behind evil NAT66. And an ICE client
>> may not be able to reach a STUN server so you can't rely on having
>> reflexive candidates. So you should still try to match ULAs with globals=
.
>=20
> OK, this is quite a corner case, but I'm afraid you're right. However,=20
> if you have a global address on the interface (i.e., you're not behind=20
> an evil NAT66), matching ULAs with globals doesn't make sense. So, I'd=20
> suggest text along the lines of:
>=20
>    o  Candidate addresses from Unique Local Addresses (ULAs) SHOULD NOT
>       be combined with any other candidates except other ULA candidates.
>       However, if an interface does not have any global addresses, the
>       ULA SHOULD be used.
>=20
> (changed MUST to SHOULD and added the second sentence)

Remembering that the two ICE endpoints need to agree on which candidates ma=
tch, does this mean that I need to know whether my peer's ULA and my peer's=
 global address are on its same interface?

As a more general comment, one of the virtues of ICE is that by matching ev=
erything to everything, you're guaranteed to find a route, if one's possibl=
e, no matter how stupid or evil your network architects have been.  I don't=
 think we want to break that property for IPv6, except in cases where it's =
absolutely impossible (e.g., due to host behavior) for a route to work.  If=
 there's any circumstance where a network admin being "helpful" could make =
a connectivity check on a candidate pair succeed, I think we want to try th=
at pair.  Even if the IETF says that the network MUST NOT be configured so =
as to make such a route work.

That said, if there were a well-defined algorithm to prioritize sensible ch=
ecks over absurd ones, that'd be fine.

I'm afraid I don't understand v6 addressing well enough to make concrete te=
xt suggestions based on this principle, though.

--
Jonathan Lennox
jonathan@vidyo.com



From palmarti@cisco.com  Mon Aug  6 01:02:50 2012
Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487E621F85FF for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 01:02:50 -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 s1CNJRtN5LHG for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 01:02:49 -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 3278021F8600 for <mmusic@ietf.org>; Mon,  6 Aug 2012 01:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=palmarti@cisco.com; l=3041; q=dns/txt; s=iport; t=1344240169; x=1345449769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rUItiANTpj3K1aABdPnGrFhUX9ddHXxMRLmAb1nyypo=; b=c1HPl1dtHnZhWc7eVtK+JGXpPKM6cPeF8ZMyvgCNgeiSwOE4vPIXph0z soepvHHaOGu9H5qqW9MfXk5C91egCihCl4LMwbKGi3IQ4+gBzL9yMJkEn 0S9dHUb4i3gZ+NR28DBOpXUpBM34zupbjgyd2THQRLxwRUl5Ve4fgGp1X s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EACx5H1CtJV2d/2dsb2JhbABFuT6BB4IgAQEBAwEBAQEPAVsLBQsCAQgYLicLJQIEDgUih2UGC5s7n0gEi0qGJGADiBiNMY4mgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,717,1336348800"; d="scan'208";a="108706468"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2012 08:02:48 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7682msS011281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 08:02:48 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.245]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 03:02:48 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAMisQA=
Date: Mon, 6 Aug 2012 08:02:48 +0000
Message-ID: <BE917D1B-C11C-433A-AE16-5C580C83E7E3@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>
In-Reply-To: <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.90.130]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.004
x-tm-as-result: No--39.101600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <0931836700D27E42969A77CEF83C95F9@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 08:02:50 -0000

On Aug 4, 2012, at 10:09 AM, Jonathan Lennox <jonathan@vidyo.com>
 wrote:

>=20
> On Aug 3, 2012, at 12:27 PM, Ari Keranen wrote:
>=20
>> On 8/3/12 12:03 PM, Simon Perreault wrote:
>>> Le 2012-08-03 11:58, Ari Keranen a =E9crit :
>>>> Yes, you should not get ULAs from the STUN server as long as the STUN
>>>> server is properly located (on the Internet, outside of the organizati=
on
>>>> perimeter and on the other side of any NATs). And the peer reflexive
>>>> candidate (which would be global address) can be then matched with
>>>> peer's globals.
>>>=20
>>> But reflexive candidates don't always work. I know I said NPTv6, but we
>>> shouldn't prevent ICE from working behind evil NAT66. And an ICE client
>>> may not be able to reach a STUN server so you can't rely on having
>>> reflexive candidates. So you should still try to match ULAs with global=
s.
>>=20
>> OK, this is quite a corner case, but I'm afraid you're right. However,=20
>> if you have a global address on the interface (i.e., you're not behind=20
>> an evil NAT66), matching ULAs with globals doesn't make sense. So, I'd=20
>> suggest text along the lines of:
>>=20
>>   o  Candidate addresses from Unique Local Addresses (ULAs) SHOULD NOT
>>      be combined with any other candidates except other ULA candidates.
>>      However, if an interface does not have any global addresses, the
>>      ULA SHOULD be used.
>>=20
>> (changed MUST to SHOULD and added the second sentence)
>=20
> Remembering that the two ICE endpoints need to agree on which candidates =
match, does this mean that I need to know whether my peer's ULA and my peer=
's global address are on its same interface?
>=20
> As a more general comment, one of the virtues of ICE is that by matching =
everything to everything, you're guaranteed to find a route, if one's possi=
ble, no matter how stupid or evil your network architects have been.  I don=
't think we want to break that property for IPv6, except in cases where it'=
s absolutely impossible (e.g., due to host behavior) for a route to work.  =
If there's any circumstance where a network admin being "helpful" could mak=
e a connectivity check on a candidate pair succeed, I think we want to try =
that pair.  Even if the IETF says that the network MUST NOT be configured s=
o as to make such a route work.
>=20
> That said, if there were a well-defined algorithm to prioritize sensible =
checks over absurd ones, that'd be fine.
>=20
+1=20

I think you make a very good point here. Just make sure we don=B4t encourag=
e bad/evil network configurations. Those configurations should finish their=
 connectivity checks last.

.-.
P=E5l-Erik

> I'm afraid I don't understand v6 addressing well enough to make concrete =
text suggestions based on this principle, though.
>=20
> --
> Jonathan Lennox
> jonathan@vidyo.com
>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From miguel.a.garcia@ericsson.com  Mon Aug  6 02:18:31 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190F21F8610 for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 02:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.916
X-Spam-Level: 
X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_62=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 fbQa5-V8K2GK for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 02:18:30 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7B21F85D2 for <mmusic@ietf.org>; Mon,  6 Aug 2012 02:18:29 -0700 (PDT)
X-AuditID: c1b4fb25-b7f236d000005cde-d1-501f8be47217
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6F.5E.23774.4EB8F105; Mon,  6 Aug 2012 11:18:28 +0200 (CEST)
Received: from [159.107.105.89] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Mon, 6 Aug 2012 11:18:24 +0200
Message-ID: <501F8BDB.2060103@ericsson.com>
Date: Mon, 6 Aug 2012 11:18:19 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "mmusic (E-mail)" <mmusic@ietf.org>
References: <501887FF.7020203@ericsson.com> <50198530.1070806@ericsson.com>
In-Reply-To: <50198530.1070806@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3VvdJt3yAwa09YhZTlz9msfjbzuzA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZcxvvsRScNm2YmHjJ9YGxtuGXYycHBICJhKH P69hg7DFJC7cWw9kc3EICZxilDjasZQdwlnNKLHq+WIWkCpeAW2J+RM+g3WwCKhIfH9xhxHE ZhMwl2jduJEdxBYVCJR4PnsLO0S9oMTJmU/AekUEGoEGNTmB2MICARLTVq4C6uUAWuAtcfh8 JUiYU0BH4vZkiDHMArYSF+ZcZ4Gw5SWat85mBrGFBDQlJt9cyjyBUWAWkg2zkLTMQtKygJF5 FaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYEAe3PJbdQfjnXMihxilOViUxHmtt+7xFxJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cBo2v1Uf7J5QrkSb1ze+jt3TedL3gzgez6LzcRx5tEf3SJP N/F/m872X2/BgY7osA7JGxdNFINXbIqodNB1qui+WXRyc80z1W1z38lfPTIz+2NWhdItEZYP L7uCjz4pWRu8qYY3dtl+rs3Tttq+lDVieDBdpyOo4FtiRQmf/0zeP7V7r7FLN8QosRRnJBpq MRcVJwIAFeTyNxYCAAA=
Subject: Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 09:18:31 -0000

Hi,

Many thanks to Magnus and Roni for discussing the wording of this LS 
resposne. This is to close the discussion on this topic.

There is general agreement on the LS. I believe Roni ask to add a 
reference to RFC 3556 in our bullet point #3.

This is the final response that we will be forwarding to 3GPP SA4.

/Miguel

==========

Source: IETF MMUSIC WG
To: 3GPP TSG SA WG4 (SA4)

Title: Reply regarding On RTCP Bandwidth Negotiation


MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
SA4's identification that there exist no well defined behavior for the
negotiation of the RTCP bandwidth parameters RR and RS when used in
Offer/Answer context to negotiate a unicast transported RTP session. It
is clear that the RTP session participating end-points do need to agree
on common values or there exist a potential for interoperability failures.

Regarding the proposed recommendations for negotiation MMUSIC WG has the
following comments.

1. Based on the limitations of Offer/Answer and the requirement on
arriving at a common RTCP bandwidth value for RR and RS respectively
there exist only two possible choices. A. that the Offerer dictates the
bandwidth values without any possibilities for B to change the values,
or B. as proposed in the LS that the Offerer suggest a value that
the Answerer may modify. On that high level MMUSIC WG considers the
proposed solution appropriate

2. However, we do consider the limitation that the answerer only can
keep or reduce the bandwidth values to a be a potential issue in the
proposed recommendation. The reason is that the answering party then
have no way of increasing the value if the peer agent is not willing to
accept the higher suggested values in a subsequent Offer. This may
appear a reasonable behavior in many cases and considering limited total
bandwidth on the path between the agents. However, when an agent
requires a higher RTCP bandwidth due to its usage of some RTCP based
extensions this could prevent such functionality from being used. And
the bandwidth usage could be addressed by having the answering party to
reduce the total RTP session bandwidth in its answer and be forced to
reduce the bit-rate delivered to the other agent in proportion to the
increase of the RTCP bandwidth.

3. Has any special consideration been taken around the usage of RR or RS
parameter values of 0 as specified in RFC 3556? If either offerer or 
answerer intended to turn off RTCP completely or for receivers only, it 
is questionable that this should have precedence over the other agents 
desire to use RTCP.

MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
rules for the RR and RS bandwidth parameters. This would be to provide
all users of the RTCP bandwidth parameter with guidance on this issue.
If the participants in SA4 WG considers that appropriate, MMUSIC WG
would highly appreciate any engagement from the SA4 participants in
the MMUSIC WG.


=========

On 01/08/2012 21:36, Miguel A. Garcia wrote:
> A reminder to the WG.
>
> We indicated earlier in the meeting that we have only 2 additional days
> for commenting Magnus'es proposed answer to this LS. We are aiming to get
> an agreed response by this Friday August 3rd.
>
> /Miguel
>
> On 01/08/2012 3:35, Magnus Westerlund wrote:
>> MMUSIC WG,
>>
>> Below you find my proposal for a reply to the LS we received from 3GPP
>> SA4 WG.
>> https://datatracker.ietf.org/liaison/1159/
>>
>> This is intended as a starting point for a discussion of what reply we
>> as WG want to send. So please review it and send comments on this.
>>
>> I would highly appreciate any insights how this issues is currently
>> dealt with in any implementations. If we have knowledge of multiple
>> different solutions then that is something we should indicate. Also if
>> any existing solution clashes with SA4's proposed solution.
>>
>> I also raise the question if we should initiate any update of RFC 3556.
>> And if we can come to such an agreement and have volunteers we may be
>> able to strengthen the language in the last paragraph. Otherwise that
>> language is intended to signal a preference for the driving parties in
>> SA4 to come help us update the RFC in MMUSIC WG.
>>
>> ===
>> Source: IETF MMUSIC WG
>> To: 3GPP TSG SA WG4 (SA4)
>>
>> Title: Reply regarding On RTCP Bandwidth Negotiation
>>
>>
>> MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
>> SA4's identification that there exist no well defined behavior for the
>> negotiation of the RTCP bandwidth parameters RR and RS when used in
>> Offer/Answer context to negotiate a unicast transported RTP session. It
>> is clear that the RTP session participating end-points do need to agree
>> on common values or there exist a potential for interoperability failures.
>>
>> Regarding the proposed recommendations for negotiation MMUSIC WG has the
>> following comments.
>>
>> 1. Based on the limitations of Offer/Answer and the requirement on
>> arriving at a common RTCP bandwidth value for RR and RS respectively
>> there exist only two possible choices. A. that the Offerer dictates the
>> bandwidth values without any possibilities for B to change the values,
>> or B. as proposed in the LS that the Offerer suggest a value that
>> the Answerer may modify. On that high level MMUSIC WG considers the
>> proposed solution appropriate
>>
>> 2. However, we do consider the limitation that the answerer only can
>> keep or reduce the bandwidth values to a be a potential issue in the
>> proposed recommendation. The reason is that the answering party then
>> have no way of increasing the value if the peer agent is not willing to
>> accept the higher suggested values in a subsequent Offer. This may
>> appear a reasonable behavior in many cases and considering limited total
>> bandwidth on the path between the agents. However, when an agent
>> requires a higher RTCP bandwidth due to its usage of some RTCP based
>> extensions this could prevent such functionality from being used. And
>> the bandwidth usage could be addressed by having the answering party to
>> reduce the total RTP session bandwidth in its answer and be forced to
>> reduce the bit-rate delivered to the other agent in proportion to the
>> increase of the RTCP bandwidth.
>>
>> 3. Has any special consideration been taken around the usage of RR or RS
>> parameter values of 0. If either offerer or answerer intended to turn
>> off RTCP completely or for receivers only, it is questionable that this
>> should have precedence over the other agents desire to use RTCP.
>>
>> MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
>> rules for the RR and RS bandwidth parameters. This would be to provide
>> all users of the RTCP bandwidth parameter with guidance on this issue.
>> If the participants in SA4 WG considers that appropriate, MMUSIC WG
>> would highly appreciate any engagement from the SA4 participants in
>> the MMUSIC WG.
>>
>> Actions: None
>>
>> -- end of proposed LS reply --
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From ari.keranen@nomadiclab.com  Mon Aug  6 08:06:49 2012
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47921F8678 for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 08:06:49 -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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax8PfY9bZthc for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 08:06:48 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id DF7C021F85FF for <mmusic@ietf.org>; Mon,  6 Aug 2012 08:06:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 869264E6E4; Mon,  6 Aug 2012 18:06:37 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTbFl5KGNRrP; Mon,  6 Aug 2012 18:06:36 +0300 (EEST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 2891A4E6D4; Mon,  6 Aug 2012 18:06:36 +0300 (EEST)
Message-ID: <501FDD75.3090506@nomadiclab.com>
Date: Mon, 06 Aug 2012 17:06:29 +0200
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jonathan Lennox <jonathan@vidyo.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>
In-Reply-To: <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 15:06:49 -0000

On 8/4/12 10:09 AM, Jonathan Lennox wrote:
>
> On Aug 3, 2012, at 12:27 PM, Ari Keranen wrote:
>
>> On 8/3/12 12:03 PM, Simon Perreault wrote:
>>> Le 2012-08-03 11:58, Ari Keranen a écrit :
>>>> Yes, you should not get ULAs from the STUN server as long as
>>>> the STUN server is properly located (on the Internet, outside
>>>> of the organization perimeter and on the other side of any
>>>> NATs). And the peer reflexive candidate (which would be global
>>>> address) can be then matched with peer's globals.
>>>
>>> But reflexive candidates don't always work. I know I said NPTv6,
>>> but we shouldn't prevent ICE from working behind evil NAT66. And
>>> an ICE client may not be able to reach a STUN server so you can't
>>> rely on having reflexive candidates. So you should still try to
>>> match ULAs with globals.
>>
>> OK, this is quite a corner case, but I'm afraid you're right.
>> However, if you have a global address on the interface (i.e.,
>> you're not behind an evil NAT66), matching ULAs with globals
>> doesn't make sense. So, I'd suggest text along the lines of:
>>
>> o  Candidate addresses from Unique Local Addresses (ULAs) SHOULD
>> NOT be combined with any other candidates except other ULA
>> candidates. However, if an interface does not have any global
>> addresses, the ULA SHOULD be used.
>>
>> (changed MUST to SHOULD and added the second sentence)
>
> Remembering that the two ICE endpoints need to agree on which
> candidates match, does this mean that I need to know whether my
> peer's ULA and my peer's global address are on its same interface?
>
> As a more general comment, one of the virtues of ICE is that by
> matching everything to everything, you're guaranteed to find a route,
> if one's possible, no matter how stupid or evil your network
> architects have been.  I don't think we want to break that property
> for IPv6, except in cases where it's absolutely impossible (e.g., due
> to host behavior) for a route to work.  If there's any circumstance
> where a network admin being "helpful" could make a connectivity check
> on a candidate pair succeed, I think we want to try that pair.  Even
> if the IETF says that the network MUST NOT be configured so as to
> make such a route work.

You have a good point. My main concern is that when you have a long list 
of different kind of IPv6 addresses for each interface (global, 
link-local, ULA, some temporary addresses, etc.), you will end up with a 
huge checklist of host-host candidates (which have the highest 
priority). If you have broken v6 connectivity, it's gonna take ages 
before you move to v4 candidates that work.

That being said, perhaps we should keep matching ULAs to globals but 
just give that combination a lower priority than other host-host 
candidate pairs. Link-locals we should still match only to link-locals 
(right?).

> That said, if there were a well-defined algorithm to prioritize
> sensible checks over absurd ones, that'd be fine.

This is the tricky part. Right now the candidates use same priority 
regardless of the other candidate's type. What we'd like to say is "for 
ULA candidate with ULA pair you need priority X and with other types 
priority Y". Then another question is what's the sensible trade-off 
between complexity of prioritization and making these corner cases work..

> I'm afraid I don't understand v6 addressing well enough to make
> concrete text suggestions based on this principle, though.

I can try to craft something for the next revision. All suggestions are 
welcome of course.


Cheers,
Ari

From brett@broadsoft.com  Mon Aug  6 08:14:29 2012
Return-Path: <brett@broadsoft.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7720921F8629 for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 08:14:29 -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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Toi-HSE+DBxf for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 08:14:29 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id E657C21F863F for <mmusic@ietf.org>; Mon,  6 Aug 2012 08:14:28 -0700 (PDT)
Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Aug 2012 08:17:53 -0700
Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 6 Aug 2012 08:17:53 -0700
From: Brett Tate <brett@broadsoft.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Date: Mon, 6 Aug 2012 08:14:26 -0700
Thread-Topic: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: Ac1z5irXaxvG+6IYTyi3BKqjoBMk/A==
Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 15:14:29 -0000

Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the following.

"In general, session-level values are the default for all media
 unless overridden by an equivalent media-level value."

"The connection ("c=3D") and attribute ("a=3D") information in the
 session-level section applies to all the media of that session unless
 overridden by connection information or an attribute of the same name
 in the media description.  For instance, in the example below, each
 media behaves as if it were given a "recvonly" attribute."

If the attributes are related but with different names (such as "inactive" =
and "sendrecv"), does the attribute at the media-level have precedence over=
 the value at the session-level?  If so, I recommend that the draft be upda=
ted to clarify the topic.

Thanks,
Brett


This email is intended solely for the person or entity to which it is addre=
ssed and may contain confidential and/or privileged information.  If you ar=
e not the intended recipient and have received this email in error, please =
notify BroadSoft, Inc. immediately by replying to this message, or by sendi=
ng an email to helpdesk@broadsoft.com, and destroy all copies of this messa=
ge, along with any attachment, prior to reading, distributing or copying it=
.

From internet-drafts@ietf.org  Mon Aug  6 17:31:59 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B170821F8549; Mon,  6 Aug 2012 17:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 buK4dHvwcJln; Mon,  6 Aug 2012 17:31:59 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D29D21F854A; Mon,  6 Aug 2012 17:31: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.33
Message-ID: <20120807003159.19033.24943.idtracker@ietfa.amsl.com>
Date: Mon, 06 Aug 2012 17:31:59 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-21.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 00:32:00 -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           : An Extension to the Session Description Protocol (SDP) a=
nd Real-time Transport Protocol (RTP) for Media Loopback
	Author(s)       : Hadriel Kaplan
                          Kaynam Hedayat
                          Nagarjuna Venna
                          Paul E. Jones
                          Nathan Stratton
	Filename        : draft-ietf-mmusic-media-loopback-21.txt
	Pages           : 33
	Date            : 2012-08-06

Abstract:
    The wide deployment of Voice over IP (VoIP), Text and Video over IP
    services has introduced new challenges in managing and maintaining
    real-time voice/text/video quality, reliability, and overall
    performance.  In particular, media delivery is an area that needs
    attention.  One method of meeting these challenges is monitoring
    the media delivery performance by looping media back to the
    transmitter.  This is typically referred to as "active monitoring"
    of services.   Media loopback is especially popular in ensuring the
    quality of transport to the edge of a given VoIP, Real-time Text or
    Video over IP service.  Today in networks that deliver real-time
    media, short of running 'ping' and 'traceroute' to the edge,
    administrators are left without the necessary tools to actively
    monitor, manage, and diagnose quality issues with their service.
    The extension defined herein adds new SDP media types and
    attributes, which enable establishment of media sessions where the
    media is looped back to the transmitter. Such media sessions will
    serve as monitoring and troubleshooting tools by providing the
    means for measurement of more advanced VoIP, Real-time Text and
    Video over IP performance metrics.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-21

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-21


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From jonathan@vidyo.com  Mon Aug  6 19:07:58 2012
Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C62D21F8669 for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 19:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYR+JZivJoXj for <mmusic@ietfa.amsl.com>; Mon,  6 Aug 2012 19:07:57 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7257421F8661 for <mmusic@ietf.org>; Mon,  6 Aug 2012 19:07:57 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E2560554F2D; Mon,  6 Aug 2012 22:07:56 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7CB09554F1E; Mon,  6 Aug 2012 22:07:56 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 6 Aug 2012 22:07:34 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Ari Keranen <ari.keranen@nomadiclab.com>
Date: Mon, 6 Aug 2012 22:07:53 -0400
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: Ac1z5QogRY98fn1HRDmwrq9QryRpKAAXA1fw
Message-ID: <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com>
In-Reply-To: <501FDD75.3090506@nomadiclab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 02:07:58 -0000

On Monday, August 6 2012, Ari Keranen wrote:

> You have a good point. My main concern is that when you have a long list=
=20
> of different kind of IPv6 addresses for each interface (global,=20
> link-local, ULA, some temporary addresses, etc.), you will end up with a=
=20
> huge checklist of host-host candidates (which have the highest=20
> priority). If you have broken v6 connectivity, it's gonna take ages=20
> before you move to v4 candidates that work.
>=20
> That being said, perhaps we should keep matching ULAs to globals but=20
> just give that combination a lower priority than other host-host=20
> candidate pairs. Link-locals we should still match only to link-locals=20
> (right?).

I understand the problem, and I agree it'll be an issue.

Furthermore, if you need to fall back to v4, it's not enough to just
prioritize all the weird cases below the other host-host pairs -- the v4
address that works will probably be server-reflexive, which you'd prefer.

(If hosts really treat link-local as link-local -- i.e. you'll never have a
router for link-local, and trying to send from link-local to non-link-local
is a black hole or socket error at the sender -- then yes, there's no point
in pairing them with non-link-local addresses.  That's the case I was
thinking of as "impossible")

> > That said, if there were a well-defined algorithm to prioritize
> > sensible checks over absurd ones, that'd be fine.
>=20
> This is the tricky part. Right now the candidates use same priority=20
> regardless of the other candidate's type. What we'd like to say is "for=20
> ULA candidate with ULA pair you need priority X and with other types=20
> priority Y". Then another question is what's the sensible trade-off=20
> between complexity of prioritization and making these corner cases work..

My quick-and-dirty idea would be to take all the candidate pairs that the
current draft lists as "MUST NOT" combine, and put them in a secondary
("stupid") check list which follows all the other checks.  Within the
secondary list, checks are in the standard ICE priority order.

One question would be what the relative priority of weird v6 combinations
vs. v4 relays should be.

--=20
Jonathan Lennox
jonathan@vidyo.com


From dwing@cisco.com  Tue Aug  7 00:15:16 2012
Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CD321F85A8 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 00:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.493
X-Spam-Level: 
X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 xbWY9FQyy3U8 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 00:15:15 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8ADC21F8585 for <mmusic@ietf.org>; Tue,  7 Aug 2012 00:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3380; q=dns/txt; s=iport; t=1344323715; x=1345533315; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=msqRwngj8tHUogurObbV6OjY00GPFVyc8eUTS+eLfEQ=; b=WFkE3DLg+u1+s3abgrj99pGdoQbV+dzTj78ngZ/Yaz7TGcIGF7vB3ho/ nR6rWX5y413Ooia2TqXQnnuEUoJ+f3zg8IaoT6N9NOHHN5DFhCm+QIceY MaSvYU6oTVo+ddWstSX02DIkCmzhxLSxpO8E3C3MsVGBKMXUUWOAc3Z6D g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUKACm/IFCrRDoI/2dsb2JhbABFqh+OKwQDfoEHgiABAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBAQEnBxkOFQoJCAEBBAESCxMEh2UFDJsEoDsEi0qGbQOITYUNlhWBZoJ/gTYj
X-IronPort-AV: E=Sophos;i="4.77,725,1336348800"; d="scan'208";a="54221366"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Aug 2012 07:15:15 +0000
Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q777F4GO017627; Tue, 7 Aug 2012 07:15:05 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Jonathan Lennox'" <jonathan@vidyo.com>, "'Ari Keranen'" <ari.keranen@nomadiclab.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca>	<5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca>	<501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca>	<501C2639.60000@nomadiclab.com>	<EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>	<501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan>
In-Reply-To: <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan>
Date: Tue, 7 Aug 2012 00:15:04 -0700
Message-ID: <092c01cd746c$5e7c8040$1b7580c0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac1z5QogRY98fn1HRDmwrq9QryRpKAAXA1fwAAq4i+A=
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 07:15:16 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Jonathan Lennox
> Sent: Monday, August 06, 2012 7:08 PM
> To: Ari Keranen
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] ICE candidate address selection update draft
> 
> On Monday, August 6 2012, Ari Keranen wrote:
> 
> > You have a good point. My main concern is that when you have a long
> list
> > of different kind of IPv6 addresses for each interface (global,
> > link-local, ULA, some temporary addresses, etc.), you will end up
> with a
> > huge checklist of host-host candidates (which have the highest
> > priority). If you have broken v6 connectivity, it's gonna take ages
> > before you move to v4 candidates that work.
> >
> > That being said, perhaps we should keep matching ULAs to globals but
> > just give that combination a lower priority than other host-host
> > candidate pairs. Link-locals we should still match only to link-
> locals
> > (right?).
> 
> I understand the problem, and I agree it'll be an issue.
> 
> Furthermore, if you need to fall back to v4, it's not enough to just
> prioritize all the weird cases below the other host-host pairs -- the
> v4
> address that works will probably be server-reflexive, which you'd
> prefer.
> 
> (If hosts really treat link-local as link-local -- i.e. you'll never
> have a
> router for link-local, and trying to send from link-local to non-link-
> local
> is a black hole or socket error at the sender -- then yes, there's no
> point
> in pairing them with non-link-local addresses.  That's the case I was
> thinking of as "impossible")
> 
> > > That said, if there were a well-defined algorithm to prioritize
> > > sensible checks over absurd ones, that'd be fine.
> >
> > This is the tricky part. Right now the candidates use same priority
> > regardless of the other candidate's type. What we'd like to say is
> "for
> > ULA candidate with ULA pair you need priority X and with other types
> > priority Y". Then another question is what's the sensible trade-off
> > between complexity of prioritization and making these corner cases
> work..
> 
> My quick-and-dirty idea would be to take all the candidate pairs that
> the
> current draft lists as "MUST NOT" combine, and put them in a secondary
> ("stupid") check list which follows all the other checks.  Within the
> secondary list, checks are in the standard ICE priority order.

Mine would be to take the list of IPv6 and IPv4 addresses and try them
in the order described by ICE (which currently recommends following
the OS's default, which is sometimes hard to get depending on the
OS).  But if the first IPv6 candidate didn't return a connectivity
checks quickly (let's say, 150ms), initiate a connectivity check
on the highest priority IPv4 address next.  In that 150ms, based
on ICE's pacing, many IPv6 addresses will have been tried.  150ms
gives plenty of time for IPv6 to 'win', before using an IPv4
resource that is likely shared with IPv4-only devices.

-d

> One question would be what the relative priority of weird v6
> combinations
> vs. v4 relays should be.
> 
> --
> Jonathan Lennox
> jonathan@vidyo.com
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From jonathan@vidyo.com  Tue Aug  7 02:53:12 2012
Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6236721F85B4 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 02:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level: 
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082,  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 42us5GW8Paot for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 02:53:11 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 32F7221F85A3 for <mmusic@ietf.org>; Tue,  7 Aug 2012 02:53:11 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8B9358BE994; Tue,  7 Aug 2012 05:53:10 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB013.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 22E228BE90A; Tue,  7 Aug 2012 05:53:10 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Tue, 7 Aug 2012 05:53:09 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Dan Wing <dwing@cisco.com>, 'Ari Keranen' <ari.keranen@nomadiclab.com>
Date: Tue, 7 Aug 2012 05:53:08 -0400
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: Ac1z5QogRY98fn1HRDmwrq9QryRpKAAXA1fwAAq4i+AABZupQA==
Message-ID: <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com>
In-Reply-To: <092c01cd746c$5e7c8040$1b7580c0$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 09:53:13 -0000

On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari Ker=
anen', mmusic@ietf.org" saying:

> Mine would be to take the list of IPv6 and IPv4 addresses and try them=20
> in the order described by ICE (which currently recommends following=20
> the OS's default, which is sometimes hard to get depending on the OS). =20
> But if the first IPv6 candidate didn't return a connectivity checks=20
> quickly (let's say, 150ms), initiate a connectivity check on the=20
> highest priority IPv4 address next.  In that 150ms, based on ICE's=20
> pacing, many IPv6 addresses will have been tried.  150ms gives plenty=20
> of time for IPv6 to 'win', before using an IPv4 resource that is=20
> likely shared with IPv4-only devices.

Can't this result in the endpoints getting out of sync with the order of th=
e checklist?  If one side has started IPv4 while the other hasn't, you won'=
t have the outbound packets coming from one side to create the port binding=
s.

--=20
Jonathan Lennox
jonathan@vidyo.com

From internet-drafts@ietf.org  Tue Aug  7 08:25:52 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A539821F866B; Tue,  7 Aug 2012 08:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 NL2TBCpNswj6; Tue,  7 Aug 2012 08:25:51 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5121F866E; Tue,  7 Aug 2012 08:25:51 -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.33
Message-ID: <20120807152551.2856.9834.idtracker@ietfa.amsl.com>
Date: Tue, 07 Aug 2012 08:25:51 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-22.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 15:25:52 -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           : An Extension to the Session Description Protocol (SDP) a=
nd Real-time Transport Protocol (RTP) for Media Loopback
	Author(s)       : Hadriel Kaplan
                          Kaynam Hedayat
                          Nagarjuna Venna
                          Paul E. Jones
                          Nathan Stratton
	Filename        : draft-ietf-mmusic-media-loopback-22.txt
	Pages           : 33
	Date            : 2012-08-07

Abstract:
    The wide deployment of Voice over IP (VoIP), Text and Video over IP
    services has introduced new challenges in managing and maintaining
    real-time voice/text/video quality, reliability, and overall
    performance.  In particular, media delivery is an area that needs
    attention.  One method of meeting these challenges is monitoring
    the media delivery performance by looping media back to the
    transmitter.  This is typically referred to as "active monitoring"
    of services.   Media loopback is especially popular in ensuring the
    quality of transport to the edge of a given VoIP, Real-time Text or
    Video over IP service.  Today in networks that deliver real-time
    media, short of running 'ping' and 'traceroute' to the edge,
    administrators are left without the necessary tools to actively
    monitor, manage, and diagnose quality issues with their service.
    The extension defined herein adds new SDP media types and
    attributes, which enable establishment of media sessions where the
    media is looped back to the transmitter. Such media sessions will
    serve as monitoring and troubleshooting tools by providing the
    means for measurement of more advanced VoIP, Real-time Text and
    Video over IP performance metrics.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-22

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-22


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From palmarti@cisco.com  Tue Aug  7 11:30:22 2012
Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2700221F859A for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 11:30:22 -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 nbxp0HwEDksy for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 11:30:21 -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 3D1B521F858F for <mmusic@ietf.org>; Tue,  7 Aug 2012 11:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=palmarti@cisco.com; l=2672; q=dns/txt; s=iport; t=1344364221; x=1345573821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tCKxbCo9TKJJrulewgWoe8BN6bl0xBw9gcemvEC5Dyo=; b=jUwPKkCEP4V2eO9qDkKE25XoqWC9DgZ+Hr3OXrn1thnkvqakT5sUh3Mh hH7UM2INMI4iUE8NYmNxBCtwCdlvs8ojK7qQUyTWjQDZ9p8VRZz5/CsIH yZZ3lSf7HlhGsQS+ua1Sy6sqI2bRfwy4kpMPeakP/ojiRnatE5Un3q3oA A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAMRdIVCtJXG9/2dsb2JhbABFuWWBB4IgAQEBAwEBAQEPAVsLBQsCAQhGJwslAgQOBR4Eh2UGC5s7oFQEiw+GAGADiBiNMI4mgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,728,1336348800"; d="scan'208";a="109278515"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2012 18:30:20 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q77IUKuF026886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 18:30:20 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.245]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 13:30:20 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAOZDYCAALjLgIAAVdMAgAAsKgCAAJB/AA==
Date: Tue, 7 Aug 2012 18:30:19 +0000
Message-ID: <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan>
In-Reply-To: <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.154.72]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.000
x-tm-as-result: No--36.006000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <38D78789C0E7D945950040B250ACE3D6@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "Dan Wing \(dwing\)" <dwing@cisco.com>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 18:30:22 -0000

On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:

> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari K=
eranen', mmusic@ietf.org" saying:
>=20
>> Mine would be to take the list of IPv6 and IPv4 addresses and try them=20
>> in the order described by ICE (which currently recommends following=20
>> the OS's default, which is sometimes hard to get depending on the OS).

>From a ICE multi platform library developer that is somewhat of a nightmare=
.=20
Guess it can be solved by having a reasonable interface that the applicatio=
n=20
that uses the library can fill in the defaults. Having reasonable default v=
alues
is important as some platforms might not be able to set the values.=20

>> =20
>> But if the first IPv6 candidate didn't return a connectivity checks=20
>> quickly (let's say, 150ms), initiate a connectivity check on the=20
>> highest priority IPv4 address next.  In that 150ms, based on ICE's=20
>> pacing, many IPv6 addresses will have been tried.  150ms gives plenty=20
>> of time for IPv6 to 'win', before using an IPv4 resource that is=20
>> likely shared with IPv4-only devices.
>=20
> Can't this result in the endpoints getting out of sync with the order of =
the checklist?  If one side has started IPv4 while the other hasn't, you wo=
n't have the outbound packets coming from one side to create the port bindi=
ngs.
>=20
It can at least potentially introduce more "kamikaze" packets and delay the=
 result. The STUN transaction have 10 retransmits and would timeout long af=
ter the checklist is empty.

To maintain the speed of ICE negotiation and keep call setup times low I th=
ink we should consider looking at the pacing of the conn checks. The ration=
ale behind the pacing was not to overwhelm the NATs. Have the world move sl=
ightly towards better NATs? Looking from the perspective of an endpoint sen=
ding 1080p60 video streams the pacing seem a bit conservative? And how does=
 the different paths (IPv4, IPv6, multi homed) impact the pacing? Could we =
do more in parallel without overwhelm the NATs?

I am wondering if we could do something smart with prioritising the checkli=
st and triggered checks to make sure IPv6 wins if there is connectivity? I =
have to little understanding if IPv6 and all the different addresses to cle=
arly formulate the idea at the moment. (Hoping this may trigger something f=
or someone.)

.-.
P=E5l-Erik


> --=20
> Jonathan Lennox
> jonathan@vidyo.com
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From tom.taylor.stds@gmail.com  Tue Aug  7 11:59:02 2012
Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC92A21F86E4 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 11:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvHL2PJsCO3v for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 11:59:01 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9986A21F86E2 for <mmusic@ietf.org>; Tue,  7 Aug 2012 11:59:01 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so4448263ggn.31 for <mmusic@ietf.org>; Tue, 07 Aug 2012 11:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=JhhdQ2vbkGEf37UHicJHS3JVd+SlZk/HE0hNbHFLt28=; b=UYzUUG5MPFJ4d47JfEzxLc4H0l2NxGyZ9iO/v2QzPW8CgHnUXn6koZqpjhQW7r+Ian kly0YpiVNmBE3PyjPMID4TDANK8Q3Hluv0mjPAHoJrwQBpv+IkFR7QxYpAsz/vr8MNfv zdh9Mq8m4Rhu8CZD8PkHtZG4ZgbCHuevVi1cA3KBJS0wSx16/77N6Pdlyp34dlnER2VZ TxIq7FeIbkHw87Bjps3u9tKd7oehpmqYKY1TxYN1jmBIhTIyUl7/mOhMbVWn0+SvlDsD SOCM3n4y9s50Vx5u5JJvLfoX2I4Se6uQNh5zSvyq9SGVbHEHBnUBK/Ew7nH3vCUFvw70 ZEcw==
Received: by 10.60.25.226 with SMTP id f2mr26022135oeg.13.1344365940783; Tue, 07 Aug 2012 11:59:00 -0700 (PDT)
Received: from [127.0.0.1] ([199.246.39.165]) by mx.google.com with ESMTPS id s7sm15674464oec.7.2012.08.07.11.58.58 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 11:58:59 -0700 (PDT)
Message-ID: <50216570.3090903@gmail.com>
Date: Tue, 07 Aug 2012 14:58:56 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com>
In-Reply-To: <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 120807-0, 07/08/2012), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 18:59:02 -0000

People involved in this discussion might be interested in

  http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/

On 07/08/2012 2:30 PM, Pal Martinsen (palmarti) wrote:
>
> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari Keranen', mmusic@ietf.org" saying:
>>
>>> Mine would be to take the list of IPv6 and IPv4 addresses and try them
>>> in the order described by ICE (which currently recommends following
>>> the OS's default, which is sometimes hard to get depending on the OS).
>
>>From a ICE multi platform library developer that is somewhat of a nightmare.
> Guess it can be solved by having a reasonable interface that the application
> that uses the library can fill in the defaults. Having reasonable default values
> is important as some platforms might not be able to set the values.
>
>>>
>>> But if the first IPv6 candidate didn't return a connectivity checks
>>> quickly (let's say, 150ms), initiate a connectivity check on the
>>> highest priority IPv4 address next.  In that 150ms, based on ICE's
>>> pacing, many IPv6 addresses will have been tried.  150ms gives plenty
>>> of time for IPv6 to 'win', before using an IPv4 resource that is
>>> likely shared with IPv4-only devices.
>>
>> Can't this result in the endpoints getting out of sync with the order of the checklist?  If one side has started IPv4 while the other hasn't, you won't have the outbound packets coming from one side to create the port bindings.
>>
> It can at least potentially introduce more "kamikaze" packets and delay the result. The STUN transaction have 10 retransmits and would timeout long after the checklist is empty.
>
> To maintain the speed of ICE negotiation and keep call setup times low I think we should consider looking at the pacing of the conn checks. The rationale behind the pacing was not to overwhelm the NATs. Have the world move slightly towards better NATs? Looking from the perspective of an endpoint sending 1080p60 video streams the pacing seem a bit conservative? And how does the different paths (IPv4, IPv6, multi homed) impact the pacing? Could we do more in parallel without overwhelm the NATs?
>
> I am wondering if we could do something smart with prioritising the checklist and triggered checks to make sure IPv6 wins if there is connectivity? I have to little understanding if IPv6 and all the different addresses to clearly formulate the idea at the moment. (Hoping this may trigger something for someone.)
>
> .-.
> Pål-Erik
>
>
>> --
>> 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
>

From ietf@meetecho.com  Tue Aug  7 15:47:44 2012
Return-Path: <ietf@meetecho.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1AD21F8668 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 15:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.131
X-Spam-Level: 
X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=0.588,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rziLzWRxTsSN for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 15:47:43 -0700 (PDT)
Received: from smtplq01.aruba.it (smtplqs-out19.aruba.it [62.149.158.59]) by ietfa.amsl.com (Postfix) with SMTP id E38F321F8667 for <mmusic@ietf.org>; Tue,  7 Aug 2012 15:47:42 -0700 (PDT)
Received: (qmail 16034 invoked by uid 89); 7 Aug 2012 22:47:41 -0000
Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq01.aruba.it with SMTP; 7 Aug 2012 22:47:41 -0000
Received: (qmail 18849 invoked by uid 89); 7 Aug 2012 22:47:41 -0000
Received: from unknown (HELO ?192.168.1.154?) (alex@meetecho.com@87.11.150.210) by smtp5.ad.aruba.it with ESMTPA; 7 Aug 2012 22:47:41 -0000
Message-ID: <50219AFE.7030600@meetecho.com>
Date: Wed, 08 Aug 2012 00:47:26 +0200
From: Meetecho IETF support <ietf@meetecho.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N
Subject: [MMUSIC] Meetecho session recording available
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 22:47:44 -0000

Dear all,

the full recording (synchronized video, audio, slides and jabber room)
of MMUSIC session at IETF-84 is available.

You can watch it by accessing the following URL:
http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_MMUSIC

For the chair(s): please feel free to put the link to the recording in 
the minutes, if you think this might be useful.

In case of problems with the playout, just drop an e-mail to 
team@meetecho.com.

Cheers,
the Meetecho team

-- 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

From HKaplan@acmepacket.com  Tue Aug  7 16:27:23 2012
Return-Path: <HKaplan@acmepacket.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78D21F85C4 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 16:27:23 -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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCMpkeR+7X65 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 16:27:22 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 41F6321F85BB for <mmusic@ietf.org>; Tue,  7 Aug 2012 16:27:21 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 7 Aug 2012 19:27:17 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.168]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Tue, 7 Aug 2012 19:27:16 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "mmusic (E-mail)" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-22.txt
Thread-Index: AQHNdPQumfO/4CJDHkyLI5ZlLeOJuA==
Date: Tue, 7 Aug 2012 23:27:16 +0000
Message-ID: <45CEAD98-023F-4E41-AF22-0BDD599CA85D@acmepacket.com>
References: <20120807152551.2856.9834.idtracker@ietfa.amsl.com>
In-Reply-To: <20120807152551.2856.9834.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3188A402E64AC14EB2F1655483E0E5CE@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAC+NgFvrMqsTGxcLFwCCqG7pEMcBg99wH05gsrs/bx+zAGMAQxZqZl5RfkcCaMevdf5aCpeIVR1dPZW9g/C3YxcjFISSwglFi0v+/rBDOHEaJ7w8usHQxcnKwCehKbNi7lhnEFhFQl2jd3McKYgsLeEpseP2OFSLuJdH55DobhK0n8fb4M/YuRg4OFgEVidv/RUDCvAKOEo3Ht4ONERKwl1h3YxpYK6eAg8TGA4+ZQGxGATGJ76fWgNnMAuISt57MB7MlBLQltr/axwph60hsuraKBWS8hIC1xO67YhBhAYkle84zQ9hKEr2330G1ikq8fPwPqlVPonHLDzYIO1Biw4VlLBC2qcSbJZegbFuJE2v/Qs1xl2hdvxAq7itxaPESKFte4v+9+3D121Y3MkLYshJNF94xw8SfXVoBZXtLXJ76BqreSOL61yaoGywl3k5cwDKBUWMWko8hbB2JBbs/sUHYthIPerqg4toSyxa+Zp4FDlFBiZMzn7AsYGRdxSiaWpKbmJmjl5icm1qQmJydWqKXnJ+7iRGYIG5oSrDtYHz0Tf0QoyQHk5Ior8VCxQAhvqT8lMqMxOKM+KLSnNTiQ4wSHDxKIrxCi4ByvMUFibnFmekwKRkODiUJ3kcgKcGi1PTUirTMnJLUIoj0KUZJKXHeTyBJAZC+jNI8uNwlRlEpYd59IDmegtSi3MwSiPgtRmGOh0xCLHn5ealSQCcyAIEG4ytGcQ5GJWFe0cUg9Zl5JXAnvAK6jgnoOm95OZDrShIRUlINjC2vd1yIbz91iMnA4f9qn9WBVQ3BBVv0lT74G1iu1r2V8XqGidX0ht1/vwdLyzesLtYuSFPrE7s7nZtJUPDPhrfHOZ/nzvaokqhTmuAocfXATgs1HdP/IUpXdP/WzlM/U3xZ6JxVma9CM5vi+mNMQR0bNypUav1R2x5Vy7z8TmXHV7nazts/lViKMxINtZiLihMB4waxp YYDAAA=
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-22.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 23:27:23 -0000

FYI, these updates to the media-loopback-draft are to fix boilerplate issue=
s and other idnits so it can be moved to publication request.
We believe they're all fixed now.
Nothing to see here... move along...

-hadriel


On Aug 7, 2012, at 11:25 AM, <internet-drafts@ietf.org>
 <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           : An Extension to the Session Description Protocol (SDP)=
 and Real-time Transport Protocol (RTP) for Media Loopback
> 	Author(s)       : Hadriel Kaplan
>                          Kaynam Hedayat
>                          Nagarjuna Venna
>                          Paul E. Jones
>                          Nathan Stratton
> 	Filename        : draft-ietf-mmusic-media-loopback-22.txt
> 	Pages           : 33
> 	Date            : 2012-08-07
>=20
> Abstract:
>    The wide deployment of Voice over IP (VoIP), Text and Video over IP
>    services has introduced new challenges in managing and maintaining
>    real-time voice/text/video quality, reliability, and overall
>    performance.  In particular, media delivery is an area that needs
>    attention.  One method of meeting these challenges is monitoring
>    the media delivery performance by looping media back to the
>    transmitter.  This is typically referred to as "active monitoring"
>    of services.   Media loopback is especially popular in ensuring the
>    quality of transport to the edge of a given VoIP, Real-time Text or
>    Video over IP service.  Today in networks that deliver real-time
>    media, short of running 'ping' and 'traceroute' to the edge,
>    administrators are left without the necessary tools to actively
>    monitor, manage, and diagnose quality issues with their service.
>    The extension defined herein adds new SDP media types and
>    attributes, which enable establishment of media sessions where the
>    media is looped back to the transmitter. Such media sessions will
>    serve as monitoring and troubleshooting tools by providing the
>    means for measurement of more advanced VoIP, Real-time Text and
>    Video over IP performance metrics.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-22
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-22
>=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 abegen@cisco.com  Tue Aug  7 20:33:18 2012
Return-Path: <abegen@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFD521F8568 for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 20:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyjlXtzro8lT for <mmusic@ietfa.amsl.com>; Tue,  7 Aug 2012 20:32:58 -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 021FA21F8566 for <mmusic@ietf.org>; Tue,  7 Aug 2012 20:32:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1893; q=dns/txt; s=iport; t=1344396778; x=1345606378; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8QS1XgqBwuNVAoqYUMTa+QGnCtnOnJ1SFt0UFgQWGOE=; b=HzJtJswl2Yepwlz99aySbJi9+G2TOv0njd68ze0yAcNldVY+iicc7I9s eWG941copBqjF83GgNAkzEdZ0wMa2aokpAFHxA5CAgP7Zb60v1ykQEcSN TFBJYYPd5tNUDypF9nUTwxMRkEHKg98GMGeFKgoET1uNSt4nwH6lBcTdT I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACrdIVCtJV2c/2dsb2JhbABFuWqBB4IgAQEBAwEBAQEPAVsQBwQCAQgRBAEBCx0HJwsUCQgBAQQBEggah2UGAQqaW6BPBIsPhgBgA6NugWaCX4Ff
X-IronPort-AV: E=Sophos;i="4.77,730,1336348800"; d="scan'208";a="109429890"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 08 Aug 2012 03:32:57 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q783WvDg015208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 03:32:57 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 22:32:57 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Brett Tate <brett@broadsoft.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: Ac1z5irXaxvG+6IYTyi3BKqjoBMk/ABMAh4w
Date: Wed, 8 Aug 2012 03:32:56 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local>
In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.248.196]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.001
x-tm-as-result: No--45.269400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 03:33:18 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf =
Of Brett Tate
> Sent: Monday, August 06, 2012 11:14 AM
> To: mmusic@ietf.org
> Subject: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attribut=
es
>=20
> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the following.
>=20
> "In general, session-level values are the default for all media
>  unless overridden by an equivalent media-level value."
>=20
> "The connection ("c=3D") and attribute ("a=3D") information in the
>  session-level section applies to all the media of that session unless
>  overridden by connection information or an attribute of the same name
>  in the media description.  For instance, in the example below, each
>  media behaves as if it were given a "recvonly" attribute."
>=20
> If the attributes are related but with different names (such as "inactive=
" and "sendrecv"), does the attribute at the media-
> level have precedence over the value at the session-level?  If so, I reco=
mmend that the draft be updated to clarify the topic.

I believe so. at least that is my understanding from the text. Does it real=
ly need clarification? Thoughts?

-acbegen

=20
> Thanks,
> Brett
>=20
>=20
> This email is intended solely for the person or entity to which it is add=
ressed and may contain confidential and/or privileged
> information.  If you are not the intended recipient and have received thi=
s email in error, please notify BroadSoft, Inc.
> immediately by replying to this message, or by sending an email to helpde=
sk@broadsoft.com, and destroy all copies of this
> message, along with any attachment, prior to reading, distributing or cop=
ying it.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From miguel.a.garcia@ericsson.com  Wed Aug  8 01:15:01 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96CE21F86CF for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 01:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.206
X-Spam-Level: 
X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWiRuyiUiEKZ for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 01:15:00 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C985111E8098 for <mmusic@ietf.org>; Wed,  8 Aug 2012 01:14:58 -0700 (PDT)
X-AuditID: c1b4fb25-b7f236d000005cde-ef-5022200159fe
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 79.92.23774.10022205; Wed,  8 Aug 2012 10:14:57 +0200 (CEST)
Received: from [159.107.105.89] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Wed, 8 Aug 2012 10:14:55 +0200
Message-ID: <50221FF9.9000900@ericsson.com>
Date: Wed, 8 Aug 2012 10:14:49 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>,  "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" <draft-ietf-mmusic-media-loopback.authors@tools.ietf.org>
References: <20120807152551.2856.9834.idtracker@ietfa.amsl.com> <45CEAD98-023F-4E41-AF22-0BDD599CA85D@acmepacket.com>
In-Reply-To: <45CEAD98-023F-4E41-AF22-0BDD599CA85D@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvrS6jglKAwb63yhabF89ns5h7+Tm7 xdTlj1kcmD02Td7M5rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZexbP5+p4LN0xfm9Z9gb GM+JdjFyckgImEi8m3eVFcIWk7hwbz0biC0kcIpRYuE2li5GLiB7NaPEpwfv2UESvALaEhtX LmECsVkEVCR+/rzCCGKzCZhLtG7cCFYjKhAo8Xz2Fqh6QYmTM5+ADRIRWMwocfDRPrBtzALq Ej2/W5hBbGEBT4kNr9+xQmwulfiz6BnQUA4OTgEnifv3LSHKbSUuzLnOAmHLS2x/O4cZolxT YvLNpcwTGAVnIVk3C0nLLCQtCxiZVzEK5yZm5qSXG+mlFmUmFxfn5+kVp25iBIbvwS2/VXcw 3jkncohRmoNFSZzXeusefyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MPZd/PX3PMiv9/ybe txlTbixpncjT+V5WicnLImOqa4P9Kae71YZZJ2dc8RDwebe333NKjeDxFIHgs6dtpqyps7us cWk3x6Ej+zWTFLwvzRPe0WSybNmf+Q8cu97at4odm8bYcV/o9XLR0qXx0U1SjDlvzs6KyT/a fFHghtz7deJJm2SufiuJVmIpzkg01GIuKk4EAJbWTuktAgAA
Cc: "mmusic \(E-mail\)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-22.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 08:15:01 -0000

And we have just submitted this version to the IESG for publication.

Thanks to the authors and the mailing list for the hard work throughout 
the years.

Please keep tuned for the IETF LC, Security review, Gen-ART review, and 
whatever other review this document triggers.

/Miguel

On 08/08/2012 1:27, Hadriel Kaplan wrote:
>
> FYI, these updates to the media-loopback-draft are to fix boilerplate issues and other idnits so it can be moved to publication request.
> We believe they're all fixed now.
> Nothing to see here... move along...
>
> -hadriel
>
>
> On Aug 7, 2012, at 11:25 AM, <internet-drafts@ietf.org>
>   <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           : An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
>> 	Author(s)       : Hadriel Kaplan
>>                           Kaynam Hedayat
>>                           Nagarjuna Venna
>>                           Paul E. Jones
>>                           Nathan Stratton
>> 	Filename        : draft-ietf-mmusic-media-loopback-22.txt
>> 	Pages           : 33
>> 	Date            : 2012-08-07
>>
>> Abstract:
>>     The wide deployment of Voice over IP (VoIP), Text and Video over IP
>>     services has introduced new challenges in managing and maintaining
>>     real-time voice/text/video quality, reliability, and overall
>>     performance.  In particular, media delivery is an area that needs
>>     attention.  One method of meeting these challenges is monitoring
>>     the media delivery performance by looping media back to the
>>     transmitter.  This is typically referred to as "active monitoring"
>>     of services.   Media loopback is especially popular in ensuring the
>>     quality of transport to the edge of a given VoIP, Real-time Text or
>>     Video over IP service.  Today in networks that deliver real-time
>>     media, short of running 'ping' and 'traceroute' to the edge,
>>     administrators are left without the necessary tools to actively
>>     monitor, manage, and diagnose quality issues with their service.
>>     The extension defined herein adds new SDP media types and
>>     attributes, which enable establishment of media sessions where the
>>     media is looped back to the transmitter. Such media sessions will
>>     serve as monitoring and troubleshooting tools by providing the
>>     means for measurement of more advanced VoIP, Real-time Text and
>>     Video over IP performance metrics.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-22
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-media-loopback-22
>>
>>
>> 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
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From harald@alvestrand.no  Wed Aug  8 02:11:42 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC82A21F859F for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 02:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.157
X-Spam-Level: 
X-Spam-Status: No, score=-109.157 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=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 qRl-m394FBVY for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 02:11:41 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7121F850D for <mmusic@ietf.org>; Wed,  8 Aug 2012 02:11:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3A7739E058 for <mmusic@ietf.org>; Wed,  8 Aug 2012 11:11: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 u9T-rPANTH1S for <mmusic@ietf.org>; Wed,  8 Aug 2012 11:11:33 +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 5841E39E106 for <mmusic@ietf.org>; Wed,  8 Aug 2012 11:11:33 +0200 (CEST)
Message-ID: <50222D44.5040105@alvestrand.no>
Date: Wed, 08 Aug 2012 11:11:32 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>
In-Reply-To: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 09:11:42 -0000

On 08/01/2012 08:56 PM, Jonathan Lennox wrote:
> As I mentioned at the mic, BUNDLE currently generates an implicit combined description of the bundled RTP session, and a lot of the problems and standardization issues we're having relate to the fact that the bundled session's media description is implicit.  Therefore, you need a lot of language specifying when parts of bundled m=lines must be the same, when they must be different, and when they may be independent.  Such specifications would need to be defined for every existing SDP attribute used in offer-answer, and every new SDP attribute going forward.
>
> The alternative to having an implicit description, I think, would be to have an explicit description.  The basic idea is to have a new m-line representing the bundled session explicitly, defined in a way that a non-bundle-aware endpoint should see it as an unknown type of m-line and reject it.  The BUNDLE grouping semantic then says that you either use all the traditional m-lines, rejecting the bundled one, or you use the one bundled m-line, rejecting all the others.
Deja vu! I think we discussed this option (really fixing the rtpmap 
syntax) a year ago, and dropped it because it was too big a change....

It's cleaner, MUCH cleaner. The biggest disadvantage I see at the moment 
(not knowing anything about how the interop would work out) is that it's 
another reset.

>
> As a straw man example, a variant of bundle-negotiation-00's example offer with ICE:
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>         t=0 0
>         a=group:BUNDLE foo bar baz
Nit: I think the bundled a=mid should be first.... we might want to call 
the grouping something other than BUNDLE, since that name is already 
showing up in implementations, assuming the current syntax...
>         m=audio 10000 RTP/AVP 0 8 97
>         a=mid:foo
>         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
>         m=video 10002 RTP/AVP 31 32
>         a=mid:bar
>         b=AS:1000
>         a=rtpmap:31 H261/90000
>         a=rtpmap:32 MPV/90000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
>         m=bundle 10000 RTP/AVP 0 8 97 31 32
>         a=mid:baz
>         b=AS:1200
>         a=full-rtpmap:0 audio/PCMU/8000
>         a=full-rtpmap:8 audio/PCMA/8000
>         a=full-rtpmap:97 audio/iLBC/8000
>         a=full-rtpmap:31 video/H261/90000
>         a=full-rtpmap:32 video/MPV/90000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>
> Points to note:
>
> * Outside the m=bundle line and its attributes, this is entirely current-standard SDP.
>
> * The m=bundle is a complete description of an entirely separate m-line; if it's used, the other m-lines in the group are rejected and the information they carry is ignored.
>
> * We'll need to make sure that we have a syntax for this new m-line (what I've called m=bundle) that existing implementations will reject (with port 0), rather than interpreting as an SDP syntax error.  We'll need input from interop people to know what's safe to do here.
Interop's what's currently giving us trouble with the current 
description proposal, so I agree that's critical.
>
> * The ports and ICE candidates specified in the m=bundle line are entirely up to the whim of the offerer; they may overlap with one of the other m-lines, but don't have to.
>
> * Because the media type of the payload types isn't given by the m-line, we need new syntax to specify the top-level media type.  I've called this "full-rtpmap", but this is just a strawman.
I'd like to call it "mime-rtp-map", but that's my personal bias showing 
:-) (the bad thing about current rtpmap is that it maps only part of the 
mime type).
>
> * Because there's one list of payload types, the RFC 3264 payload preference order needs a bit of finessing. I'd suggest saying that the preference order should be interpreted independently per media type.
>
> * There's obviously no way to do a=sendonly/recvonly independently for audio and video; you'd need to do it on the source level, with (if you're doing it in SDP) something like my source-selection draft.
>
> * There's an obvious syntax to send an offer that means "support BUNDLE, or fail" -- just send the m=bundle line, without the grouped independent lines.  Whether we'd want to allow such an offer is a separate question.
I don't see a reason to forbid it :-) - once all the equipment that 
doesn't do BUNDLE is decommissioned, we can get rid of the m=<type> 
syntax altogether and just regard "m=bundle" as a token that we keep 
around for historical reasons.

Ever the optimist!


From brett@broadsoft.com  Wed Aug  8 04:53:44 2012
Return-Path: <brett@broadsoft.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB421F85E1 for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 04:53:44 -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 bWwNCPyveGmX for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 04:53:44 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B021F85E0 for <mmusic@ietf.org>; Wed,  8 Aug 2012 04:53:44 -0700 (PDT)
Received: from casumhub01.citservers.local (172.16.98.57) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 8 Aug 2012 04:57:10 -0700
Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 8 Aug 2012 04:57:10 -0700
From: Brett Tate <brett@broadsoft.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Wed, 8 Aug 2012 04:53:41 -0700
Thread-Topic: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: Ac1z5irXaxvG+6IYTyi3BKqjoBMk/ABMAh4wAA/knVA=
Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 11:53:45 -0000

> > Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the=20
> > following.
> >
> > "In general, session-level values are the default for all=20
> > media unless overridden by an equivalent media-level value."
> >
> > "The connection ("c=3D") and attribute ("a=3D") information=20
> > in the session-level section applies to all the media of=20
> > that session unless overridden by connection information=20
> > or an attribute of the same name in the media description.
> > For instance, in the example below, each media behaves=20
> > as if it were given a "recvonly" attribute."
> >
> > If the attributes are related but with different names=20
> > (such as "inactive" and "sendrecv"), does the attribute=20
> > at the media-level have precedence over the value at the=20
> > session-level?  If so, I recommend that the draft be=20
> > updated to clarify the topic.
>=20
> I believe so. at least that is my understanding from the=20
> text. Does it really need clarification? Thoughts?

I think that it should be clarified because it is unclear if "an attribute =
of the same name" indicates the typical situation or only situation concern=
ing application of "unless overridden by an equivalent media-level value". =
 For instance if I sent "a=3Dinactive" at session-level and "a=3Dsendrecv" =
at media-level, I'd be concerned that the receiver may interpret the SDP as=
 being abnormal (such as including both values at media-level) instead of a=
llowing "a=3Dsendrecv" to override "a=3Dinactive".

In case it matters from an extendibility perspective, requiring the same na=
me might make it easier to recognize the override.  However since section 6=
 already introduces complications with defaulting to "sendrecv" if a new op=
tion is defined/used and unknown, allowing the override even when the names=
 are not the same doesn't make things too much worse; it actually allows co=
mmunication of a backup attribute (such as "a=3Dinactive") if they don't un=
derstand the preferred new attribute (such as "a=3Dfoo").

"If none of the attributes "sendonly", "recvonly", "inactive",=20
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the conference type
"broadcast" or "H332" (see below)."

Thanks for the response,
Brett


From bernard_aboba@hotmail.com  Wed Aug  8 05:06:53 2012
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CC321F8540 for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 05:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.727
X-Spam-Level: 
X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=-0.524, 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 6MvAAIqv0bJk for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 05:06:53 -0700 (PDT)
Received: from blu0-omc2-s23.blu0.hotmail.com (blu0-omc2-s23.blu0.hotmail.com [65.55.111.98]) by ietfa.amsl.com (Postfix) with ESMTP id 052EA21F853A for <mmusic@ietf.org>; Wed,  8 Aug 2012 05:06:52 -0700 (PDT)
Received: from BLU401-EAS126 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Aug 2012 05:06:52 -0700
X-Originating-IP: [24.16.96.166]
X-EIP: [gAzfr63RcB0rJy8IemvHcxMM7n8P3quO]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no>
Content-Transfer-Encoding: quoted-printable
From: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <50222D44.5040105@alvestrand.no>
Date: Wed, 8 Aug 2012 05:06:49 -0700
To: Harald Alvestrand <harald@alvestrand.no>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 08 Aug 2012 12:06:52.0585 (UTC) FILETIME=[4BFCD990:01CD755E]
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 12:06:53 -0000

> Deja vu! I think we discussed this option (really fixing the rtpmap syntax=
) a year ago, and dropped it because it was too big a change.

> It's cleaner, MUCH cleaner. The biggest disadvantage I see at the moment (=
not knowing anything about how the interop would work out) is that it's anot=
her reset.

[BA] There are other issues as well. How do you express the desire to multip=
lex a layered codec which is itself a grouping in Jonathan's proposal?=20


From harald@alvestrand.no  Wed Aug  8 05:17:18 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08A21F8620 for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 05:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.303
X-Spam-Level: 
X-Spam-Status: No, score=-110.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 o0Xhgl+CXppe for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 05:17:17 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93F21F861A for <mmusic@ietf.org>; Wed,  8 Aug 2012 05:17:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 660C839E106; Wed,  8 Aug 2012 14:17:16 +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 EqaiHcvIzWXy; Wed,  8 Aug 2012 14:17: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 8C68439E058; Wed,  8 Aug 2012 14:17:15 +0200 (CEST)
Message-ID: <502258CA.5030009@alvestrand.no>
Date: Wed, 08 Aug 2012 14:17:14 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>
In-Reply-To: <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 12:17:18 -0000

On 08/08/2012 02:06 PM, Bernard Aboba wrote:
>> Deja vu! I think we discussed this option (really fixing the rtpmap syntax) a year ago, and dropped it because it was too big a change.
>> It's cleaner, MUCH cleaner. The biggest disadvantage I see at the moment (not knowing anything about how the interop would work out) is that it's another reset.
> [BA] There are other issues as well. How do you express the desire to multiplex a layered codec which is itself a grouping in Jonathan's proposal?
>
Bernard, since I'm so easily confused by how people transmit layers of 
layered codecs, can you illustrate the particular scheme you want to 
use, and can't think of how to represent in Jonathan's scheme?

("same SSRC in multiple RTP sessions" is quite hard to multiplex; 
"different SSRCs in one RTP session" doesn't seem to affect this 
proposal at all)

                        Harald

From dwing@cisco.com  Wed Aug  8 09:05:20 2012
Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2035C21F86EB for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 09:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.497
X-Spam-Level: 
X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 BJzZlZYr15QW for <mmusic@ietfa.amsl.com>; Wed,  8 Aug 2012 09:05:15 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BE10521F86F1 for <mmusic@ietf.org>; Wed,  8 Aug 2012 09:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4667; q=dns/txt; s=iport; t=1344441915; x=1345651515; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=wiFXNJPYTozMgFwBc/QFXcHC/2odtILn+wqQTtMoqTw=; b=ImapeAjW7tsxNsNOLmBFWNzMwGFpzcwYBH7mcZrCVCsAYAqwli26E8+c sESZy1P0gUaBFhnzrceN57S1wfhSpWpDG2dRa921tg84P0fKzapYPIrY2 KO5mUBXfOOvj3dPSjfzwymRBthKshUQD5DDirPPx5X4EF3yw0ivqk+RmC s=;
X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208";a="51333947"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 08 Aug 2012 16:05:14 +0000
Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q78G5EAt017360; Wed, 8 Aug 2012 16:05:14 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Pal Martinsen \(palmarti\)'" <palmarti@cisco.com>, "'Jonathan Lennox'" <jonathan@vidyo.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com>
In-Reply-To: <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com>
Date: Wed, 8 Aug 2012 09:05:14 -0700
Message-ID: <0e2801cd757f$98a72680$c9f57380$@com>
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: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAOZDYCAALjLgIAAVdMAgAAsKgCAAJB/AIABDntw
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 16:05:21 -0000

> -----Original Message-----
> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]
> Sent: Tuesday, August 07, 2012 11:30 AM
> To: Jonathan Lennox
> Cc: Dan Wing (dwing); Ari Keranen; mmusic@ietf.org
> Subject: Re: [MMUSIC] ICE candidate address selection update draft
>=20
>=20
> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com>
> wrote:
>=20
> > On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',
> 'Ari Keranen', mmusic@ietf.org" saying:
> >
> >> Mine would be to take the list of IPv6 and IPv4 addresses and try
> them
> >> in the order described by ICE (which currently recommends following
> >> the OS's default, which is sometimes hard to get depending on the
> OS).
>=20
> From a ICE multi platform library developer that is somewhat of a
> nightmare.
> Guess it can be solved by having a reasonable interface that the
> application
> that uses the library can fill in the defaults. Having reasonable
> default values
> is important as some platforms might not be able to set the values.
>=20
> >>
> >> But if the first IPv6 candidate didn't return a connectivity checks
> >> quickly (let's say, 150ms), initiate a connectivity check on the
> >> highest priority IPv4 address next.  In that 150ms, based on ICE's
> >> pacing, many IPv6 addresses will have been tried.  150ms gives
> plenty
> >> of time for IPv6 to 'win', before using an IPv4 resource that is
> >> likely shared with IPv4-only devices.
> >
> > Can't this result in the endpoints getting out of sync with the =
order
> of the checklist?  If one side has started IPv4 while the other =
hasn't,
> you won't have the outbound packets coming from one side to create the
> port bindings.
> >
> It can at least potentially introduce more "kamikaze" packets and =
delay
> the result. The STUN transaction have 10 retransmits and would timeout
> long after the checklist is empty.
>=20
> To maintain the speed of ICE negotiation and keep call setup times low
> I think we should consider looking at the pacing of the conn checks.
> The rationale behind the pacing was not to overwhelm the NATs.

Yes.  And also to reduce the concern that ICE connectivity checks=20
could flood a link.

> Have the
> world move slightly towards better NATs? Looking from the perspective
> of an endpoint sending 1080p60 video streams the pacing seem a bit
> conservative?

The problem, even at the time, was not pps or bandwidth throughput of
the NATs.  Rather, it was that NATs would not create new mappings
quick enough and drop the STUN Binding Request.  This would be re-
transmitted and make it through the NAT, but that retransmit was=20
obviously harmful for call setup times.  As all the connectivity
checks are supposed to be sent from the same source address and
port on the client, a new mapping is only necessary for NATs which
have "address dependent mapping" or "address and port dependent
mapping" behavior.

I just checked, and couldn't find a test of UDP mapping speed
at http://nattest.net.in.tum.de/results.php,=20
draft-jennings-behave-test-results, or=20
http://eggert.org/papers/2010-imc-hgw-study.pdf.  Perhaps there
are tests available somewhere else.

> And how does the different paths (IPv4, IPv6, multi
> homed) impact the pacing? Could we do more in parallel without
> overwhelm the NATs?

I'm sure we could.

We could also be more aggressive with STUN retransmissions, and
less aggressive at trying new candidates.  That depends on our=20
confidence that the candidates are in the proper order, and if
we can move a connection to a new candidate.  RTP can be moved
pretty easily; TCP cannot.  Before ICE completes, we could move
RTP sessions around without draft-wing-mmusic-ice-mobility.

It is probably worth backing up and enumerating the problem(s) we=20
have with ICE, and then deciding what we want to solve.

> I am wondering if we could do something smart with prioritising the
> checklist and triggered checks to make sure IPv6 wins if there is
> connectivity? I have to little understanding if IPv6 and all the
> different addresses to clearly formulate the idea at the moment.
> (Hoping this may trigger something for someone.)

ICE was written before there was wide acceptance that the IPv6 path
is sometimes broken.  Tweaking ICE to better accommodate that reality
seems worthwhile.

-d


>=20
> .-.
> P=E5l-Erik
>=20
>=20
> > --
> > Jonathan Lennox
> > jonathan@vidyo.com
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic


From bernard_aboba@hotmail.com  Thu Aug  9 09:57:21 2012
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760FA21F875C for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 09:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.764
X-Spam-Level: 
X-Spam-Status: No, score=-100.764 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=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 CoE54iHuAglm for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 09:57:20 -0700 (PDT)
Received: from blu0-omc1-s5.blu0.hotmail.com (blu0-omc1-s5.blu0.hotmail.com [65.55.116.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DF21F8644 for <mmusic@ietf.org>; Thu,  9 Aug 2012 09:57:20 -0700 (PDT)
Received: from BLU002-W140 ([65.55.116.7]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 9 Aug 2012 09:57:20 -0700
Message-ID: <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
Content-Type: multipart/alternative; boundary="_2bd16725-02e6-4120-9e53-f5ee1c9557b2_"
X-Originating-IP: [24.16.96.166]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 9 Aug 2012 09:57:19 -0700
Importance: Normal
In-Reply-To: <502258CA.5030009@alvestrand.no>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>, <502258CA.5030009@alvestrand.no>
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Aug 2012 16:57:20.0082 (UTC) FILETIME=[09FF9B20:01CD7650]
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 16:57:21 -0000

--_2bd16725-02e6-4120-9e53-f5ee1c9557b2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Harald said:=20
> Bernard=2C since I'm so easily confused by how people transmit layers of=
=20
> layered codecs=2C can you illustrate the particular scheme you want to=20
> use=2C and can't think of how to represent in Jonathan's scheme?

[BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP"=
. An
example of how this would be used with H.264/SVC is included in RFC 6190=2C=
 Section 7.3.4:

      a=3Dgroup:DDP L1 L2=0A=
      m=3Dvideo 20000 RTP/AVP 96=0A=
      a=3Drtpmap:96 H264/90000=0A=
      a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bmst=
-mode=3DNI-T=3B=0A=
      a=3Dmid:L1=0A=
      m=3Dvideo 20002 RTP/AVP 97=0A=
      a=3Drtpmap:97 H264-SVC/90000=0A=
      a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<2=2C0=2C1=2C0=2C53=
000c=2C=0A=
      3200=2C352=2C288=2C384=2C512>=2C<3=2C1=2C2=2C0=2C53001F=2C6400=2C704=
=2C576=2C768=2C1024>=3B=0A=
      a=3Dmid:L2=0A=
      a=3Ddepend:97 lay L1:96
Here the a=3Ddepend line is expressing the decoding dependency (layered in =
this case).=20

Let us assume that there is also audio=2C as in Jonathan's example:

       m=3Daudio 10000 RTP/AVP 0 8 97=0A=
       a=3Dmid:foo=0A=
       b=3DAS:200=0A=
       a=3Drtpmap:0 PCMU/8000=0A=
       a=3Drtpmap:8 PCMA/8000=0A=
       a=3Drtpmap:97 iLBC/8000
Does the entire SDP offer with BUNDLE and dependency grouping  look like th=
is (ignoring RTP/RTCP mux for the moment)?=20

       v=3D0=0A=
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com=0A=
       s=3D=0A=
       c=3DIN IP4 host.atlanta.com=0A=
       t=3D0 0=0A=
       a=3Dgroup:BUNDLE foo L1 L2 baz
       a=3Dgroup:DDP L1 L2=0A=
       m=3Daudio 10000 RTP/AVP 0 8 98=0A=
       a=3Dmid:foo=0A=
       b=3DAS:200=0A=
       a=3Drtpmap:0 PCMU/8000=0A=
       a=3Drtpmap:8 PCMA/8000=0A=
       a=3Drtpmap:98 iLBC/8000=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A=
       m=3Dvideo 20000 RTP/AVP 96=0A=
       a=3Drtpmap:96 H264/90000=0A=
       a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bms=
t-mode=3DNI-T=3B=0A=
       a=3Dmid:L1=0A=
       m=3Dvideo 20002 RTP/AVP 97=0A=
       a=3Drtpmap:97 H264-SVC/90000=0A=
       a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=
=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<2=2C0=2C1=2C0=2C53=
000c=2C=0A=
      3200=2C352=2C288=2C384=2C512>=2C<3=2C1=2C2=2C0=2C53001F=2C6400=2C704=
=2C576=2C768=2C1024>=3B=0A=
       a=3Dmid:L2=0A=
       a=3Ddepend:97 lay L1:96=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host=0A=
       m=3Dbundle 10000 RTP/AVP 0 8 96 97 98=0A=
       a=3Dmid:baz=0A=
       b=3DAS:1200=0A=
       a=3Dfull-rtpmap:0 audio/PCMU/8000=0A=
       a=3Dfull-rtpmap:8 audio/PCMA/8000=0A=
       a=3Dfull-rtpmap:98 audio/iLBC/8000=0A=
       a=3Dfull-rtpmap:96 H264/90000=0A=
       a=3Dfull-rtpmap:97 H264-SVC/90000=0A=
       a=3Ddepend:97 lay L1:96=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A=

 =0A=

 		 	   		  =

--_2bd16725-02e6-4120-9e53-f5ee1c9557b2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'><br>Harald said: <br><div>&gt=3B=
 Bernard=2C since I'm so easily confused by how people transmit layers of <=
br>&gt=3B layered codecs=2C can you illustrate the particular scheme you wa=
nt to <br>&gt=3B use=2C and can't think of how to represent in Jonathan's s=
cheme?<br><br>[BA]&nbsp=3B I am looking at RFC 5583 "Signaling Media Decodi=
ng Dependency in SDP". An<br>example of how this would be used with H.264/S=
VC is included in RFC 6190=2C Section 7.3.4:<br><br><pre>      a=3Dgroup:DD=
P L1 L2=0A=
      m=3Dvideo 20000 RTP/AVP 96=0A=
      a=3Drtpmap:96 H264/90000=0A=
      a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bmst=
-mode=3DNI-T=3B=0A=
      a=3Dmid:L1=0A=
      m=3Dvideo 20002 RTP/AVP 97=0A=
      a=3Drtpmap:97 H264-SVC/90000=0A=
      a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D&lt=3B2=2C0=2C1=2C0=
=2C53000c=2C=0A=
      3200=2C352=2C288=2C384=2C512&gt=3B=2C&lt=3B3=2C1=2C2=2C0=2C53001F=2C6=
400=2C704=2C576=2C768=2C1024&gt=3B=3B=0A=
      a=3Dmid:L2=0A=
      a=3Ddepend:97 lay L1:96</pre><br>Here the a=3Ddepend line is expressi=
ng the decoding dependency (layered in this case). <br><br>Let us assume th=
at there is also audio=2C as in Jonathan's example:<br><br><pre>       m=3D=
audio 10000 RTP/AVP 0 8 97=0A=
       a=3Dmid:foo=0A=
       b=3DAS:200=0A=
       a=3Drtpmap:0 PCMU/8000=0A=
       a=3Drtpmap:8 PCMA/8000=0A=
       a=3Drtpmap:97 iLBC/8000</pre><br>Does the entire SDP offer with BUND=
LE and dependency grouping&nbsp=3B look like this (ignoring RTP/RTCP mux fo=
r the moment)? <br><br><pre>       v=3D0=0A=
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com=0A=
       s=3D=0A=
       c=3DIN IP4 host.atlanta.com=0A=
       t=3D0 0=0A=
       a=3Dgroup:BUNDLE foo L1 L2 baz<br>       a=3Dgroup:DDP L1 L2=0A=
      &nbsp=3Bm=3Daudio 10000 RTP/AVP 0 8 98=0A=
       a=3Dmid:foo=0A=
       b=3DAS:200=0A=
       a=3Drtpmap:0 PCMU/8000=0A=
       a=3Drtpmap:8 PCMA/8000=0A=
       a=3Drtpmap:98 iLBC/8000=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A=
       m=3Dvideo 20000 RTP/AVP 96=0A=
       a=3Drtpmap:96 H264/90000=0A=
       a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bms=
t-mode=3DNI-T=3B=0A=
       a=3Dmid:L1=0A=
       m=3Dvideo 20002 RTP/AVP 97=0A=
       a=3Drtpmap:97 H264-SVC/90000=0A=
       a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=
=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D&lt=3B2=2C0=2C1=2C0=
=2C53000c=2C=0A=
      3200=2C352=2C288=2C384=2C512&gt=3B=2C&lt=3B3=2C1=2C2=2C0=2C53001F=2C6=
400=2C704=2C576=2C768=2C1024&gt=3B=3B=0A=
       a=3Dmid:L2=0A=
       a=3Ddepend:97 lay L1:96=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host=0A=
       m=3Dbundle 10000 RTP/AVP 0 8 96 97 98=0A=
       a=3Dmid:baz=0A=
       b=3DAS:1200=0A=
       a=3Dfull-rtpmap:0 audio/PCMU/8000=0A=
       a=3Dfull-rtpmap:8 audio/PCMA/8000=0A=
       a=3Dfull-rtpmap:98 audio/iLBC/8000=0A=
       a=3Dfull-rtpmap:96 H264/90000=0A=
       a=3Dfull-rtpmap:97 H264-SVC/90000=0A=
       a=3Ddepend:97 lay L1:96=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A=
</pre><br><pre> =0A=
</pre><br></div> 		 	   		  </div></body>
</html>=

--_2bd16725-02e6-4120-9e53-f5ee1c9557b2_--

From palmarti@cisco.com  Thu Aug  9 10:13:32 2012
Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9572B21F86EC for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 10:13: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=[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 KmGQmrT1eMSg for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 10:13:31 -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 8713D21F86E4 for <mmusic@ietf.org>; Thu,  9 Aug 2012 10:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=palmarti@cisco.com; l=5468; q=dns/txt; s=iport; t=1344532411; x=1345742011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MVocEhtwzvd9zd3OYnRhDxgDDZ21twa1RL0hTa1WQS0=; b=VXLuATjM88+31xEf2C61NLoPKcVVlnzQMfAeRGpeHL+MSglCG8epOawT mBE3eOMPX2t2EWC0OY5/MJujYJmJhCmVdf/BcU0mlCMmm5q4kPM3ttZMu /Q8VqP0St9TdRFnO2zNdrix9MQCm3VmLuivV519XFdGiPgKgEqdOT/fDB A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIzgI1CtJXG//2dsb2JhbAArGrligQeCIAEBAQIBAQEBAQ8BWwsFBwQCAQgRBAEBAScHJwsUCQgCBA4FHgSHZQYLKppRoG2LD4YEYAOIGYlMg2SBFIlxgySBZoJf
X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="110059695"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2012 17:13:31 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q79HDUZa016420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 17:13:30 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 12:13:30 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: "Dan Wing (dwing)" <dwing@cisco.com>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAOZDYCAALjLgIAAVdMAgAAsKgCAAJB/AIABDntwgAIAu4A=
Date: Thu, 9 Aug 2012 17:13:29 +0000
Message-ID: <E7E7FFBC-D6FE-4444-8AA3-9DCE43E02FE4@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com> <0e2801cd757f$98a72680$c9f57380$@com>
In-Reply-To: <0e2801cd757f$98a72680$c9f57380$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.83.176]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19096.006
x-tm-as-result: No--51.293400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <BBEC15B23C3CBB4285664F00FD16C574@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox <jonathan@vidyo.com>, "<mmusic@ietf.org>" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 17:13:32 -0000

On Aug 8, 2012, at 6:05 PM, Dan Wing <dwing@cisco.com> wrote:

>> -----Original Message-----
>> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]
>> Sent: Tuesday, August 07, 2012 11:30 AM
>> To: Jonathan Lennox
>> Cc: Dan Wing (dwing); Ari Keranen; mmusic@ietf.org
>> Subject: Re: [MMUSIC] ICE candidate address selection update draft
>>=20
>>=20
>> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com>
>> wrote:
>>=20
>>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',
>> 'Ari Keranen', mmusic@ietf.org" saying:
>>>=20
>>>> Mine would be to take the list of IPv6 and IPv4 addresses and try
>> them
>>>> in the order described by ICE (which currently recommends following
>>>> the OS's default, which is sometimes hard to get depending on the
>> OS).
>>=20
>> From a ICE multi platform library developer that is somewhat of a
>> nightmare.
>> Guess it can be solved by having a reasonable interface that the
>> application
>> that uses the library can fill in the defaults. Having reasonable
>> default values
>> is important as some platforms might not be able to set the values.
>>=20
>>>>=20
>>>> But if the first IPv6 candidate didn't return a connectivity checks
>>>> quickly (let's say, 150ms), initiate a connectivity check on the
>>>> highest priority IPv4 address next.  In that 150ms, based on ICE's
>>>> pacing, many IPv6 addresses will have been tried.  150ms gives
>> plenty
>>>> of time for IPv6 to 'win', before using an IPv4 resource that is
>>>> likely shared with IPv4-only devices.
>>>=20
>>> Can't this result in the endpoints getting out of sync with the order
>> of the checklist?  If one side has started IPv4 while the other hasn't,
>> you won't have the outbound packets coming from one side to create the
>> port bindings.
>>>=20
>> It can at least potentially introduce more "kamikaze" packets and delay
>> the result. The STUN transaction have 10 retransmits and would timeout
>> long after the checklist is empty.
>>=20
>> To maintain the speed of ICE negotiation and keep call setup times low
>> I think we should consider looking at the pacing of the conn checks.
>> The rationale behind the pacing was not to overwhelm the NATs.
>=20
> Yes.  And also to reduce the concern that ICE connectivity checks=20
> could flood a link.
>=20
>> Have the
>> world move slightly towards better NATs? Looking from the perspective
>> of an endpoint sending 1080p60 video streams the pacing seem a bit
>> conservative?
>=20
> The problem, even at the time, was not pps or bandwidth throughput of
> the NATs.  Rather, it was that NATs would not create new mappings
> quick enough and drop the STUN Binding Request.  This would be re-
> transmitted and make it through the NAT, but that retransmit was=20
> obviously harmful for call setup times.  As all the connectivity
> checks are supposed to be sent from the same source address and
> port on the client, a new mapping is only necessary for NATs which
> have "address dependent mapping" or "address and port dependent
> mapping" behavior.
>=20
> I just checked, and couldn't find a test of UDP mapping speed
> at http://nattest.net.in.tum.de/results.php,=20
> draft-jennings-behave-test-results, or=20
> http://eggert.org/papers/2010-imc-hgw-study.pdf.  Perhaps there
> are tests available somewhere else.
>=20
Thanks for clearing that up.

>> And how does the different paths (IPv4, IPv6, multi
>> homed) impact the pacing? Could we do more in parallel without
>> overwhelm the NATs?
>=20
> I'm sure we could.
>=20
> We could also be more aggressive with STUN retransmissions, and
> less aggressive at trying new candidates.  That depends on our=20
> confidence that the candidates are in the proper order, and if
> we can move a connection to a new candidate.  RTP can be moved
> pretty easily; TCP cannot.  Before ICE completes, we could move
> RTP sessions around without draft-wing-mmusic-ice-mobility.
>=20
More agressive STUN retransmits would help speeding up things for RFLX=20
candidates.

> It is probably worth backing up and enumerating the problem(s) we=20
> have with ICE, and then deciding what we want to solve.
>=20
Yes, you are right.

Keeping the number of connectivity checks at a minimum by removing the=20
ones that will never work as this documents describes is probably what we
want from this document.=20

>> I am wondering if we could do something smart with prioritising the
>> checklist and triggered checks to make sure IPv6 wins if there is
>> connectivity? I have to little understanding if IPv6 and all the
>> different addresses to clearly formulate the idea at the moment.
>> (Hoping this may trigger something for someone.)
>=20
> ICE was written before there was wide acceptance that the IPv6 path
> is sometimes broken.  Tweaking ICE to better accommodate that reality
> seems worthwhile.

Prioritising IPv6 over IPv4 is all about choosing from the valid_list and t=
hat is=20
currently up to the different implementations to decide. Is it worthwhile h=
aving=20
a separate document describing that?

.-.
P=E5l-Erik

>=20
> -d
>=20
>=20
>>=20
>> .-.
>> P=E5l-Erik
>>=20
>>=20
>>> --
>>> Jonathan Lennox
>>> jonathan@vidyo.com
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>=20


From dwing@cisco.com  Thu Aug  9 10:40:34 2012
Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934F821F879E for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 10:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.504
X-Spam-Level: 
X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 sBLe9ouaBZup for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 10:40:33 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3921F878E for <mmusic@ietf.org>; Thu,  9 Aug 2012 10:40:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6716; q=dns/txt; s=iport; t=1344534033; x=1345743633; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=EOysE1rGzvTIWGGXsA08fJ5K8N9SUmZitu2hYQDZb5o=; b=NTPFuBvAXAk/65BGxPQ0TgMpk95e+xvtqeCOz1nM3n0R07XyK6+TFNVY tUe8Xxi6Mo9mvVrtTOKQc6ktDClHu961QCwmo93XCgOJrZguTmC8hLKSU /NJM6jTEpSjEqH85zqTqoboEmxfSZ0AXq7CJHJA0p+6jg3vi0DbEBLTsA w=;
X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="54482175"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 17:40:33 +0000
Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q79HeX1l017339; Thu, 9 Aug 2012 17:40:33 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Pal Martinsen \(palmarti\)'" <palmarti@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com> <0e2801cd757f$98a72680$c9f57380$@com> <E7E7FFBC-D6FE-4444-8AA3-9DCE43E02FE4@cisco.com>
In-Reply-To: <E7E7FFBC-D6FE-4444-8AA3-9DCE43E02FE4@cisco.com>
Date: Thu, 9 Aug 2012 10:40:33 -0700
Message-ID: <04c701cd7656$13b9ef70$3b2dce50$@com>
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: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAOZDYCAALjLgIAAVdMAgAAsKgCAAJB/AIABDntwgAIAu4D//7Jz4A==
Content-Language: en-us
Cc: 'Jonathan Lennox' <jonathan@vidyo.com>, mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 17:40:34 -0000

> -----Original Message-----
> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]
> Sent: Thursday, August 09, 2012 10:13 AM
> To: Dan Wing (dwing)
> Cc: Jonathan Lennox; Ari Keranen; <mmusic@ietf.org>
> Subject: Re: [MMUSIC] ICE candidate address selection update draft
>=20
>=20
> On Aug 8, 2012, at 6:05 PM, Dan Wing <dwing@cisco.com> wrote:
>=20
> >> -----Original Message-----
> >> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]
> >> Sent: Tuesday, August 07, 2012 11:30 AM
> >> To: Jonathan Lennox
> >> Cc: Dan Wing (dwing); Ari Keranen; mmusic@ietf.org
> >> Subject: Re: [MMUSIC] ICE candidate address selection update draft
> >>
> >>
> >> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com>
> >> wrote:
> >>
> >>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',
> >> 'Ari Keranen', mmusic@ietf.org" saying:
> >>>
> >>>> Mine would be to take the list of IPv6 and IPv4 addresses and try
> >> them
> >>>> in the order described by ICE (which currently recommends
> following
> >>>> the OS's default, which is sometimes hard to get depending on the
> >> OS).
> >>
> >> From a ICE multi platform library developer that is somewhat of a
> >> nightmare.
> >> Guess it can be solved by having a reasonable interface that the
> >> application
> >> that uses the library can fill in the defaults. Having reasonable
> >> default values
> >> is important as some platforms might not be able to set the values.
> >>
> >>>>
> >>>> But if the first IPv6 candidate didn't return a connectivity
> checks
> >>>> quickly (let's say, 150ms), initiate a connectivity check on the
> >>>> highest priority IPv4 address next.  In that 150ms, based on =
ICE's
> >>>> pacing, many IPv6 addresses will have been tried.  150ms gives
> >> plenty
> >>>> of time for IPv6 to 'win', before using an IPv4 resource that is
> >>>> likely shared with IPv4-only devices.
> >>>
> >>> Can't this result in the endpoints getting out of sync with the
> order
> >> of the checklist?  If one side has started IPv4 while the other
> hasn't,
> >> you won't have the outbound packets coming from one side to create
> the
> >> port bindings.
> >>>
> >> It can at least potentially introduce more "kamikaze" packets and
> delay
> >> the result. The STUN transaction have 10 retransmits and would
> timeout
> >> long after the checklist is empty.
> >>
> >> To maintain the speed of ICE negotiation and keep call setup times
> low
> >> I think we should consider looking at the pacing of the conn =
checks.
> >> The rationale behind the pacing was not to overwhelm the NATs.
> >
> > Yes.  And also to reduce the concern that ICE connectivity checks
> > could flood a link.
> >
> >> Have the
> >> world move slightly towards better NATs? Looking from the
> perspective
> >> of an endpoint sending 1080p60 video streams the pacing seem a bit
> >> conservative?
> >
> > The problem, even at the time, was not pps or bandwidth throughput =
of
> > the NATs.  Rather, it was that NATs would not create new mappings
> > quick enough and drop the STUN Binding Request.  This would be re-
> > transmitted and make it through the NAT, but that retransmit was
> > obviously harmful for call setup times.  As all the connectivity
> > checks are supposed to be sent from the same source address and
> > port on the client, a new mapping is only necessary for NATs which
> > have "address dependent mapping" or "address and port dependent
> > mapping" behavior.
> >
> > I just checked, and couldn't find a test of UDP mapping speed
> > at http://nattest.net.in.tum.de/results.php,
> > draft-jennings-behave-test-results, or
> > http://eggert.org/papers/2010-imc-hgw-study.pdf.  Perhaps there
> > are tests available somewhere else.
> >
> Thanks for clearing that up.
>=20
> >> And how does the different paths (IPv4, IPv6, multi
> >> homed) impact the pacing? Could we do more in parallel without
> >> overwhelm the NATs?
> >
> > I'm sure we could.
> >
> > We could also be more aggressive with STUN retransmissions, and
> > less aggressive at trying new candidates.  That depends on our
> > confidence that the candidates are in the proper order, and if
> > we can move a connection to a new candidate.  RTP can be moved
> > pretty easily; TCP cannot.  Before ICE completes, we could move
> > RTP sessions around without draft-wing-mmusic-ice-mobility.
> >
> More agressive STUN retransmits would help speeding up things for RFLX
> candidates.
>=20
> > It is probably worth backing up and enumerating the problem(s) we
> > have with ICE, and then deciding what we want to solve.
> >
> Yes, you are right.
>=20
> Keeping the number of connectivity checks at a minimum by removing the
> ones that will never work as this documents describes is probably what
> we want from this document.

Absolutely.


Solving additional problems might belong in other documents (e.g.,
faster STUN retransmissions). =20

> >> I am wondering if we could do something smart with prioritising the
> >> checklist and triggered checks to make sure IPv6 wins if there is
> >> connectivity? I have to little understanding if IPv6 and all the
> >> different addresses to clearly formulate the idea at the moment.
> >> (Hoping this may trigger something for someone.)
> >
> > ICE was written before there was wide acceptance that the IPv6 path
> > is sometimes broken.  Tweaking ICE to better accommodate that =
reality
> > seems worthwhile.
>=20
> Prioritising IPv6 over IPv4 is all about choosing from the valid_list
> and that is
> currently up to the different implementations to decide. Is it
> worthwhile having a separate document describing that?

To my mind, that seems appropriate for this ICE Candidate Address
Selection Update document.  Right now ICE is pretty circumspect in
its IPv6/IPv4 recommendation and says to follow what the OS would
order, if possible, but doesn't provide strong recommendations if
the OS doesn't have an order.

I know there are one or two APIs in Windows that accept a bunch
of IP addresses and will re-order them.  I dunno if a similar API
is available for Android, Linux, or iOS/OS X.  Without an API on
those OSs, the ICE Candidate Address Selection Update is a good
place to make recommendations for those OSs.

-d


>=20
> .-.
> P=E5l-Erik
>=20
> >
> > -d
> >
> >
> >>
> >> .-.
> >> P=E5l-Erik
> >>
> >>
> >>> --
> >>> Jonathan Lennox
> >>> jonathan@vidyo.com
> >>> _______________________________________________
> >>> mmusic mailing list
> >>> mmusic@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >


From iesg-secretary@ietf.org  Thu Aug  9 11:30:58 2012
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EB821F8743; Thu,  9 Aug 2012 11:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 mRIhBbsxypCG; Thu,  9 Aug 2012 11:30:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401BA21F8596; Thu,  9 Aug 2012 11:30:58 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.33
Message-ID: <20120809183058.10494.72226.idtracker@ietfa.amsl.com>
Date: Thu, 09 Aug 2012 11:30:58 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] Last Call: <draft-ietf-mmusic-media-loopback-22.txt> (An Extension to	the Session Description Protocol (SDP) and Real-time Transport	Protocol (RTP) for Media Loopback) to Proposed Standard
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 18:30:59 -0000

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'An Extension to the Session Description Protocol (SDP) and Real-time
   Transport Protocol (RTP) for Media Loopback'
  <draft-ietf-mmusic-media-loopback-22.txt> 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 2012-08-23. 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


    The wide deployment of Voice over IP (VoIP), Text and Video over IP
    services has introduced new challenges in managing and maintaining
    real-time voice/text/video quality, reliability, and overall
    performance.  In particular, media delivery is an area that needs
    attention.  One method of meeting these challenges is monitoring
    the media delivery performance by looping media back to the
    transmitter.  This is typically referred to as "active monitoring"
    of services.   Media loopback is especially popular in ensuring the
    quality of transport to the edge of a given VoIP, Real-time Text or
    Video over IP service.  Today in networks that deliver real-time
    media, short of running 'ping' and 'traceroute' to the edge,
    administrators are left without the necessary tools to actively
    monitor, manage, and diagnose quality issues with their service.
    The extension defined herein adds new SDP media types and
    attributes, which enable establishment of media sessions where the
    media is looped back to the transmitter. Such media sessions will
    serve as monitoring and troubleshooting tools by providing the
    means for measurement of more advanced VoIP, Real-time Text and
    Video over IP performance metrics.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ballot/


No IPR declarations have been submitted directly on this I-D.



From christer.holmberg@ericsson.com  Thu Aug  9 16:35:52 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8521F8592 for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 16:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.266
X-Spam-Level: 
X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONaTHZLAPcK5 for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 16:35:52 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9C49421F858F for <mmusic@ietf.org>; Thu,  9 Aug 2012 16:35:51 -0700 (PDT)
X-AuditID: c1b4fb30-b7fd46d000003161-14-50244955a183
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 50.21.12641.55944205; Fri, 10 Aug 2012 01:35:50 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 10 Aug 2012 01:35:37 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 10 Aug 2012 01:35:36 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac12UA1OwO9ssswyRXO+qyX1EfCwSwANqMPv
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683630@ESESSCMS0356.eemea.ericsson.se>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>, <502258CA.5030009@alvestrand.no>, <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
In-Reply-To: <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrW6Yp0qAwaP9fBb7l1xmtjjW18Vm MXX5YxYHZo8rE66wejzuOcPmsWTJT6YA5igum5TUnMyy1CJ9uwSujOX7HrMXvJGpWD71JXsD 4zfRLkZODgkBE4kFm7tYIGwxiQv31rN1MXJxCAmcYpRoOXGeGcJZwCjxrfkVUBUHB5uAhUT3 P22QBhGBSIlHMz+ygoSZBdQlri4OAgmzCKhK3Hv9jBHEFhaIl1ixbSkzRHmCxK5JaxkhbCOJ 6ffWs4LYvALhEr03tjNCrHrKKNGw/zHYQZwC1hLzF5wGa2AEOu77qTVMIDazgLjErSfzmSCO FpBYsuc8M4QtKvHy8T9WiHpRiTvt6xkh6vUkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKUTg3MTMnvdxcL7UoM7m4OD9Przh1EyMwng5u+W2wg3HTfbFDjNIc LErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLI+3nro74Tdv9NKuqoW/Hh8cqF/ a/0zhdP2f6+fV15idtP6rM8a1l6OGYwP41e+9mvuvjFny7f+2F4lzj0XeTrEE2Le8h+o27b2 YptBfujxfjWF40r759pffXaxPq/6m8LiGeq1rNyStocnXfpwXD7hcfCJrz0ML81eqCzO9Xgs 4+B6ff8CqYVKLMUZiYZazEXFiQADMTpsdQIAAA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 23:35:52 -0000

Hi,

One question: within the m=3Dbundle description, does the "a=3Ddepend:97 la=
y L1:96" attribute provide all information needed for the decoding dependen=
cy, or does the receiver also need to look for the "a=3Dgroup:DDP L1 L2" at=
tribute?

(This is related to a more general question we need to answer: do we explic=
itly add all information to the m=3Dbundle description, or can we "referenc=
e" information from the m=3Daudio/video/etc descriptions?)

Regards,

Christer




________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Bernar=
d Aboba [bernard_aboba@hotmail.com]
Sent: Thursday, August 09, 2012 7:57 PM
To: Harald Alvestrand
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line f=
or bundled session


Harald said:
> Bernard, since I'm so easily confused by how people transmit layers of
> layered codecs, can you illustrate the particular scheme you want to
> use, and can't think of how to represent in Jonathan's scheme?

[BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP"=
. An
example of how this would be used with H.264/SVC is included in RFC 6190, S=
ection 7.3.4:


      a=3Dgroup:DDP L1 L2
      m=3Dvideo 20000 RTP/AVP 96
      a=3Drtpmap:96 H264/90000
      a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-mod=
e=3DNI-T;
      a=3Dmid:L1
      m=3Dvideo 20002 RTP/AVP 97
      a=3Drtpmap:97 H264-SVC/90000
      a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
       mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
      3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
      a=3Dmid:L2
      a=3Ddepend:97 lay L1:96

Here the a=3Ddepend line is expressing the decoding dependency (layered in =
this case).

Let us assume that there is also audio, as in Jonathan's example:


       m=3Daudio 10000 RTP/AVP 0 8 97
       a=3Dmid:foo
       b=3DAS:200
       a=3Drtpmap:0 PCMU/8000
       a=3Drtpmap:8 PCMA/8000
       a=3Drtpmap:97 iLBC/8000

Does the entire SDP offer with BUNDLE and dependency grouping  look like th=
is (ignoring RTP/RTCP mux for the moment)?


       v=3D0
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=3D
       c=3DIN IP4 host.atlanta.com
       t=3D0 0
       a=3Dgroup:BUNDLE foo L1 L2 baz
       a=3Dgroup:DDP L1 L2
       m=3Daudio 10000 RTP/AVP 0 8 98
       a=3Dmid:foo
       b=3DAS:200
       a=3Drtpmap:0 PCMU/8000
       a=3Drtpmap:8 PCMA/8000
       a=3Drtpmap:98 iLBC/8000
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=3Dvideo 20000 RTP/AVP 96
       a=3Drtpmap:96 H264/90000
       a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-mo=
de=3DNI-T;
       a=3Dmid:L1
       m=3Dvideo 20002 RTP/AVP 97
       a=3Drtpmap:97 H264-SVC/90000
       a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
       mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
      3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
       a=3Dmid:L2
       a=3Ddepend:97 lay L1:96
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
       m=3Dbundle 10000 RTP/AVP 0 8 96 97 98
       a=3Dmid:baz
       b=3DAS:1200
       a=3Dfull-rtpmap:0 audio/PCMU/8000
       a=3Dfull-rtpmap:8 audio/PCMA/8000
       a=3Dfull-rtpmap:98 audio/iLBC/8000
       a=3Dfull-rtpmap:96 H264/90000
       a=3Dfull-rtpmap:97 H264-SVC/90000
       a=3Ddepend:97 lay L1:96
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host







From harald@alvestrand.no  Thu Aug  9 22:45:17 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2305111E80E5 for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 22:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.457
X-Spam-Level: 
X-Spam-Status: No, score=-109.457 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=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 Dbu3rRlBdPco for <mmusic@ietfa.amsl.com>; Thu,  9 Aug 2012 22:45:16 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A05AB11E80DF for <mmusic@ietf.org>; Thu,  9 Aug 2012 22:45:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEEF939E170; Fri, 10 Aug 2012 07:45:12 +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 neKOHGwf+l20; Fri, 10 Aug 2012 07:45:10 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:4ca5:d00a:49a2:b939] (unknown [IPv6:2001:470:de0a:27:4ca5:d00a:49a2:b939]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B4B2F39E130; Fri, 10 Aug 2012 07:45:10 +0200 (CEST)
Message-ID: <50249FFB.7000905@alvestrand.no>
Date: Fri, 10 Aug 2012 07:45:31 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>, <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
In-Reply-To: <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
Content-Type: multipart/alternative; boundary="------------050200010904000701070106"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 05:45:17 -0000

This is a multi-part message in MIME format.
--------------050200010904000701070106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/09/2012 06:57 PM, Bernard Aboba wrote:
>
> Harald said:
> > Bernard, since I'm so easily confused by how people transmit layers of
> > layered codecs, can you illustrate the particular scheme you want to
> > use, and can't think of how to represent in Jonathan's scheme?
>
> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in 
> SDP". An
> example of how this would be used with H.264/SVC is included in RFC 
> 6190, Section 7.3.4:
>
>        a=group:DDP L1 L2
>        m=video 20000 RTP/AVP 96
>        a=rtpmap:96 H264/90000
>        a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>        a=mid:L1
>        m=video 20002 RTP/AVP 97
>        a=rtpmap:97 H264-SVC/90000
>        a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>        a=mid:L2
>        a=depend:97 lay L1:96
>
> Here the a=depend line is expressing the decoding dependency (layered 
> in this case).

Interesting..... I do not see a way in that syntax to express a 
relationship between multiple video tracks in the same session. Is this 
expected to be done by matching SSRC across the sessions?


> Let us assume that there is also audio, as in Jonathan's example:
>
>         m=audio 10000 RTP/AVP 0 8 97
>         a=mid:foo
>         b=AS:200
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         a=rtpmap:97 iLBC/8000
>
> Does the entire SDP offer with BUNDLE and dependency grouping look 
> like this (ignoring RTP/RTCP mux for the moment)?
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>         t=0 0
>         a=group:BUNDLE foo L1 L2 baz
>         a=group:DDP L1 L2
>         m=audio 10000 RTP/AVP 0 8 98
>         a=mid:foo
>         b=AS:200
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         a=rtpmap:98 iLBC/8000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>         m=video 20000 RTP/AVP 96
>         a=rtpmap:96 H264/90000
>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>         a=mid:L1
>         m=video 20002 RTP/AVP 97
>         a=rtpmap:97 H264-SVC/90000
>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>         a=mid:L2
>         a=depend:97 lay L1:96
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>         m=bundle 10000 RTP/AVP 0 8 96 97 98
>         a=mid:baz
>         b=AS:1200
>         a=full-rtpmap:0 audio/PCMU/8000
>         a=full-rtpmap:8 audio/PCMA/8000
>         a=full-rtpmap:98 audio/iLBC/8000
>         a=full-rtpmap:96 H264/90000
>         a=full-rtpmap:97 H264-SVC/90000
>         a=depend:97 lay L1:96
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>
I think you can't BUNDLE L1 and L2 together, since the whole point of 
having L1 and L2 is transport separation, and if SSRC matching is used 
to figure out which video stream in L2 is an enhancement layer for which 
video stream in L1, mapping them into the same RTP stream would be 
physically impossible.

So if one BUNDLEs audio and L1 video, the SDP should look like this:
>   
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>         t=0 0
>         a=group:BUNDLE foo L1 baz
>         a=group:DDP L1 L2
>         m=audio 10000 RTP/AVP 0 8 98
>         a=mid:foo
>         b=AS:200
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         a=rtpmap:98 iLBC/8000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>         m=video 20000 RTP/AVP 96
>         a=rtpmap:96 H264/90000
>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>         a=mid:L1
>         m=video 20002 RTP/AVP 97
>         a=rtpmap:97 H264-SVC/90000
>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>         a=mid:L2
>         a=depend:97 lay L1:96
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>         m=bundle 10000 RTP/AVP 0 8 96 97 98
>         a=mid:baz
>         b=AS:1200
>         a=full-rtpmap:0 audio/PCMU/8000
>         a=full-rtpmap:8 audio/PCMA/8000
>         a=full-rtpmap:98 audio/iLBC/8000
>         a=full-rtpmap:96 H264/90000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host

That is - "you can't get there from here, so you shouldn't try".

(I think there's a possibility of carrying all these in a single session 
using MSID to represent the relationships, but that's not something I 
want to chew on for the moment.)

             Harald

--------------050200010904000701070106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/09/2012 06:57 PM, Bernard Aboba
      wrote:<br>
    </div>
    <blockquote cite="mid:BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl"
      type="cite">
      <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
      <div dir="ltr"><br>
        Harald said: <br>
        <div>&gt; Bernard, since I'm so easily confused by how people
          transmit layers of <br>
          &gt; layered codecs, can you illustrate the particular scheme
          you want to <br>
          &gt; use, and can't think of how to represent in Jonathan's
          scheme?<br>
          <br>
          [BA]&nbsp; I am looking at RFC 5583 "Signaling Media Decoding
          Dependency in SDP". An<br>
          example of how this would be used with H.264/SVC is included
          in RFC 6190, Section 7.3.4:<br>
          <br>
          <pre>      a=group:DDP L1 L2
      m=video 20000 RTP/AVP 96
      a=rtpmap:96 H264/90000
      a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
      a=mid:L1
      m=video 20002 RTP/AVP 97
      a=rtpmap:97 H264-SVC/90000
      a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
       mst-mode=NI-TC; sprop-operation-point-info=&lt;2,0,1,0,53000c,
      3200,352,288,384,512&gt;,&lt;3,1,2,0,53001F,6400,704,576,768,1024&gt;;
      a=mid:L2
      a=depend:97 lay L1:96</pre>
          <br>
          Here the a=depend line is expressing the decoding dependency
          (layered in this case). <br>
        </div>
      </div>
    </blockquote>
    <br>
    Interesting..... I do not see a way in that syntax to express a
    relationship between multiple video tracks in the same session. Is
    this expected to be done by matching SSRC across the sessions?<br>
    <br>
    <br>
    <blockquote cite="mid:BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl"
      type="cite">
      <div dir="ltr">
        <div>Let us assume that there is also audio, as in Jonathan's
          example:<br>
          <br>
          <pre>       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000</pre>
          <br>
          Does the entire SDP offer with BUNDLE and dependency grouping&nbsp;
          look like this (ignoring RTP/RTCP mux for the moment)? <br>
          <br>
          <pre>       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo L1 L2 baz
       a=group:DDP L1 L2
      &nbsp;m=audio 10000 RTP/AVP 0 8 98
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:98 iLBC/8000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 20000 RTP/AVP 96
       a=rtpmap:96 H264/90000
       a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
       a=mid:L1
       m=video 20002 RTP/AVP 97
       a=rtpmap:97 H264-SVC/90000
       a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
       mst-mode=NI-TC; sprop-operation-point-info=&lt;2,0,1,0,53000c,
      3200,352,288,384,512&gt;,&lt;3,1,2,0,53001F,6400,704,576,768,1024&gt;;
       a=mid:L2
       a=depend:97 lay L1:96
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
       m=bundle 10000 RTP/AVP 0 8 96 97 98
       a=mid:baz
       b=AS:1200
       a=full-rtpmap:0 audio/PCMU/8000
       a=full-rtpmap:8 audio/PCMA/8000
       a=full-rtpmap:98 audio/iLBC/8000
       a=full-rtpmap:96 H264/90000
       a=full-rtpmap:97 H264-SVC/90000
       a=depend:97 lay L1:96
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
</pre>
          <br>
        </div>
      </div>
    </blockquote>
    I think you can't BUNDLE L1 and L2 together, since the whole point
    of having L1 and L2 is transport separation, and if SSRC matching is
    used to figure out which video stream in L2 is an enhancement layer
    for which video stream in L1, mapping them into the same RTP stream
    would be physically impossible.<br>
    <br>
    So if one BUNDLEs audio and L1 video, the SDP should look like this:<br>
    <blockquote cite="mid:BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl"
      type="cite">
      <div dir="ltr">
        <div>
          <pre> 
       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo L1 baz
       a=group:DDP L1 L2
       m=audio 10000 RTP/AVP 0 8 98
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:98 iLBC/8000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 20000 RTP/AVP 96
       a=rtpmap:96 H264/90000
       a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
       a=mid:L1
       m=video 20002 RTP/AVP 97
       a=rtpmap:97 H264-SVC/90000
       a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
       mst-mode=NI-TC; sprop-operation-point-info=&lt;2,0,1,0,53000c,
      3200,352,288,384,512&gt;,&lt;3,1,2,0,53001F,6400,704,576,768,1024&gt;;
       a=mid:L2
       a=depend:97 lay L1:96
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
       m=bundle 10000 RTP/AVP 0 8 96 97 98
       a=mid:baz
       b=AS:1200
       a=full-rtpmap:0 audio/PCMU/8000
       a=full-rtpmap:8 audio/PCMA/8000
       a=full-rtpmap:98 audio/iLBC/8000
       a=full-rtpmap:96 H264/90000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
</pre>
        </div>
      </div>
    </blockquote>
    <br>
    That is - "you can't get there from here, so you shouldn't try".<br>
    <br>
    (I think there's a possibility of carrying all these in a single
    session using MSID to represent the relationships, but that's not
    something I want to chew on for the moment.)<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Harald<br>
  </body>
</html>

--------------050200010904000701070106--

From eckelcu@cisco.com  Fri Aug 10 09:27:19 2012
Return-Path: <eckelcu@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4398921F8568 for <mmusic@ietfa.amsl.com>; Fri, 10 Aug 2012 09:27:19 -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 1kM++RGiXUlA for <mmusic@ietfa.amsl.com>; Fri, 10 Aug 2012 09:27:18 -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 829CD21F8539 for <mmusic@ietf.org>; Fri, 10 Aug 2012 09:27:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1946; q=dns/txt; s=iport; t=1344616038; x=1345825638; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EMocckQqmZN44hXil/T9rx22E6JzCVoeSCEuJ1twgOE=; b=QTYLtJMlqUGBY5P/EnflwjZmYyqVI4ATy+I8Mf0C9doM6obpjDHUfipE QH7SKaKamTLOq8S9I6ufMa0smgWyGYAGKk2DYrNdUVnTKqWAikbS1ZLRG +nt80Pqm7ED8ifaim5Ccv4m1q/i4KDTVjrl9p3lNGxsYpfB0SzAtP6bEQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIzgI1CtJV2a/2dsb2JhbABFuWKBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgBAQQBEggah2sLmnugaQSLD4YEYAOjcoFmgl+BXw
X-IronPort-AV: E=Sophos;i="4.77,745,1336348800"; d="scan'208";a="110404133"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 10 Aug 2012 16:27:17 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7AGRHFY008706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 16:27:17 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.66]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 11:27:17 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Brett Tate <brett@broadsoft.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: Ac1z5irXaxvG+6IYTyi3BKqjoBMk/ADLpbgQ
Date: Fri, 10 Aug 2012 16:27:16 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C0882807C871@xmb-aln-x08.cisco.com>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local>
In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.114.222]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003
x-tm-as-result: No--47.586000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 16:27:19 -0000

Yes, I agree that is the intent of the existing wording. Adding an example =
for the specific example you provided would help make this even more clear.

Cheers,
Charles

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Brett Tate
> Sent: Monday, August 06, 2012 8:14 AM
> To: mmusic@ietf.org
> Subject: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attribut=
es
>=20
> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the following.
>=20
> "In general, session-level values are the default for all media
>  unless overridden by an equivalent media-level value."
>=20
> "The connection ("c=3D") and attribute ("a=3D") information in the
>  session-level section applies to all the media of that session unless
>  overridden by connection information or an attribute of the same name
>  in the media description.  For instance, in the example below, each
>  media behaves as if it were given a "recvonly" attribute."
>=20
> If the attributes are related but with different names (such as "inactive=
" and
> "sendrecv"), does the attribute at the media-level have precedence over
> the value at the session-level?  If so, I recommend that the draft be upd=
ated
> to clarify the topic.
>=20
> Thanks,
> Brett
>=20
>=20
> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information.  If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, or=
 by
> sending an email to helpdesk@broadsoft.com, and destroy all copies of thi=
s
> message, along with any attachment, prior to reading, distributing or
> copying it.
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From lishitao@huawei.com  Mon Aug 13 00:42:43 2012
Return-Path: <lishitao@huawei.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C383521F86A8 for <mmusic@ietfa.amsl.com>; Mon, 13 Aug 2012 00:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=3.301,  BAYES_00=-2.599, J_CHICKENPOX_14=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 1RH7e9+JJEMt for <mmusic@ietfa.amsl.com>; Mon, 13 Aug 2012 00:42:43 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 24C6021F86AA for <mmusic@ietf.org>; Mon, 13 Aug 2012 00:42:43 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJE12171; Sun, 12 Aug 2012 23:42:42 -0800 (PST)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 00:40:25 -0700
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 00:40:26 -0700
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 15:40:20 +0800
From: Lishitao <lishitao@huawei.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Simultanous usage of a=rtcp and a=rtcp-mux
Thread-Index: AQHNcQNY0hgh5d0YIEer0pxA+0dG7pdXaa+Q
Date: Mon, 13 Aug 2012 07:40:20 +0000
Message-ID: <DA165A8A2929C6429CAB403A76B573A51467CCBE@szxeml534-mbx.china.huawei.com>
References: <7F2072F1E0DE894DA4B517B93C6A058534086835E5@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534086835E5@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.73.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [MMUSIC] Simultanous usage of a=rtcp and a=rtcp-mux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2012 07:42:43 -0000

Hi Christer
I find some words in RFC 5245, section 5.7.1, this may answer your question=
.

   In the case of RTP, this would happen when one agent provides
   candidates for RTCP, and the other does not.  As another example, the
   offerer can multiplex RTP and RTCP on the same port and signals that
   it can do that in the SDP through an SDP attribute [RFC5761].

   However, since the offerer doesn't know if the answerer can perform
   such multiplexing, the offerer includes candidates for RTP and RTCP
   on separate ports, so that the offer has two components per media
   stream.  If the answerer can perform such multiplexing, it would
   include just a single component for each candidate - for the combined
   RTP/RTCP mux.  ICE would end up acting as if there was just a single
   component for this candidate.

To me, this indicates that if the receiver supports rtcp-mux, it should use=
 the same port for RTP and RTCP.

Regards
shitao

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> Sent: Friday, August 03, 2012 7:32 AM
> To: mmusic@ietf.org
> Subject: [MMUSIC] Simultanous usage of a=3Drtcp and a=3Drtcp-mux
>=20
> Hi,
>=20
> One of the issues which was raised during the MMUSIC BUNDLE presentation,
> but which is not BUNDLE specfic, was the case when an offer contains both
> a=3Drtcp and a=3Drtcp-mux.
>=20
> A case where this can happen is ICE, which requires the inclusion of the =
a=3Drtcp
> attribute.
>=20
>       "If the agent is utilizing RTCP, it MUST encode the RTCP candidate =
using
> the a=3Drtcp attribute as defined in RFC 3605 [RFC3605]." (RFC 5245/Secti=
on 4.3)
>=20
> Example:
>=20
> m=3Daudio 20000
> a=3Drtcp: 25000
> a=3Drtcp-mux
>=20
>=20
> Q: If the receiver supports both attributes, to which port would it send =
RTCP?
>=20
> As indicated during the meeting, in theory this could be solved by using =
a=3Drtcp:
> 20000 (ie same port as RTP), but people indicated that it is not allowed
> (eventhough not explicitly forbidden, afaik).
>=20
> As also indicated, another way to solve this could be by saying: "If the =
receiver
> supports a=3Drtcp-mux, use that, otherwise use a=3Drtcp". But, I have not=
 found
> any text which would support such intepretion.
>=20
> Opinions?
>=20
> Regards,
>=20
> Christer
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From christer.holmberg@ericsson.com  Tue Aug 14 12:17:13 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9780B21F863F for <mmusic@ietfa.amsl.com>; Tue, 14 Aug 2012 12:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.552
X-Spam-Level: 
X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 y+Ow93LH47cB for <mmusic@ietfa.amsl.com>; Tue, 14 Aug 2012 12:17:13 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D320021F8615 for <mmusic@ietf.org>; Tue, 14 Aug 2012 12:17:08 -0700 (PDT)
X-AuditID: c1b4fb25-b7f236d000005cde-62-502aa433a8cb
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C1.72.23774.334AA205; Tue, 14 Aug 2012 21:17:08 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 14 Aug 2012 21:17:08 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Lishitao <lishitao@huawei.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Date: Tue, 14 Aug 2012 21:15:05 +0200
Thread-Topic: Simultanous usage of a=rtcp and a=rtcp-mux
Thread-Index: AQHNcQNY0hgh5d0YIEer0pxA+0dG7pdXaa+QgAJWg+4=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340868365B@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A058534086835E5@ESESSCMS0356.eemea.ericsson.se>, <DA165A8A2929C6429CAB403A76B573A51467CCBE@szxeml534-mbx.china.huawei.com>
In-Reply-To: <DA165A8A2929C6429CAB403A76B573A51467CCBE@szxeml534-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7JEq0Ag6/uFgf33WK2mLr8MYsD k0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgynh77D97wSbJij/HHrI2MK4U6WLk5JAQMJF4 s+k8K4QtJnHh3nq2LkYuDiGBU4wSmz53s4AkhAQWMEp8mu7TxcjBwSZgIdH9TxskLCLgLjF5 +042EJtFQFXiZVMX2BxhAXOJSa962CFqLCSOtV1jhbCtJC41NIDZvALhEu9vnmCFGL+QUaLn pTOIzSkQJrHj+CFGEJsR6J7vp9YwgdjMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YIepFJe60 r2eEqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRuHcxMyc 9HIjvdSizOTi4vw8veLUTYzA+Di45bfqDsY750QOMUpzsCiJ81pv3eMvJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgbHSmm+O2JaF/y93x/3Mt3F4Uth3rS6j8vve4vhpy8+tvGt77Vi5rsmR iEURe7b9+9tRWyK4XnlnTu1/PneJX1dSO7+e93ba4pl66zfP1snPX7HVTHR9XbooeG7KTQHJ DqHlxw5PNGOc6Lb+Urzs0tu3C+043z/9cKNRtd0pOWrTlnnHxTKmLolWYinOSDTUYi4qTgQA +i11Ll0CAAA=
Subject: Re: [MMUSIC] Simultanous usage of a=rtcp and a=rtcp-mux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2012 19:17:13 -0000

Hi Shitao,

I agree with your understanding.

Of course, the answerer might not support ICE, but a=3Dssrc and a=3Drtcp-mu=
x, and in that case it will have to choose one. But, as the offerer has to =
be prepared for both alternatives, I guess that should not be a problem.

Regards,

Christer

________________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Lishit=
ao [lishitao@huawei.com]
Sent: Monday, August 13, 2012 10:40 AM
To: Christer Holmberg; mmusic@ietf.org
Subject: Re: [MMUSIC] Simultanous usage of a=3Drtcp and a=3Drtcp-mux

Hi Christer
I find some words in RFC 5245, section 5.7.1, this may answer your question=
.

   In the case of RTP, this would happen when one agent provides
   candidates for RTCP, and the other does not.  As another example, the
   offerer can multiplex RTP and RTCP on the same port and signals that
   it can do that in the SDP through an SDP attribute [RFC5761].

   However, since the offerer doesn't know if the answerer can perform
   such multiplexing, the offerer includes candidates for RTP and RTCP
   on separate ports, so that the offer has two components per media
   stream.  If the answerer can perform such multiplexing, it would
   include just a single component for each candidate - for the combined
   RTP/RTCP mux.  ICE would end up acting as if there was just a single
   component for this candidate.

To me, this indicates that if the receiver supports rtcp-mux, it should use=
 the same port for RTP and RTCP.

Regards
shitao

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> Sent: Friday, August 03, 2012 7:32 AM
> To: mmusic@ietf.org
> Subject: [MMUSIC] Simultanous usage of a=3Drtcp and a=3Drtcp-mux
>
> Hi,
>
> One of the issues which was raised during the MMUSIC BUNDLE presentation,
> but which is not BUNDLE specfic, was the case when an offer contains both
> a=3Drtcp and a=3Drtcp-mux.
>
> A case where this can happen is ICE, which requires the inclusion of the =
a=3Drtcp
> attribute.
>
>       "If the agent is utilizing RTCP, it MUST encode the RTCP candidate =
using
> the a=3Drtcp attribute as defined in RFC 3605 [RFC3605]." (RFC 5245/Secti=
on 4.3)
>
> Example:
>
> m=3Daudio 20000
> a=3Drtcp: 25000
> a=3Drtcp-mux
>
>
> Q: If the receiver supports both attributes, to which port would it send =
RTCP?
>
> As indicated during the meeting, in theory this could be solved by using =
a=3Drtcp:
> 20000 (ie same port as RTP), but people indicated that it is not allowed
> (eventhough not explicitly forbidden, afaik).
>
> As also indicated, another way to solve this could be by saying: "If the =
receiver
> supports a=3Drtcp-mux, use that, otherwise use a=3Drtcp". But, I have not=
 found
> any text which would support such intepretion.
>
> Opinions?
>
> 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 tireddy@cisco.com  Thu Aug 16 04:43:06 2012
Return-Path: <tireddy@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6700A21F85FF for <mmusic@ietfa.amsl.com>; Thu, 16 Aug 2012 04:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.457
X-Spam-Level: 
X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_73=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHg6ki4hQCMc for <mmusic@ietfa.amsl.com>; Thu, 16 Aug 2012 04:43:05 -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 22CC021F85F3 for <mmusic@ietf.org>; Thu, 16 Aug 2012 04:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=6984; q=dns/txt; s=iport; t=1345117385; x=1346326985; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CfDuTMu01xvrxxevw21uiJ12En5MQVy41VcjE+uPkQ0=; b=UU0Ec+nKNs45pYz2vql8aQ2qqeT4pDP0q/86EuUNzJ0WIgpsm8ev5X1b gV5x725K8dCezFfkGFmG4tfgCvdix0Hz2fAzucw/OBe/elaAgvac/0wEX 9SSDbNKC4vdd1pj7foGNuBgRCmqArPCfPv3g2R/D6FB4ocT1WmApPvfC+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAHjcLFCtJXG8/2dsb2JhbABFhgGzOmeBB4IgAQEBAwEBAQEPASE6CwUHBAIBBgIRBAEBBQYdBQICJQsUCQgBAQQBDQUIGodlBguaM40TCJMCgR2JbAqFNzZgA5ZjjRiBZoJfgVYHHA
X-IronPort-AV: E=Sophos;i="4.77,778,1336348800"; d="scan'208";a="112198137"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2012 11:43:04 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GBh40U005436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 11:43:04 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 06:43:04 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Lishitao <lishitao@huawei.com>, "Dan Wing (dwing)" <dwing@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] ICE Mobility
Thread-Index: Ac1p+zUFva24pK9+Re6kqju1dkzYXAAFXwSABFGpEcA=
Date: Thu, 16 Aug 2012 11:43:02 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1478821F@xmb-rcd-x10.cisco.com>
References: <048b01cd69fb$35469ba0$9fd3d2e0$@com> <DA165A8A2929C6429CAB403A76B573A514679790@szxeml534-mbx.china.huawei.com>
In-Reply-To: <DA165A8A2929C6429CAB403A76B573A514679790@szxeml534-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.39.28.153]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000
x-tm-as-result: No--47.486100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "Prashanth Patil \(praspati\)" <praspati@cisco.com>
Subject: Re: [MMUSIC] ICE Mobility
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 11:43:06 -0000

VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUgaW5saW5lLg0KDQotLVRpcnUuDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGlzaGl0YW8gW21haWx0bzps
aXNoaXRhb0BodWF3ZWkuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjUsIDIwMTIgOTox
MyBBTQ0KPiBUbzogRGFuIFdpbmcgKGR3aW5nKTsgbW11c2ljQGlldGYub3JnDQo+IENjOiBQcmFz
aGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiBT
dWJqZWN0OiC08Li0OiBbTU1VU0lDXSBJQ0UgTW9iaWxpdHkNCj4gDQo+IEhpIERhbg0KPiANCj4g
SSByZWFkIHRoaXMgZHJhZnQsIGFuZCBJIHRoaW5rIHRoZSBpZGVhIG9mIHRoaXMgZHJhZnQgaXMg
dXNlZnVsLg0KPiBSZWdhcmRpbmcgdGhlIHR3byBtZXRob2RzIG1lbnRpb25lZCBpbiB0aGUgZHJh
ZnQsIEkgdGhpbmsgdGhlIFRVUk4gb25lDQo+IGlzIGJldHRlciB0aGFuIHRoZSBJQ0Ugb25lLA0K
PiANCj4gZXNwZWNpYWxseSBpZiB0aGUgVFVSTiBzZXJ2ZXIgaGFzIHRoZSBjYWNoZSBjYXBhYmls
aXR5LCB0aGUgZGF0YSBsb3NlDQo+IHdpbGwgYmUgcXVpdGUgc21hbGwuDQo+IA0KPiBGb3IgdGhl
IG1vYmlsaXR5IHVzaW5nIElDRSBJIGdvdCBzb21lIGNvbW1lbnRzLA0KPiAxKSwgaW4gc2VjdGlv
biAzLjEsIEkgYmVsaWV2ZSB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBoZXJlIGlzIGFsbCBhYm91
dA0KPiB0aGUgZW5kcG9pbnQgd2hvIG1lZXQgdGhlIG1vYmlsaXR5IHNpdHVhdGlvbiwgc28gaW4g
c3RlcCA2LCB0aGUgSUNFDQo+IGNvbm5lY3Rpdml0eSBjaGVjayBpcyBvbmx5IGRvbmUgYnkgdGhp
cyBzaWRlLCBkbyB5b3UgbmVlZCB0byB3YWl0IHRoZQ0KPiBJQ0UgY29ubmVjdGl2aXR5IGNoZWNr
IGZpbmlzaGVkIGJ5IGFub3RoZXIgc2lkZSAocHJvYmFibHkgdGhlIHByb2NlZHVyZQ0KPiBpbiBz
ZWN0aW9uIDMuMiApIGJlZm9yZSB5b3Ugbm9taW5hdGUgdGhlIGNoZWNrIHJlc3VsdD8NCg0KVGhl
cmUgaXMgbm8gbmVlZCB0byB3YWl0LiBUaGUgbmV3IHBhaXIgaXMgbm9taW5hdGVkIGZvciBtZWRp
YSBhZnRlciBzdWNjZXNzZnVsIFNUVU4gYmluZGluZyByZXNwb25zZS4NCg0KPiANCj4gMiksIGlu
IHNlY3Rpb24gMy4yLCBpdCBzYWlkIHRoYXQgIkEgU1RVTiBCaW5kaW5nIFJlcXVlc3QgY29udGFp
bmluZyB0aGUNCj4gTU9CSUxJVFktRVZFTlQgYXR0cmlidXRlIE1BWSBiZSByZWNlaXZlZCBieSBh
biBJQ0UgZW5kcG9pbnQuICIgIHdoeSBpcw0KPiBNQVkgYmUgaGVyZT8gQW5kIHdoZW4gZG9lcyB0
aGlzIE1PQklMSVRZLUVWRU5UIGF0dHJpYnV0ZSBuZWVkID8NCg0KSWYgYW4gZW5kcG9pbnQgbW92
ZXMgdG8gYSBuZXcgaW50ZXJmYWNlIGl0IHdpbGwgaW5mb3JtIGl0J3MgcGVlciB1c2luZyBNT0JJ
TElUWS1FVkVOVCBhdHRyaWJ1dGUuIFRoZSBwZWVyIHdpbGwNCmhhdmUgdG8gbm93IGluaXRpYXRl
IElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIGFzIGRlc2NyaWJlZCBiZWxvdyA6DQoNClRoZSBJQ0Ug
YWdlbnQgY29uc3RydWN0cyBhIHBhaXIgd2hvc2UgbG9jYWwgY2FuZGlkYXRlIGlzIGVxdWFsIHRv
IHRoZSB0cmFuc3BvcnQgYWRkcmVzcyBvbiB3aGljaCB0aGUgU1RVTiByZXF1ZXN0IHdhcyByZWNl
aXZlZCB3aXRoIE1PQklMSVRZLUVWRU5UIGF0dHJpYnV0ZSwgYW5kIGEgcmVtb3RlIGNhbmRpZGF0
ZSBlcXVhbCB0byB0aGUgc291cmNlIHRyYW5zcG9ydCBhZGRyZXNzIHdoZXJlIHRoZSBTVFVOIHJl
cXVlc3QgY2FtZSBmcm9tLiBUaGUgSUNFIGFnZW50IHdpbGwgcGVyZm9ybSB0cmlnZ2VyZWQgY2hl
Y2sgdXNpbmcgdGhpcyBuZXcgcGFpciBhbmQgaWYgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayBpcyBz
dWNjZXNzZnVsLCB0aGUgcGFpciBpcyB0aGVuIGFkZCB0byB0aGUgdmFsaWQgbGlzdC4gVGhlIGFn
ZW50IHNldHMgdGhlIG5vbWluYXRlZCBmbGFnIGluIHRoZSB2YWxpZCBwYWlyIHRvIHRydWUgYW5k
IGNhbiBub3cgdXNlIHRoZSBuZXcgcGFpciBmb3Igc2VuZGluZyBtZWRpYS4NCg0Kd2Ugd2lsbCB1
cGRhdGUgdGhlIGRyYWZ0IHdpdGggdGhpcyBkZXRhaWwuDQoNCj4gDQo+IDMpICwgIHdoYXQgZG8g
eW91IG1lYW4gYnkgdGhpcyB3b3JkcyAiIElmIHRoaXMgaXMgcmVjZWl2ZWQgYmVmb3JlIHRoZQ0K
PiBlbmRwb2ludCBpcyBpbiB0aGUgSUNFIENvbmNsdWRlZCBzdGF0ZSwgaXQgc2hvdWxkIGJlIHNp
bGVudGx5DQo+IGRpc2NhcmRlZC4gIiA/DQoNCkl0IGlzIG5vdCBleHBlY3RlZCB0byBzZW5kIE1P
QklMSVRZLUVWRU5UIGJlZm9yZSB0aGUgSUNFIHN0YXRlIGlzIGNvbXBsZXRlZCBhbmQgbWVkaWEg
aXMgc2VsZWN0ZWQuIEhlbmNlIHRoZSBwZWVyIHdpbGwNCmRpc2NhcmQgTU9CSUxJVFktRVZFTlQg
YmVmb3JlIHRoZSBJQ0Ugc3RhdGUgaXMgY29tcGxldGUuDQoNCkl0IHNob3VsZCBzYXkgIklmIE1P
QklMSVRZLUVWRU5UIGF0dHJpYnV0ZSBhcnJpdmVzIGJlZm9yZSB0aGUgSUNFIHN0YXRlIGlzIENv
bXBsZXRlZC4iICh3aWxsIGZpeCB0aGUgbGluZSkNCg0KPiANCj4gNCksIHNlY3Rpb24gMy4zLCBs
b3NpbmcgYW4gaW50ZXJmYWNlLCBpdCByZWNvbW1lbmRzIHRoYXQgbm90IHRvIHNlbmQNCj4gdGhl
IFNEUCB0byByZW1vdmUgdGhlIGxvc3QgaW50ZXJmYWNlLCBpbnN0ZWFkIGl0IGlzIGJldHRlciB0
byBtYWludGFpbg0KPiBpdCBhY3RpdmUuIEZvciBteSB1bmRlcnN0YW5kaW5nLCB3aGVuIHRoZSBt
b2JpbGUgZGV2aWNlIHN3aXRjaCBmcm9tIG9uZQ0KPiBpbnRlcmZhY2UgdG8gYW5vdGhlcihmb3Ig
ZXhhbXBsZSwgd2lmaSB0byAzRyksIHRoZSBnYXRld2F5IGFuZCBOQVQNCj4gYmVmb3JlIHRoZSBk
ZXZpY2Ugd2lsbCBjaGFuZ2UgdG9vLCBob3cgY2FuIGl0IG1haW50YWluIHRoZSBwcmV2aW91cw0K
PiBpbnRlcmZhY2UgYWN0aXZlID8NCg0KVGhlIGludGVyZmFjZSBsb3NzIG1pZ2h0IGJlIHRlbXBv
cmFyeSAoYW5kIHNvb24gcmVnYWluZWQpLCBoZW5jZSBpdCBjb3VsZCBiZSB2YWx1YWJsZSB0byBy
ZXRhaW4gdGhlIGxvc3QgaW50ZXJmYWNlIGluIFNEUC4gDQoNCj4gVGhlIG9ubHkgd2F5LCBJIGNh
biBjb25zaWRlciBpcyB0aGF0IHRoZSBwcmV2aW91cw0KPiBpbnRlcmZhY2UgaXMgbm90IHRvdGFs
bHkgbG9zdCwgaXQgc3RpbGwgYWN0aXZlIG9uIHRoZSBkZXZpY2UsIHRoYXQNCj4gbWVhbnMgdGhl
IHR3byBpbnRlcmZhY2VzIGFsbCBleGlzdCBhdCB0aGUgc2FtZSB0aW1lLCBidXQgdGhlIGRldmlj
ZSBjYW4NCj4gY2hvb3NlIHRvIHVzZSB0aGUgbmV3IG9uZSBiZWNhdXNlIGl0cyBzaWduYWwgaXMg
YmV0dGVyIHRoYW4gdGhlDQo+IHByZXZpb3VzIG9uZS4NCg0KWWVzLCBJZiB0aGUgTW9iaWxlIGRl
dmljZSBoYXMgbW9yZSB0aGFuIG9uZSBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBhY3RpdmUgKGxl
dCdzIHNheSAzRywgV0lGSSkgdGhlbiBjaGFuZ2UgY291bGQgYmUgYmFzZWQgb24gcGVyIGJpdCBj
b3N0IGFuZCBjb25uZWN0aW9uIHNwZWVkLiANCg0KLS1UaXJ1Lg0KDQo+IA0KPiBSZWdhcmRzDQo+
IFNoaXRhbw0KPiANCj4gDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IG1tdXNpYy1i
b3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4g
RGFuIFdpbmcNCj4gt6LLzcqxvOQ6IDIwMTLE6jfUwjI1yNUgODoyMA0KPiDK1bz+yMs6IG1tdXNp
Y0BpZXRmLm9yZw0KPiCzrcvNOiAnUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSknOyAnVGlydW1h
bGVzd2FyIFJlZGR5ICh0aXJlZGR5KScNCj4g1vfM4jogW01NVVNJQ10gSUNFIE1vYmlsaXR5DQo+
IA0KPiBNTVVTSUMsDQo+IA0KPiBMb3Npbmcgb3IgYWNxdWlyaW5nIGFuIGludGVyZmFjZSBvZnRl
biBoYXBwZW5zIHdpdGggbW9iaWxlIGRldmljZXMsDQo+IHN1Y2ggYXMNCj4gd2hlbiBhIGRldmlj
ZSBnZXRzIHdpdGhpbiBXaUZpIHJhbmdlIG9yIGxlYXZlcyAzRyByYW5nZS4gIFRvZGF5IHRoZQ0K
PiBpbmR1c3RyeQ0KPiBnZW5lcmFsbHkgcmVsaWVzIG9uIHRlY2huaXF1ZXMgYmVsb3cgbGF5ZXIg
MyB0byBoaWRlIHRoZSBJUCBhZGRyZXNzDQo+IGNoYW5nZQ0KPiBmcm9tIHRoZSByZW1vdGUgZW5k
cG9pbnQgKGUuZy4sIExJU1AsIE1vYmlsZSBJUCkuICBUaGVzZSBleGlzdGluZw0KPiB0ZWNobmlx
dWVzDQo+IGhhdmUgc29tZSBkcmF3YmFja3MsIHN1Y2ggYXMgcmVxdWlyaW5nIHN1cHBvcnQgaW4g
dGhlIG5ldHdvcmsNCj4gaW5mcmFzdHJ1Y3R1cmUuDQo+IA0KPiBJQ0UgTW9iaWxpdHkgZXhwbG9y
ZXMgaG93IHRvIGFjY29tcGxpc2ggYSBzaW1pbGFyIGZ1bmN0aW9uIGZvciBJQ0UtDQo+IGluaXRp
YXRlZA0KPiBmbG93cyB3aXRob3V0IG5lZWRpbmcgc3VwcG9ydCBpbiB0aGUgZW5kcG9pbnQgb3Ig
aW4gdGhlIG5ldHdvcmsuDQo+IEluc3RlYWQsDQo+IHRoZSBtb2JpbGl0eSBzdXBwb3J0IGlzIHBy
b3ZpZGVkIGF0IHRoZSBJQ0UgbGF5ZXIgKHN1Y2ggYXMgUlRQLCBTUlRQLA0KPiBvcg0KPiBSVENX
RUIncyBkYXRhIGNoYW5uZWwgKFNSVFAgb3ZlciBVRFApKS4gIFRoZSBkb2N1bWVudCBkaXNjdXNz
ZXMgaG93IHR3bw0KPiBhcHByb2FjaGVzOiAgKGEpIHdoZW4gYm90aCBlbmRwb2ludHMgc3VwcG9y
dCBJQ0UgTW9iaWxpdHksIGFuZCAoYikgd2hlbg0KPiBvbmx5DQo+IG9uZSBlbmRwb2ludCBzdXBw
b3J0cyBJQ0UgTW9iaWxpdHksIHdoaWNoIHVzZXMgYSBUVVJOIHNlcnZlciAtLSBhDQo+IGRpZmZl
cmVudA0KPiBzb3J0IG9mIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUuDQo+IA0KPiBodHRwOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkNCj4gDQo+IA0K
PiBXZSBhcmUgdW5saWtlbHkgdG8gZ2V0IHRpbWUgaW4gTU1VU0lDIHRvIHByZXNlbnQgdGhpcyBk
cmFmdCwgYnV0IGFyZQ0KPiBpbnRlcmVzdGVkIGluIGZlZWRiYWNrLg0KPiANCj4gLWQNCj4gDQo+
IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBt
bXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K

From frederick.melville@iis.fraunhofer.de  Fri Aug 17 10:40:03 2012
Return-Path: <frederick.melville@iis.fraunhofer.de>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0494F11E80DF for <mmusic@ietfa.amsl.com>; Fri, 17 Aug 2012 10:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3IekBRRaQTE for <mmusic@ietfa.amsl.com>; Fri, 17 Aug 2012 10:40:01 -0700 (PDT)
Received: from mx-relay02-haj2.antispameurope.com (mx-relay02-haj2.antispameurope.com [83.246.65.202]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDE11E809B for <mmusic@ietf.org>; Fri, 17 Aug 2012 10:39:59 -0700 (PDT)
Received: from smtp02.iis.fraunhofer.de (mailserv02.iis.fraunhofer.de [153.96.171.52]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id 0D67D2400081 for <mmusic@ietf.org>; Fri, 17 Aug 2012 19:39:56 +0200 (CEST)
Received: from mbp188.iis.fhg.de (unknown [10.54.95.92]) by smtp02.iis.fraunhofer.de (Postfix) with ESMTPS id 0415094002 for <mmusic@ietf.org>; Fri, 17 Aug 2012 19:39:56 +0200 (CEST)
From: Fred Melville <frederick.melville@iis.fraunhofer.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC"
Date: Fri, 17 Aug 2012 19:39:55 +0200
Message-Id: <E31A0031-8FCD-48A5-BCB8-8AFC3BE8FE88@iis.fraunhofer.de>
To: mmusic@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-cloud-security-sender: frederick.melville@iis.fraunhofer.de
X-cloud-security-recipient: mmusic@ietf.org
X-cloud-security-Virusscan: CLEAN
X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate02-haj2 with 19C686EC009
X-cloud-security: scantime:.8523
X-Mailman-Approved-At: Fri, 17 Aug 2012 14:32:18 -0700
Subject: [MMUSIC]  Using SDP Media Capabilities for AAC Signalling
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2012 17:43:07 -0000

--Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello all,

My query is a similar to the question posed here by Jochen Issing, Nov =
30 2011, in that it relates to session setup with the negotiation of AAC =
codecs, and addressing the following two main issues encountered with =
AAC signalling using standard SDP (e.g. RFC3264 / 3640):


[ISSUE_1] What I like to call "asymmetric format parameters". For =
example, Alice offers a certain mpeg4-generic codec as follows:

  m=3Daudio 49170 RTP/AVP 96
  a=3Drtpmap:96 mpeg4-generic/48000/2
  a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; =
config=3DAAA111; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; =
constantDuration=3D1024

Bob checks that he can decode with this configuration and would like to =
accept, but Bob's encoder will be using a different AudioSpecificConfig =
of AAA222, so he would like to inform Alice of this different parameter =
in his answer (this may also apply to other format parameters such as =
profile-level-id). To do so, according to RFC3264 Section 6.1, he can =
simply keep the same PayloadTypeID (i.e. 96) and edit the fmtp =
parameters to his own preferences. The problem with doing this is that =
after returning his Answer the session should be able to begin =
immediately, but Bob has no idea if Alice actually agrees to (i.e. will =
be able to decode) the edited configuration he has made, and so Bob =
cannot safely send using this codec.

[ISSUE_2] The limited number of available dynamic Payload ID's (32 - =
could easily be exceeded with a few different codecs each with several =
configurations). If the Offerer produced a list of configurations that =
exceeded 32 then this would have to be filtered down rather crudely, =
because the Offerer cannot filter intelligently without any information =
on their partner's capabilities and therefore what the partner is likely =
to accept.


I intend to use a preliminary round of SDP Media Capabilities =
Negotiation (draft 14 at time of writing). My objective for this first =
round is to communicate all the possible configurations that each =
partner offers, along with their preferred format parameters for those =
configurations. Without mapping to PayloadTypeID's in the first round =
this will allow for lists much larger than 32 configurations.

Alice                                         Bob

| (S1) sdpMedCapNeg Offer      |
|--------------------------------------->|
|                                                       |
| (S2) sdpMedCapNeg Answer |
|<---------------------------------------|
|                                                      |
| (S3) Standard SDP Offer         |
|--------------------------------------->|
|                                                      |
| (S4) Standard SDP Answer    |
|<---------------------------------------|
|                                                      |

This is my proposed logic for the sdpMedCapNeg Answer formation at (S2) =
and I am asking that if I negotiate using the method described here am I =
doing so as the authors intended?

  (a1) When the codec configuration AND format parameters proposed by =
Alice are identical to the preferred parameters Bob would like to use, =
then the preferred config remains unchanged.

  (a2) When Alice's codec configuration and format parameters are =
accepted by Bob BUT he would like to specify his own preferred =
parameters, then using the same 'pcfg' handle he changes the parameters =
as desired. Then, when both parties store the parameters from the first =
round, Alice can chose to accept or refuse Bob's preferences in the =
final Offer (S3), by listing Bob's parameters if she accepts his =
proposal, or by repeating her own parameters if she refuses.
 =20
  (a3) When the codec configuration is accepted, but the format =
parameters cannot be accepted, then we remove the 'pcfg' and add a new =
'pcfg' handle with the codec configuration and our format parameters.
 =20
  (a4)  When the codec configuration cannot be accepted, remove the =
related 'rmcap', 'mfcap(s)' and 'pcfg(s)'.


If Bob does change the any parameters, or adds configurations to the =
Answer, he sets the Port number set to zero to indicate that the session =
will not be ready to start after this round (because he is unsure if =
Alice accepts his additions). After the first round (S1 & S2) round both =
parties will be aware of their partner's capabilities, and all 32 =
PayloadTypeID's can be used to list configurations that the offerer =
knows for certain that the answerer will accept, which should be an =
ample selection to switch between during a call. Hence ISSUE_1 would be =
fully solved since both parties have exchanged and checked their =
asymmetric parameter preferences, and ISSUE_2 is partially solved =
because the limit of 32 becomes much more palatable when the options can =
be filtered intelligently down to 32 that make sense for the given =
capabilities, and are guaranteed to be accepted by the Answerer.

My main concern is (a2), and if this is the best way for Alice to signal =
that she accepts Bob's alternative parameters? I.e. in her final offer =
S3, if Alice accepts Bob's alternative parameters, then she would signal =
this by sending his parameters in the Offer even though in reality she =
will be sending using her own parameters (assuming Bob also accepted her =
preferences in the first round). Is this safe to do so (e.g. what about =
when intermediaries / middleboxes are present?).

I can reply with a example Offers and Answers, but I thought I'd remove =
them for now as the email was becoming excessive!

Best regards,

Fred Melville
--
Multimedia Transport
Fraunhofer IIS


--Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello =
all,<div><br></div><div>My query is a similar to the question posed here =
by Jochen Issing, Nov 30 2011, in that it relates to session setup with =
the negotiation of&nbsp;AAC codecs, and addressing the following two =
main issues encountered with AAC signalling using standard SDP (e.g. =
RFC3264 / 3640):</div><div><br></div><div><br></div><div>[ISSUE_1] What =
I like to call&nbsp;"asymmetric format parameters". For example, Alice =
offers a certain mpeg4-generic codec as =
follows:</div><div><div><br></div><div>&nbsp; m=3Daudio 49170 RTP/AVP =
96</div><div>&nbsp; a=3Drtpmap:96 mpeg4-generic/48000/2</div><div>&nbsp; =
a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; =
config=3DAAA111; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; =
constantDuration=3D1024</div><div><br></div>Bob checks that he can =
decode with this configuration and would like to accept, but Bob's =
encoder will be using a different AudioSpecificConfig of AAA222, so he =
would like to inform Alice of this different parameter in his answer =
(this may also apply to other format parameters such as =
profile-level-id). To do so, according to RFC3264 Section 6.1, he can =
simply keep the same PayloadTypeID (i.e. 96) and edit the fmtp =
parameters to his own preferences. The problem with doing this is that =
after returning his Answer the session should be able to begin =
immediately, but Bob has no idea if Alice actually agrees to (i.e. will =
be able to decode) the edited configuration he has made, and so Bob =
cannot safely send using this codec.</div><div><br></div><div>[ISSUE_2] =
The limited number of available dynamic Payload ID's (32 - could easily =
be exceeded with a few different codecs each with several =
configurations). If the Offerer produced a list of configurations that =
exceeded 32 then this would have to be filtered down rather crudely, =
because the Offerer cannot filter intelligently without any information =
on their partner's capabilities and therefore what the partner is likely =
to accept.</div><div><br></div><div><br></div><div>I intend to =
use&nbsp;a preliminary round of SDP Media Capabilities Negotiation =
(draft 14 at time of writing). My objective for this first round is to =
communicate all the possible configurations that each partner offers, =
along with their preferred format parameters for those configurations. =
Without mapping to PayloadTypeID's in the first round this will allow =
for lists much larger than =
32&nbsp;configurations.</div><div><br></div><div><div>Alice &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
Bob</div><div><br></div><div>| (S1) sdpMedCapNeg Offer &nbsp; &nbsp; =
&nbsp;|</div><div>|---------------------------------------&gt;|</div><div>=
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |</div><div>| (S2) =
sdpMedCapNeg Answer =
|</div><div>|&lt;---------------------------------------|</div><div>| =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>| (S3) =
Standard SDP Offer &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div>|---------------------------------------&gt;|</div><div>| =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>| (S4) =
Standard SDP Answer &nbsp; =
&nbsp;|</div><div>|&lt;---------------------------------------|</div><div>=
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</div></div><div><br></div><div>This is my proposed logic for =
the&nbsp;sdpMedCapNeg Answer formation&nbsp;at (S2) and I am asking =
that&nbsp;if I negotiate using the method described here am I doing so =
as the authors intended?</div><div><br></div><div><div>&nbsp; (a1) When =
the codec configuration AND format parameters proposed by Alice are =
identical to the preferred parameters Bob would like to use, then the =
preferred config remains unchanged.</div><div><br></div><div>&nbsp; (a2) =
When Alice's codec configuration and format parameters are accepted by =
Bob BUT he would like to specify his own preferred parameters, then =
using the same 'pcfg' handle he changes the parameters as desired. Then, =
when both parties store the parameters from the first round, Alice can =
chose to accept or refuse Bob's preferences in the final Offer (S3), by =
listing Bob's parameters if she accepts his proposal, or by repeating =
her own parameters if she =
refuses.</div><div>&nbsp;&nbsp;</div><div>&nbsp; (a3) When the codec =
configuration is accepted, but the format parameters cannot be accepted, =
then we remove the 'pcfg' and add a new 'pcfg' handle with the codec =
configuration and our format =
parameters.</div><div>&nbsp;&nbsp;</div><div>&nbsp; (a4) &nbsp;When the =
codec configuration cannot be accepted, remove the related =
'rmcap',&nbsp;'mfcap(s)' and =
'pcfg(s)'.</div></div><div><br></div><div><br></div><div>If Bob does =
change the any parameters, or adds configurations to the Answer, he sets =
the Port number set to zero to indicate that the session will not be =
ready to start after this round (because he is unsure if Alice accepts =
his additions).&nbsp;After the first round (S1 &amp; S2) round both =
parties will be aware of their partner's capabilities, and all 32 =
PayloadTypeID's can be used to list configurations that the offerer =
knows for certain that the answerer will accept, which should be an =
ample selection to switch between during a call. Hence ISSUE_1 would be =
fully solved since both parties have exchanged and checked their =
asymmetric parameter preferences, and ISSUE_2 is partially solved =
because the limit of 32 becomes much more palatable when the options can =
be filtered intelligently down to 32 that make sense for the given =
capabilities, and are guaranteed to be accepted by the =
Answerer.</div><div><br></div><div>My main concern is (a2), and if this =
is the best way for Alice to signal that she accepts Bob's alternative =
parameters? I.e. in her final offer S3, if Alice accepts Bob's =
alternative parameters, then she would signal this by sending his =
parameters in the Offer even though in reality she will be sending using =
her own parameters (assuming Bob also accepted her preferences in the =
first round). Is this safe to do so (e.g. what about when intermediaries =
/ middleboxes are present?).</div><div><br></div><div>I can reply with a =
example Offers and Answers, but I thought I'd remove them for now as the =
email was becoming excessive!</div><div><br></div><div>Best =
regards,</div><div><br></div><div>Fred Melville</div><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>--</div><div>Multimedia =
Transport</div><div><div>Fraunhofer IIS</div></div></div></span></span>
</div>
<br></body></html>=

--Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC--

From internet-drafts@ietf.org  Mon Aug 20 11:05:27 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512421F8629; Mon, 20 Aug 2012 11:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.502
X-Spam-Level: 
X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7GGD43dn3ZE; Mon, 20 Aug 2012 11:05:26 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767A121F86B4; Mon, 20 Aug 2012 11:05:26 -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.33
Message-ID: <20120820180526.6017.22894.idtracker@ietfa.amsl.com>
Date: Mon, 20 Aug 2012 11:05:26 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2012 18:05:27 -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           : Multiplexing Negotiation Using Session Description Proto=
col (SDP) Port Numbers
	Author(s)       : Christer Holmberg
                          Harald Tveit Alvestrand
	Filename        : draft-ietf-mmusic-sdp-bundle-negotiation-01.txt
	Pages           : 11
	Date            : 2012-08-20

Abstract:
   This specification defines a new SDP Grouping Framework SDP grouping
   framework extension, "BUNDLE", that can be used with the Session
   Description Protocol (SDP) Offer/Answer mechanism to negotiate the
   usage of bundled media, which refers to the usage of a single 5-tuple
   for media associated with multiple SDP media descriptions ("m=3D"
   lines).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-bundle-negotiation=
-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From paulej@packetizer.com  Wed Aug 22 15:04:41 2012
Return-Path: <paulej@packetizer.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD65321F865B for <mmusic@ietfa.amsl.com>; Wed, 22 Aug 2012 15:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyUbmfBrvko6 for <mmusic@ietfa.amsl.com>; Wed, 22 Aug 2012 15:04:41 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 01A6321F8658 for <mmusic@ietf.org>; Wed, 22 Aug 2012 15:04:40 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7MM4ccX029468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Aug 2012 18:04:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1345673079; bh=fw5e6JSx7Hpk1UCm1AVKHO5Ud45vgcpfcSW0+Wt60rY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aFhgss5lBhFMqx6yYckaA5HFbjh2xu4Kd+kSIXG+ZT19YBGojt5580s7qlnaGoWeV V4n9TYIhz9H4ny7qZwDeLjMEIhr0yqHUBz2QFTzHuUyF1rNI8lU/9N9tPB4UjHc2nB Ft7+pUTfiQIlJC+pJZGoA3cBVR5d56heEjV0k1Xw=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Paul Kyzivat'" <pkyzivat@alum.mit.edu>, <mmusic@ietf.org>
References: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> <5005DBCA.8040405@alum.mit.edu>
In-Reply-To: <5005DBCA.8040405@alum.mit.edu>
Date: Wed, 22 Aug 2012 18:04:45 -0400
Message-ID: <002f01cd80b2$24455530$6ccfff90$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIkCjpD5G0c/4AfIxmKojzRm/pGSwKLFVLylqTq1kA=
Content-Language: en-us
Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Aug 2012 22:04:41 -0000

Paul,

My apologies for the belated reply.  I hope this is still of value.

> In section 3 (SDP syntax):
> 
>     tcl-token = %2D / %30-%39 / %41-%5A / %61-7A
> 
> That only allows one character tokens. Minimally you probably want:
> 
>     tcl-token = 1*(%2D / %30-%39 / %41-%5A / %61-7A)

Ooops... agreed.  This is what was intended.
 
> But it would be more readable as:
> 
>     tcl-token = 1*( ALPHA / DIGIT / "-" )

This is OK, but we also need to include the underscore character.  So, we
need this:

     tcl-token = 1*( ALPHA / DIGIT / "-" / "_" )

For some reason, that was left out.
 
> But that allows leading and trailing, and multiple consecutive "-"s. So
> you could tighten it up with:
> 
>     tcl-token = ALPHA 0*(ALPHA / DIGIT) 0*("-" 1*(ALPHA / DIGIT))

We want to allow a leading underscore.  So, perhaps this:

  tcl-token = (ALPHA / "_") 0*(ALPHA / DIGIT) 0*(("-" / "_") 1*(ALPHA /
DIGIT))

This prevents "apple-_pie", though. Do we want to allow more than one
non-alpha-numeric to be together? I'd be content to disallow it, since the
purpose for - or _ is for readability and putting them together makes it
less readable, IMO.
 
> Also, your syntax doesn't cover non-standard-adjectives. You could cover
> that by:
> 
>     adjective = standard-adjective / non-standard-adjective
> 
>     standard-adjective = classified-adjective / unclassified-adjective
> 
>     non-standard-adjective = "_" standard-adjective

I don't think we should separate standard and non-standard adjectives via
syntax.  If we have a particular interpretation of "_foo" to mean that it is
non-standard, I think the above syntax will work.  We just need to explain
that adjectives with leading underscores are for non-standard use.
 
> Sections 6.3 & 6.4:
> 
> "Specification Required" implies expert review. That in turn calls for
> some criteria by which the expert can decide if a proposed value is
> appropriate to be registered.

What we wanted was that IETF-agreed adjectives would be supported with some
documentation (i.e., an RFC).  However, if folks prefer to allow anyone to
register an adjective for whatever purpose, we could drop the requirement.
What should be used here?

 
> IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not* Unqualified
> adjectives.  Rather,
> 
> 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified*
> adjectives.
> 	
> Does the distinction matter for registration? Should there be different
> criteria for registering new qualified adjectives? Maybe so. Maybe there
> should be some review of whether the new 'aq:foo' is compatible with the
> intended meaning of 'aq'???

"aq" by itself is not an adjective.  "aq:admitted" is an adjective.

Consider draft-jennings-rtcweb-qos-00.  In there, we mention there that a
media flow can be designated as low, medium, or high importance. Not to
cause a war of names, but let's those priority values.

So for WebRTC, we might define:
  pri:low
  pri:medium
  pri:high

So, an audio flow might be labeled:
  conversational.audio.pri:medium.aq:non-admitted

The "aq:" and "pri:" part of the adjective is something I would like to
allow developers to search for.  Perhaps one day we introduce
"pri:very-high".  A device may not know what "very-high" means, but it can
match the substring "pri:" and at least recognize the adjective as being a
priority adjective.

At least that was the intent.

What I would like to do is have a multi-level registration akin to what we
have for media types.  So, we would have something like this:

+----------------------+----------------------+----------------------+
| Category             | Application          | Adjective            |
+----------------------+----------------------+----------------------+
| conversational       | audio                | immersive            |
|                      |                      | aq:                  |
|                      |                      |    admitted          |
|                      |                      |    non-admitted      |
|                      |                      |                      |
|                      |                      | avconf               |
|                      |                      |                      |
|                      | video                | immersive            |
|                      |                      | aq:                  |
|                      |                      |    admitted          |
|                      |                      |    non-admitted      |
|                      |                      |    partial           |
|                      |                      | avconf               |
|                      |                      |                      |
|                      | text                 | realtime-text        |
+----------------------+----------------------+----------------------+
| multimedia-confer... | app-sharing          |                      |
|                      |                      |                      |
|                      | whiteboarding        |                      |
+----------------------+----------------------+----------------------+
| broadcast            | audio                |                      |
|                      |                      |                      |
|                      | video                |                      |
+----------------------+----------------------+----------------------+
...

I'm not precisely sure what the best way is to represent "aq:", but I do not
think we want to introduce another level in the hierarchy.  It's just a
prefix to a family of related adjectives.

Paul



From pkyzivat@alum.mit.edu  Wed Aug 22 16:41:19 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3621F8648 for <mmusic@ietfa.amsl.com>; Wed, 22 Aug 2012 16:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.803
X-Spam-Level: 
X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXW8UQ8Vc6-K for <mmusic@ietfa.amsl.com>; Wed, 22 Aug 2012 16:41:18 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id A33C921F8646 for <mmusic@ietf.org>; Wed, 22 Aug 2012 16:41:18 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id pzW81j00117dt5G56zhMC2; Wed, 22 Aug 2012 23:41:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id pzhl1j00X3ZTu2S3ZzhlUF; Wed, 22 Aug 2012 23:41:45 +0000
Message-ID: <50356E1D.4030908@alum.mit.edu>
Date: Wed, 22 Aug 2012 19:41:17 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Paul E. Jones" <paulej@packetizer.com>
References: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> <5005DBCA.8040405@alum.mit.edu> <002f01cd80b2$24455530$6ccfff90$@packetizer.com>
In-Reply-To: <002f01cd80b2$24455530$6ccfff90$@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Aug 2012 23:41:19 -0000

On 8/22/12 6:04 PM, Paul E. Jones wrote:
> Paul,
>
> My apologies for the belated reply.  I hope this is still of value.
>
>> In section 3 (SDP syntax):
>>
>>      tcl-token = %2D / %30-%39 / %41-%5A / %61-7A
>>
>> That only allows one character tokens. Minimally you probably want:
>>
>>      tcl-token = 1*(%2D / %30-%39 / %41-%5A / %61-7A)
>
> Ooops... agreed.  This is what was intended.
>
>> But it would be more readable as:
>>
>>      tcl-token = 1*( ALPHA / DIGIT / "-" )
>
> This is OK, but we also need to include the underscore character.  So, we
> need this:
>
>       tcl-token = 1*( ALPHA / DIGIT / "-" / "_" )
>
> For some reason, that was left out.

That answers my comment: your syntax doesn't cover non-standard-adjectives

>> But that allows leading and trailing, and multiple consecutive "-"s. So
>> you could tighten it up with:
>>
>>      tcl-token = ALPHA 0*(ALPHA / DIGIT) 0*("-" 1*(ALPHA / DIGIT))
>
> We want to allow a leading underscore.  So, perhaps this:
>    tcl-token = (ALPHA / "_") 0*(ALPHA / DIGIT) 0*(("-" / "_") 1*(ALPHA /
> DIGIT))

Well, there are two things to deal with:
- what forms are allowed
- how to represent that in ABNF

Well formed ABNF can answer both questions, as long as it isn't so 
obscure that people don't understand it.

I'm not in love with the leading "_" to signal non-standard adjectives, 
but neither do I hate it. But I'm much less fond of sequences of _ and -.

Do you want "foo:_bar" to be a valid adjective? How about "_foo:bar"?
ISTM that foo:_bar is probably a bad idea. So I'm thinking it would be 
better to define tcl_token so it doesn't permit a leading underscore. 
Then define the adjectives to allow the leading underscore where you 
want it.

So perhaps:

tcl-sep = "-" / "_"

tcl_token = ALPHA 0*(ALPHA / DIGIT) 0*((tcl-sep 1*(ALPHA / DIGIT))

std-unclassified-adj = tcl-token

std-adj-classifier = std-unclassified-adj ":"

adj-qualifier = tcl-token

std-classified_adj = std-adj-classifier adj-qualifier

standard-adjective = std-unclassified-adj / std-classified-adj

non-standard-adjective = "_" standard-adjective

I find this more readable, and it provides terms to talk about in the text.


> This prevents "apple-_pie", though. Do we want to allow more than one
> non-alpha-numeric to be together? I'd be content to disallow it, since the
> purpose for - or _ is for readability and putting them together makes it
> less readable, IMO.

AMEN!

>> Also, your syntax doesn't cover non-standard-adjectives. You could cover
>> that by:
>>
>>      adjective = standard-adjective / non-standard-adjective
>>
>>      standard-adjective = classified-adjective / unclassified-adjective
>>
>>      non-standard-adjective = "_" standard-adjective
>
> I don't think we should separate standard and non-standard adjectives via
> syntax.  If we have a particular interpretation of "_foo" to mean that it is
> non-standard, I think the above syntax will work.  We just need to explain
> that adjectives with leading underscores are for non-standard use.

Hopefully I made a case above for putting it into the syntax.

>> Sections 6.3 & 6.4:
>>
>> "Specification Required" implies expert review. That in turn calls for
>> some criteria by which the expert can decide if a proposed value is
>> appropriate to be registered.
>
> What we wanted was that IETF-agreed adjectives would be supported with some
> documentation (i.e., an RFC).  However, if folks prefer to allow anyone to
> register an adjective for whatever purpose, we could drop the requirement.
> What should be used here?

I'm not an expert at this. Look at RFC 5226 and pick the policy you want.

Regardless of which policy, the doc should specify *some* criteria for 
distinguishing an acceptable new value from an unacceptable one. If 
there is a policy that requires an expert review (like the Expert Review 
policy you currently call for) it's more important to make the criteria 
explicit.

>> IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not* Unqualified
>> adjectives.  Rather,
>>
>> 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified*
>> adjectives.
>> 	
>> Does the distinction matter for registration? Should there be different
>> criteria for registering new qualified adjectives? Maybe so. Maybe there
>> should be some review of whether the new 'aq:foo' is compatible with the
>> intended meaning of 'aq'???
>
> "aq" by itself is not an adjective.  "aq:admitted" is an adjective.

I see nothing to prevent both "aq" and "aq:admitted" from being 
registered. If you don't want to permit that, then say so.

> Consider draft-jennings-rtcweb-qos-00.  In there, we mention there that a
> media flow can be designated as low, medium, or high importance. Not to
> cause a war of names, but let's those priority values.
>
> So for WebRTC, we might define:
>    pri:low
>    pri:medium
>    pri:high
>
> So, an audio flow might be labeled:
>    conversational.audio.pri:medium.aq:non-admitted
>
> The "aq:" and "pri:" part of the adjective is something I would like to
> allow developers to search for.  Perhaps one day we introduce
> "pri:very-high".  A device may not know what "very-high" means, but it can
> match the substring "pri:" and at least recognize the adjective as being a
> priority adjective.
>
> At least that was the intent.
>
> What I would like to do is have a multi-level registration akin to what we
> have for media types.  So, we would have something like this:
>
> +----------------------+----------------------+----------------------+
> | Category             | Application          | Adjective            |
> +----------------------+----------------------+----------------------+
> | conversational       | audio                | immersive            |
> |                      |                      | aq:                  |
> |                      |                      |    admitted          |
> |                      |                      |    non-admitted      |
> |                      |                      |                      |
> |                      |                      | avconf               |
> |                      |                      |                      |
> |                      | video                | immersive            |
> |                      |                      | aq:                  |
> |                      |                      |    admitted          |
> |                      |                      |    non-admitted      |
> |                      |                      |    partial           |
> |                      |                      | avconf               |
> |                      |                      |                      |
> |                      | text                 | realtime-text        |
> +----------------------+----------------------+----------------------+
> | multimedia-confer... | app-sharing          |                      |
> |                      |                      |                      |
> |                      | whiteboarding        |                      |
> +----------------------+----------------------+----------------------+
> | broadcast            | audio                |                      |
> |                      |                      |                      |
> |                      | video                |                      |
> +----------------------+----------------------+----------------------+
> ...
>
> I'm not precisely sure what the best way is to represent "aq:", but I do not
> think we want to introduce another level in the hierarchy.  It's just a
> prefix to a family of related adjectives.

The structure of the registry can be settled later. Work out the desired 
usage first. (But to get all that into IANA will be difficult.)

My first thought is that IANA can simply register standard-adjectives 
without regard for whether they are qualified or not. The ones that are 
qualified will sort together.

But you might want a higher bar for registering a new adj-qualifier for 
an existing std-adj-classifier than you do for registering a new 
std-unclassified-adj. That will require more complex rules, and *might* 
require a different table structure.

E.g.

suppose aq:admitted and aq:non-admitted have already been registered.

Would you want it to be ok to register aq:foo for some purpose unrelated 
to the other two? I think not. What guidelines would you want to give to 
an expert to ensure that doesn't happen?

(If there are no guidelines, and someone attempts to do this, the expert 
has no grounds other than his own opinion to reject the request.)

	Thanks,
	Paul K


From dwing@cisco.com  Wed Aug 22 17:59:09 2012
Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5B21F84DC for <mmusic@ietfa.amsl.com>; Wed, 22 Aug 2012 17:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.491
X-Spam-Level: 
X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6-t77Y7uTKy for <mmusic@ietfa.amsl.com>; Wed, 22 Aug 2012 17:59:09 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8F21F84D3 for <mmusic@ietf.org>; Wed, 22 Aug 2012 17:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1532; q=dns/txt; s=iport; t=1345683549; x=1346893149; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=3oowaE0swpakne1hfv9T83AEDD6ivnuy0nk91mcdD8M=; b=bGePX5OCUZPBBK3K8b9aYFdsj2lty3OcGM+6p2KkElIEy/BoCQ6oWGGg eSDeMZFHR8TGQc8kQ8BFw15MiS2yvpoP7TrGJPPh27slQAgGLpokYR/0A vCvAZfTjqCfyOO5q4j7voLc6nFzyjwA+J5oku/PPqxAFx1m/5tW3qQ7Fr M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQKAFh/NVCrRDoJ/2dsb2JhbABFql+ObAQDf4EHgiABAQEECAoBFxA/DAEDAgkPAgQBASgHGSMKCQgBAQQBEgsTBIdqmQ2gNosIhxEDiE+FDZYjgWaDAw
X-IronPort-AV: E=Sophos;i="4.80,297,1344211200"; d="scan'208";a="55733024"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 23 Aug 2012 00:59:05 +0000
Received: from dwingWS (sjc-vpn2-607.cisco.com [10.21.114.95]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7N0x5vI009059; Thu, 23 Aug 2012 00:59:05 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Jonathan Lennox'" <jonathan@vidyo.com>, "'Ari Keranen'" <ari.keranen@nomadiclab.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca>	<5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca>	<501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca>	<501C2639.60000@nomadiclab.com>	<EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com>	<501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan>
In-Reply-To: <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan>
Date: Wed, 22 Aug 2012 17:59:05 -0700
Message-ID: <025901cd80ca$7e7442b0$7b5cc810$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac1z5QogRY98fn1HRDmwrq9QryRpKAAXA1fwAAq4i+AABZupQAMR7c6A
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2012 00:59:10 -0000

> -----Original Message-----
> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
> Sent: Tuesday, August 07, 2012 2:53 AM
> To: Dan Wing; 'Ari Keranen'
> Cc: mmusic@ietf.org
> Subject: RE: [MMUSIC] ICE candidate address selection update draft
> 
> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari
> Keranen', mmusic@ietf.org" saying:
> 
> > Mine would be to take the list of IPv6 and IPv4 addresses and try
> them
> > in the order described by ICE (which currently recommends following
> > the OS's default, which is sometimes hard to get depending on the
> OS).
> > But if the first IPv6 candidate didn't return a connectivity checks
> > quickly (let's say, 150ms), initiate a connectivity check on the
> > highest priority IPv4 address next.  In that 150ms, based on ICE's
> > pacing, many IPv6 addresses will have been tried.  150ms gives plenty
> > of time for IPv6 to 'win', before using an IPv4 resource that is
> > likely shared with IPv4-only devices.
> 
> Can't this result in the endpoints getting out of sync with the order
> of the checklist?  If one side has started IPv4 while the other hasn't,
> you won't have the outbound packets coming from one side to create the
> port bindings.

Don't we already have that problem if both peers are dual-stack, and 
one side has many more IPv6 candidates than the other side?


But, to avoid the problem you describe, seems we should try IPv6
and try IPv4 in a somewhat parallel fashion.  Echos of Happy 
Eyeballs.

-d



From jonathan@vidyo.com  Thu Aug 23 06:55:24 2012
Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5B221F858A for <mmusic@ietfa.amsl.com>; Thu, 23 Aug 2012 06:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Co9DOGiHStO for <mmusic@ietfa.amsl.com>; Thu, 23 Aug 2012 06:55:24 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id CB49C21F85FC for <mmusic@ietf.org>; Thu, 23 Aug 2012 06:55:23 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 059368BF35D; Thu, 23 Aug 2012 09:55:23 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB012.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 98CEF8BF410; Thu, 23 Aug 2012 09:55:22 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Thu, 23 Aug 2012 09:55:17 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Dan Wing <dwing@cisco.com>, 'Ari Keranen' <ari.keranen@nomadiclab.com>
Date: Thu, 23 Aug 2012 09:55:16 -0400
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: Ac1z5QogRY98fn1HRDmwrq9QryRpKAAXA1fwAAq4i+AABZupQAMR7c6AABsC1aA=
Message-ID: <C3759687E4991243A1A0BD44EAC823034DF5D6D60D@BE235.mail.lan>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <025901cd80ca$7e7442b0$7b5cc810$@com>
In-Reply-To: <025901cd80ca$7e7442b0$7b5cc810$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2012 13:55:25 -0000

Dan Wing writes:

> Don't we already have that problem if both peers are dual-stack, and one =
side has many more IPv6 candidates than the other side?

No, because the check list consists of candidate *pairs*, and under the cur=
rent ICE rules both sides see the same list of pairs, and sort them in the =
same order.

> But, to avoid the problem you describe, seems we should try IPv6
> and try IPv4 in a somewhat parallel fashion.  Echos of Happy=20
> Eyeballs.

ICE connectivity checks are inherently parallel, so some ordering like "lik=
ely v6 pairs", "v4 pairs", "unlikely v6 pairs" should accomplish this.

For the full Happy Eyeballs treatment, I suppose we could recommend that an=
 endpoint prioritize its candidates based on which ones worked previously, =
but that's an optimization and doesn't need to be standardized (so long as =
these priorities are signaled in the standard manner).

-----Original Message-----
From: Dan Wing [mailto:dwing@cisco.com]=20
Sent: Wednesday, August 22, 2012 8:59 PM
To: Jonathan Lennox; 'Ari Keranen'
Cc: mmusic@ietf.org
Subject: RE: [MMUSIC] ICE candidate address selection update draft

> -----Original Message-----
> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
> Sent: Tuesday, August 07, 2012 2:53 AM
> To: Dan Wing; 'Ari Keranen'
> Cc: mmusic@ietf.org
> Subject: RE: [MMUSIC] ICE candidate address selection update draft
>=20
> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',=20
> 'Ari Keranen', mmusic@ietf.org" saying:
>=20
> > Mine would be to take the list of IPv6 and IPv4 addresses and try
> them
> > in the order described by ICE (which currently recommends following=20
> > the OS's default, which is sometimes hard to get depending on the
> OS).
> > But if the first IPv6 candidate didn't return a connectivity checks=20
> > quickly (let's say, 150ms), initiate a connectivity check on the=20
> > highest priority IPv4 address next.  In that 150ms, based on ICE's=20
> > pacing, many IPv6 addresses will have been tried.  150ms gives=20
> > plenty of time for IPv6 to 'win', before using an IPv4 resource that=20
> > is likely shared with IPv4-only devices.
>=20
> Can't this result in the endpoints getting out of sync with the order=20
> of the checklist?  If one side has started IPv4 while the other=20
> hasn't, you won't have the outbound packets coming from one side to=20
> create the port bindings.

Don't we already have that problem if both peers are dual-stack, and one si=
de has many more IPv6 candidates than the other side?
=09

But, to avoid the problem you describe, seems we should try IPv6
and try IPv4 in a somewhat parallel fashion.  Echos of Happy=20
Eyeballs.

-d



From palmarti@cisco.com  Thu Aug 23 07:24:21 2012
Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2421F8534 for <mmusic@ietfa.amsl.com>; Thu, 23 Aug 2012 07:24:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLkHx7dwQt5c for <mmusic@ietfa.amsl.com>; Thu, 23 Aug 2012 07:24:20 -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 35BFF21F84B5 for <mmusic@ietf.org>; Thu, 23 Aug 2012 07:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=palmarti@cisco.com; l=2001; q=dns/txt; s=iport; t=1345731860; x=1346941460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5xccctQIZUnGM02Wk8KXr3azJBD5qkFoZb8MhQlYTt4=; b=KTTn40RdNOUWK3rv4+F5xtJd16SiaAxxK9c1HWnJ90j05/0EhYMKYRVB Oi+6NJ+zZ2aYvs3AnbmvLy/5MZEDCVdvH02vHqqbR2JOD20NwSlBEsmAZ 7Fg6QZT+swOheDjJi0UEU5RGQ7G4hYIhVUhc8ERrZyclnNqPwAPXL84L5 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAMo7NlCtJXHB/2dsb2JhbABFulCBB4IgAQEBAwEBAQEPAVsLDAQCAQgRBAEBKAcnCxQJCAIEDgUeBIdlBguZJqA4BIsIhjFgA4gajTqOLYFngmM
X-IronPort-AV: E=Sophos;i="4.80,300,1344211200"; d="scan'208";a="114584433"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2012 14:24:19 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7NEOJgW021210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 14:24:19 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 09:24:18 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: "Dan Wing (dwing)" <dwing@cisco.com>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAOZDYCAALjLgIAAVdMAgAAsKgCAGJAXgIAA4PmA
Date: Thu, 23 Aug 2012 14:24:17 +0000
Message-ID: <3221A85E-5F48-4508-AF5E-A68F863AAD9C@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <025901cd80ca$7e7442b0$7b5cc810$@com>
In-Reply-To: <025901cd80ca$7e7442b0$7b5cc810$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.147.112.51]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19132.005
x-tm-as-result: No--42.577200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <DAB275E9FCE6FA41927EFACABB095E3D@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox <jonathan@vidyo.com>, "<mmusic@ietf.org>" <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2012 14:24:21 -0000

On Aug 23, 2012, at 2:59 AM, Dan Wing <dwing@cisco.com> wrote:

>> -----Original Message-----
>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
>> Sent: Tuesday, August 07, 2012 2:53 AM
>> To: Dan Wing; 'Ari Keranen'
>> Cc: mmusic@ietf.org
>> Subject: RE: [MMUSIC] ICE candidate address selection update draft
>>=20
>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari
>> Keranen', mmusic@ietf.org" saying:
>>=20
>>> Mine would be to take the list of IPv6 and IPv4 addresses and try
>> them
>>> in the order described by ICE (which currently recommends following
>>> the OS's default, which is sometimes hard to get depending on the
>> OS).
>>> But if the first IPv6 candidate didn't return a connectivity checks
>>> quickly (let's say, 150ms), initiate a connectivity check on the
>>> highest priority IPv4 address next.  In that 150ms, based on ICE's
>>> pacing, many IPv6 addresses will have been tried.  150ms gives plenty
>>> of time for IPv6 to 'win', before using an IPv4 resource that is
>>> likely shared with IPv4-only devices.
>>=20
>> Can't this result in the endpoints getting out of sync with the order
>> of the checklist?  If one side has started IPv4 while the other hasn't,
>> you won't have the outbound packets coming from one side to create the
>> port bindings.
>=20
> Don't we already have that problem if both peers are dual-stack, and=20
> one side has many more IPv6 candidates than the other side?

But the checklist consist of candidate pairs. So the checklists on remote a=
nd local side should be fairly similar in size?=20

>=20
>=20
> But, to avoid the problem you describe, seems we should try IPv6
> and try IPv4 in a somewhat parallel fashion.  Echos of Happy=20
> Eyeballs.
>=20
That is a nice speed optimisation.

.-.
P=E5l-Erik


> -d
>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From paulej@packetizer.com  Thu Aug 23 13:28:54 2012
Return-Path: <paulej@packetizer.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A6221F8458 for <mmusic@ietfa.amsl.com>; Thu, 23 Aug 2012 13:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_28=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2L-+mUYx6b3 for <mmusic@ietfa.amsl.com>; Thu, 23 Aug 2012 13:28:53 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFAD21F8450 for <mmusic@ietf.org>; Thu, 23 Aug 2012 13:28:53 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7NKSpBp024953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Aug 2012 16:28:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1345753732; bh=jxhCM/l33IKBU2PnQkJAfJunPWW8dv0r81w0BerShVk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZbSDY0bC7GHUVarapfKIquJ9OxMiv6m3e1XI1HizpWW/Xe2nVjWGz2LmjjJXuoCHx 5tl4SrEYAUAdKQ+OTuhdq3RJLHVyShhegamykawnyXKvBhox1xpGMw6b0J3WFxpauy 0B24b+ivB/Gef1B6YGQQaL4FBkgcpjE91pClinx8=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Paul Kyzivat'" <pkyzivat@alum.mit.edu>
References: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> <5005DBCA.8040405@alum.mit.edu> <002f01cd80b2$24455530$6ccfff90$@packetizer.com> <50356E1D.4030908@alum.mit.edu>
In-Reply-To: <50356E1D.4030908@alum.mit.edu>
Date: Thu, 23 Aug 2012 16:29:00 -0400
Message-ID: <016001cd816d$ee4e0000$caea0000$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIkCjpD5G0c/4AfIxmKojzRm/pGSwKLFVLyAZ6pDFwCFSCbGJaIyWCg
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2012 20:28:54 -0000

Paul,

> > We want to allow a leading underscore.  So, perhaps this:
> >    tcl-token = (ALPHA / "_") 0*(ALPHA / DIGIT) 0*(("-" / "_") 1*(ALPHA
> > /
> > DIGIT))
> 
> Well, there are two things to deal with:
> - what forms are allowed
> - how to represent that in ABNF
> 
> Well formed ABNF can answer both questions, as long as it isn't so obscure
> that people don't understand it.
> 
> I'm not in love with the leading "_" to signal non-standard adjectives,
> but neither do I hate it. But I'm much less fond of sequences of _ and -.

This is understandable, and it's also the subject of RFC 6648.  While I
might get shot for saying so, I actually do prefer having some means of
indicating that a value is non-standard.  At least then people can know to
ignore it. My personal opinion is that allowing "_foo" means that people are
creating their own risk.  That's fine.  Disallowing "_foo" means people will
use "foo" and then one day when the IETF standardizing "foo" we have two
values with perhaps very different meanings.
 
> Do you want "foo:_bar" to be a valid adjective? How about "_foo:bar"?

An "adjective" is the who string in each example, so both should be legal.

> ISTM that foo:_bar is probably a bad idea. So I'm thinking it would be
> better to define tcl_token so it doesn't permit a leading underscore.
> Then define the adjectives to allow the leading underscore where you want
> it.

The reason I want to allow "foo:_bar" is for the same reasons we allow
"_foo" or other vendor-specific value.  If we define a class of adjectives
(e.g, "aq:" or "pri:"), some vendor might have a value that fits within that
class.  So, they use "aq:_foo".  I don't think it's a bad idea at all.  As I
mentioned before, the adjective is the whole string, so it is either known
or not as a unit.  If someone cares to see that this is an adjective in a
known class, they can match on "aq:".  The "_foo" part is just treated as an
unknown value.
 
> So perhaps:
> 
> tcl-sep = "-" / "_"
> 
> tcl_token = ALPHA 0*(ALPHA / DIGIT) 0*((tcl-sep 1*(ALPHA / DIGIT))
> 
> std-unclassified-adj = tcl-token
> 
> std-adj-classifier = std-unclassified-adj ":"
> 
> adj-qualifier = tcl-token
> 
> std-classified_adj = std-adj-classifier adj-qualifier
> 
> standard-adjective = std-unclassified-adj / std-classified-adj
> 
> non-standard-adjective = "_" standard-adjective

Introducing "tcl-sep" might be reasonable, but I think we're making this
unnecessarily complex introducing "std-adj..." and "non-standard-adj..."
productions.  What benefit do we get from that?  I would prefer the "_"
(when it is leading) to be understood as non-standard, but I don't really
want to create parallel syntax.
 
> >> Also, your syntax doesn't cover non-standard-adjectives. You could
> >> cover that by:
> >>
> >>      adjective = standard-adjective / non-standard-adjective
> >>
> >>      standard-adjective = classified-adjective /
> >> unclassified-adjective
> >>
> >>      non-standard-adjective = "_" standard-adjective
> >
> > I don't think we should separate standard and non-standard adjectives
> > via syntax.  If we have a particular interpretation of "_foo" to mean
> > that it is non-standard, I think the above syntax will work.  We just
> > need to explain that adjectives with leading underscores are for non-
> standard use.
> 
> Hopefully I made a case above for putting it into the syntax.

If we really want to separate out standard and non-standard adjectives with
separate syntax, yes, I think you accomplished that (modulo the fact one
cannot have "aq:_foo").

> >> IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not*
> >> Unqualified adjectives.  Rather,
> >>
> >> 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified*
> >> adjectives.
> >>
> >> Does the distinction matter for registration? Should there be
> >> different criteria for registering new qualified adjectives? Maybe
> >> so. Maybe there should be some review of whether the new 'aq:foo' is
> >> compatible with the intended meaning of 'aq'???
> >
> > "aq" by itself is not an adjective.  "aq:admitted" is an adjective.
> 
> I see nothing to prevent both "aq" and "aq:admitted" from being
> registered. If you don't want to permit that, then say so.

We could do that, but is there benefit in doing so?  It would potentially
mean a 4-level registration (category, application, adjective-prefix,
adjective suffix).  I really have no idea what people would prefer there.  I
have no preference.  I just don't want to make it complicated.

> > What I would like to do is have a multi-level registration akin to
> > what we have for media types.  So, we would have something like this:
> >
> > +----------------------+----------------------+----------------------+
> > | Category             | Application          | Adjective            |
> > +----------------------+----------------------+----------------------+
> > | conversational       | audio                | immersive            |
\
...
/
> 
> The structure of the registry can be settled later. Work out the desired
> usage first. (But to get all that into IANA will be difficult.)
>
> My first thought is that IANA can simply register standard-adjectives
> without regard for whether they are qualified or not. The ones that are
> qualified will sort together.

That's what I was hoping to do by just having three levels.  I displayed the
"aq:" separately, but what I would expect to see on the web page would be
just the sorted list, as you said.

> But you might want a higher bar for registering a new adj-qualifier for an
> existing std-adj-classifier than you do for registering a new std-
> unclassified-adj. That will require more complex rules, and *might*
> require a different table structure.
> 
> E.g.
> 
> suppose aq:admitted and aq:non-admitted have already been registered.
> 
> Would you want it to be ok to register aq:foo for some purpose unrelated
> to the other two? I think not. What guidelines would you want to give to
> an expert to ensure that doesn't happen?

Yeah, agreed.
 
> (If there are no guidelines, and someone attempts to do this, the expert
> has no grounds other than his own opinion to reject the request.)

Understood.

Paul



From internet-drafts@ietf.org  Sat Aug 25 06:34:41 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8D421F849D; Sat, 25 Aug 2012 06:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.533
X-Spam-Level: 
X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L-uptAToGSa; Sat, 25 Aug 2012 06:34:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB02221F8489; Sat, 25 Aug 2012 06:34:40 -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.34
Message-ID: <20120825133440.25990.94570.idtracker@ietfa.amsl.com>
Date: Sat, 25 Aug 2012 06:34:40 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-06.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 13:34:41 -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           : SDP: Session Description Protocol
	Author(s)       : Mark Handley
                          Van Jacobson
                          Colin Perkins
                          Ali Begen
	Filename        : draft-ietf-mmusic-rfc4566bis-06.txt
	Pages           : 49
	Date            : 2012-08-25

Abstract:
   This memo defines the Session Description Protocol (SDP).  SDP is
   intended for describing multimedia sessions for the purposes of
   session announcement, session invitation, and other forms of
   multimedia session initiation.  This document obsoletes RFC 4566.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From fluffy@cisco.com  Sat Aug 25 06:41:24 2012
Return-Path: <fluffy@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3538021F84C2 for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 06:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.52
X-Spam-Level: 
X-Spam-Status: No, score=-109.52 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EaOSX6AI0LN for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 06:41: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 26B9621F84BF for <mmusic@ietf.org>; Sat, 25 Aug 2012 06:41:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4638; q=dns/txt; s=iport; t=1345902083; x=1347111683; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oVGzZjGtYjMV7PIFL0Fq1c9J3Z8Ke4FNTG3gXmsQSf8=; b=XHMoFEnL8yV8myDRulOf7WJnrxBpUbU8w6pNul25LF2Wq3ukRa0dyJgd ASkUZBdXK23YF8Orf+PkSbpfyuqWUiLCrFcuAD2uH+gFw80TjyBTiH8Mo QvFktdFT1V3oV1jn9yf5UiaSbLyWph/7suf2JKHqlBRkt8knm2nWU0N5X 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAMrUOFCtJV2d/2dsb2JhbABCA7prgQeCIAEBAQMBAQEBDwFbCxACAQhGJwslAgQOBSKHZQYLmyKfcIsIg3CCQWADiBqNO4EUjRqBZ4Jj
X-IronPort-AV: E=Sophos;i="4.80,309,1344211200"; d="scan'208";a="115219515"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 25 Aug 2012 13:41:21 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7PDfLST015016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Aug 2012 13:41:21 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Sat, 25 Aug 2012 08:41:21 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: AQHNgsdP1D3MaqrIX0S7qF9pJKmuag==
Date: Sat, 25 Aug 2012 13:41:11 +0000
Message-ID: <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>, <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
In-Reply-To: <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19136.006
x-tm-as-result: No--47.954800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9893CB33981F7F4082C727D8629E9A30@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 13:41:24 -0000

On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:

>=20
> Harald said:=20
> > Bernard, since I'm so easily confused by how people transmit layers of=
=20
> > layered codecs, can you illustrate the particular scheme you want to=20
> > use, and can't think of how to represent in Jonathan's scheme?
>=20
> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SD=
P". An
> example of how this would be used with H.264/SVC is included in RFC 6190,=
 Section 7.3.4:
>=20
>       a=3Dgroup:DDP L1 L2
>       m=3Dvideo 20000 RTP/AVP 96
>       a=3Drtpmap:96 H264/90000
>       a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-m=
ode=3DNI-T;
>       a=3Dmid:L1
>       m=3Dvideo 20002 RTP/AVP 97
>       a=3Drtpmap:97 H264-SVC/90000
>       a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>       a=3Dmid:L2
>       a=3Ddepend:97 lay L1:96
>=20
>=20
> Here the a=3Ddepend line is expressing the decoding dependency (layered i=
n this case).=20
>=20
> Let us assume that there is also audio, as in Jonathan's example:
>=20
>        m=3Daudio 10000 RTP/AVP 0 8 97
>        a=3Dmid:foo
>        b=3DAS:200
>        a=3Drtpmap:0 PCMU/8000
>        a=3Drtpmap:8 PCMA/8000
>        a=3Drtpmap:97 iLBC/8000
>=20
>=20
> Does the entire SDP offer with BUNDLE and dependency grouping  look like =
this (ignoring RTP/RTCP mux for the moment)?=20
>=20
>        v=3D0
>        o=3Dalice 2890844526 2890844526 IN IP4=20
> host.atlanta.com
>=20
>        s=3D
>        c=3DIN IP4=20
> host.atlanta.com
>=20
>        t=3D0 0
>        a=3Dgroup:BUNDLE foo L1 L2 baz
>=20
>        a=3Dgroup:DDP L1 L2
>        m=3Daudio 10000 RTP/AVP 0 8 98
>        a=3Dmid:foo
>        b=3DAS:200
>        a=3Drtpmap:0 PCMU/8000
>        a=3Drtpmap:8 PCMA/8000
>        a=3Drtpmap:98 iLBC/8000
>        a=3Dcandidate:1 1 UDP 1694498815=20
> host.atlanta.com
>  10000 typ host
>        m=3Dvideo 20000 RTP/AVP 96
>        a=3Drtpmap:96 H264/90000
>        a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-=
mode=3DNI-T;
>        a=3Dmid:L1
>        m=3Dvideo 20002 RTP/AVP 97
>        a=3Drtpmap:97 H264-SVC/90000
>        a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>        a=3Dmid:L2
>        a=3Ddepend:97 lay L1:96
>        a=3Dcandidate:1 1 UDP 1694498815=20
> host.atlanta.com
>  20002 typ host
>        m=3Dbundle 10000 RTP/AVP 0 8 96 97 98
>        a=3Dmid:baz
>        b=3DAS:1200
>        a=3Dfull-rtpmap:0 audio/PCMU/8000
>        a=3Dfull-rtpmap:8 audio/PCMA/8000
>        a=3Dfull-rtpmap:98 audio/iLBC/8000
>        a=3Dfull-rtpmap:96 H264/90000
>        a=3Dfull-rtpmap:97 H264-SVC/90000
>        a=3Ddepend:97 lay L1:96
>        a=3Dcandidate:1 1 UDP 1694498815=20
> host.atlanta.com
>  10000 typ host
>=20
>=20
> =20


I think it will work better if it just looked like=20

       v=3D0
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=3D
       c=3DIN IP4 host.atlanta.com

       t=3D0 0
       a=3Dgroup:BUNDLE foo L1 L2 baz

       a=3Dgroup:DDP L1 L2
       m=3Daudio 10000 RTP/AVP 0 8 98
       a=3Dmid:foo
       b=3DAS:200
       a=3Drtpmap:0 PCMU/8000
       a=3Drtpmap:8 PCMA/8000
       a=3Drtpmap:98 iLBC/8000
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=3Dvideo 20000 RTP/AVP 96
       a=3Drtpmap:96 H264/90000
       a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-mo=
de=3DNI-T;
       a=3Dmid:L1
       m=3Dvideo 20002 RTP/AVP 97
       a=3Drtpmap:97 H264-SVC/90000
       a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
       mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
      3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
       a=3Dmid:L2
       a=3Ddepend:97 lay L1:96
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host


that seems to have all the same information as the version with m=3Dbundle =
thing and AFAIC some firewalls are going to remove all the stuff under the =
m=3Dbundle line as it is not a recognized media type.=20


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


From harald@alvestrand.no  Sat Aug 25 07:28:02 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75B721F8496 for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 07:28:02 -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.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzKWFIEmJt+D for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 07:28:01 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3121F8493 for <mmusic@ietf.org>; Sat, 25 Aug 2012 07:28:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 146D739E12F; Sat, 25 Aug 2012 16:28:00 +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 yvI+ZR2L6Va3; Sat, 25 Aug 2012 16:27:59 +0200 (CEST)
Received: from [192.168.11.193] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DCA6C39E125; Sat, 25 Aug 2012 16:27:58 +0200 (CEST)
Message-ID: <5038E0EE.60608@alvestrand.no>
Date: Sat, 25 Aug 2012 16:27:58 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>, <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com>
In-Reply-To: <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 14:28:03 -0000

On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>
>> Harald said:
>>> Bernard, since I'm so easily confused by how people transmit layers of
>>> layered codecs, can you illustrate the particular scheme you want to
>>> use, and can't think of how to represent in Jonathan's scheme?
>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP". An
>> example of how this would be used with H.264/SVC is included in RFC 6190, Section 7.3.4:
>>
>>        a=group:DDP L1 L2
>>        m=video 20000 RTP/AVP 96
>>        a=rtpmap:96 H264/90000
>>        a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>        a=mid:L1
>>        m=video 20002 RTP/AVP 97
>>        a=rtpmap:97 H264-SVC/90000
>>        a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>        a=mid:L2
>>        a=depend:97 lay L1:96
>>
>>
>> Here the a=depend line is expressing the decoding dependency (layered in this case).
>>
>> Let us assume that there is also audio, as in Jonathan's example:
>>
>>         m=audio 10000 RTP/AVP 0 8 97
>>         a=mid:foo
>>         b=AS:200
>>         a=rtpmap:0 PCMU/8000
>>         a=rtpmap:8 PCMA/8000
>>         a=rtpmap:97 iLBC/8000
>>
>>
>> Does the entire SDP offer with BUNDLE and dependency grouping  look like this (ignoring RTP/RTCP mux for the moment)?
>>
>>         v=0
>>         o=alice 2890844526 2890844526 IN IP4
>> host.atlanta.com
>>
>>         s=
>>         c=IN IP4
>> host.atlanta.com
>>
>>         t=0 0
>>         a=group:BUNDLE foo L1 L2 baz
>>
>>         a=group:DDP L1 L2
>>         m=audio 10000 RTP/AVP 0 8 98
>>         a=mid:foo
>>         b=AS:200
>>         a=rtpmap:0 PCMU/8000
>>         a=rtpmap:8 PCMA/8000
>>         a=rtpmap:98 iLBC/8000
>>         a=candidate:1 1 UDP 1694498815
>> host.atlanta.com
>>   10000 typ host
>>         m=video 20000 RTP/AVP 96
>>         a=rtpmap:96 H264/90000
>>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>         a=mid:L1
>>         m=video 20002 RTP/AVP 97
>>         a=rtpmap:97 H264-SVC/90000
>>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>         a=mid:L2
>>         a=depend:97 lay L1:96
>>         a=candidate:1 1 UDP 1694498815
>> host.atlanta.com
>>   20002 typ host
>>         m=bundle 10000 RTP/AVP 0 8 96 97 98
>>         a=mid:baz
>>         b=AS:1200
>>         a=full-rtpmap:0 audio/PCMU/8000
>>         a=full-rtpmap:8 audio/PCMA/8000
>>         a=full-rtpmap:98 audio/iLBC/8000
>>         a=full-rtpmap:96 H264/90000
>>         a=full-rtpmap:97 H264-SVC/90000
>>         a=depend:97 lay L1:96
>>         a=candidate:1 1 UDP 1694498815
>> host.atlanta.com
>>   10000 typ host
>>
>>
>>   
>
> I think it will work better if it just looked like
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>
>         t=0 0
>         a=group:BUNDLE foo L1 L2 baz
>
>         a=group:DDP L1 L2
>         m=audio 10000 RTP/AVP 0 8 98
>         a=mid:foo
>         b=AS:200
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         a=rtpmap:98 iLBC/8000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>         m=video 20000 RTP/AVP 96
>         a=rtpmap:96 H264/90000
>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>         a=mid:L1
>         m=video 20002 RTP/AVP 97
>         a=rtpmap:97 H264-SVC/90000
>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>         a=mid:L2
>         a=depend:97 lay L1:96
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>
>
> that seems to have all the same information as the version with m=bundle thing and AFAIC some firewalls are going to remove all the stuff under the m=bundle line as it is not a recognized media type.
Not taking a position, but having firewalls remove all the m=bundle 
stuff (and presumably also the a=group:BUNDLE line) is, in my view, 
actually an advantage of this approach. (If the firewall removes the 
m=bundle and not the a=group:BUNDLE, we're left with a somewhat strange 
SDP.)

Cullen, I note you're using different port numbers on the m= sections. 
Are you assuming the semantics from a=group:TOGETHER - that one picks 
the first one?



From bernard_aboba@hotmail.com  Sat Aug 25 09:56:02 2012
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0D21F84C9 for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 09:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.787
X-Spam-Level: 
X-Spam-Status: No, score=-100.787 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx-QZ8Q+SwfB for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 09:56:01 -0700 (PDT)
Received: from blu0-omc4-s7.blu0.hotmail.com (blu0-omc4-s7.blu0.hotmail.com [65.55.111.146]) by ietfa.amsl.com (Postfix) with ESMTP id 39BD521F84C2 for <mmusic@ietf.org>; Sat, 25 Aug 2012 09:56:01 -0700 (PDT)
Received: from BLU401-EAS144 ([65.55.111.137]) by blu0-omc4-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 25 Aug 2012 09:56:01 -0700
X-Originating-IP: [64.134.134.12]
X-EIP: [sadxKLDD4N3q8SP12DxnPD8PPruxWxz5]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>
Content-Transfer-Encoding: quoted-printable
From: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <5038E0EE.60608@alvestrand.no>
Date: Sat, 25 Aug 2012 10:01:31 -0700
To: Harald Alvestrand <harald@alvestrand.no>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 25 Aug 2012 16:56:01.0447 (UTC) FILETIME=[81BCDB70:01CD82E2]
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 16:56:02 -0000

The different port number issue arises in multiple contexts here.  Firstly, i=
t arises within the dependency grouping.  RFC 6190 allows layers to use diff=
erent ports as well as allowing multiple layers to be sent to the same port.=
 While the SDP example in RFC 6190 (which I copied) shows different ports be=
ing offered, in practice, I believe that H.264/SVC implementations typically=
 prefer using the same port.  However, using the same port in an SDP offer c=
an cause answerers to reject the SDP as invalid, which is presumably why tha=
t approach was chosen for the RFC 6190 example. So the potential solution is=
 to offer different ports, and have the answer respond with the same port.  S=
econdly, the issue arises with the bundle grouping.=20

Cullen -- did you mean to include "baz" on the=20
a=3Dgroup:BUNDLE foo L1 L2 baz

line, since the a=3Dmid:baz line is now gone?=20

=20



On Aug 25, 2012, at 7:28, "Harald Alvestrand" <harald@alvestrand.no> wrote:

> On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
>> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>>=20
>>> Harald said:
>>>> Bernard, since I'm so easily confused by how people transmit layers of
>>>> layered codecs, can you illustrate the particular scheme you want to
>>>> use, and can't think of how to represent in Jonathan's scheme?
>>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in S=
DP". An
>>> example of how this would be used with H.264/SVC is included in RFC 6190=
, Section 7.3.4:
>>>=20
>>>       a=3Dgroup:DDP L1 L2
>>>       m=3Dvideo 20000 RTP/AVP 96
>>>       a=3Drtpmap:96 H264/90000
>>>       a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-=
mode=3DNI-T;
>>>       a=3Dmid:L1
>>>       m=3Dvideo 20002 RTP/AVP 97
>>>       a=3Drtpmap:97 H264-SVC/90000
>>>       a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>       a=3Dmid:L2
>>>       a=3Ddepend:97 lay L1:96
>>>=20
>>>=20
>>> Here the a=3Ddepend line is expressing the decoding dependency (layered i=
n this case).
>>>=20
>>> Let us assume that there is also audio, as in Jonathan's example:
>>>=20
>>>        m=3Daudio 10000 RTP/AVP 0 8 97
>>>        a=3Dmid:foo
>>>        b=3DAS:200
>>>        a=3Drtpmap:0 PCMU/8000
>>>        a=3Drtpmap:8 PCMA/8000
>>>        a=3Drtpmap:97 iLBC/8000
>>>=20
>>>=20
>>> Does the entire SDP offer with BUNDLE and dependency grouping  look like=
 this (ignoring RTP/RTCP mux for the moment)?
>>>=20
>>>        v=3D0
>>>        o=3Dalice 2890844526 2890844526 IN IP4
>>> host.atlanta.com
>>>=20
>>>        s=3D
>>>        c=3DIN IP4
>>> host.atlanta.com
>>>=20
>>>        t=3D0 0
>>>        a=3Dgroup:BUNDLE foo L1 L2 baz
>>>=20
>>>        a=3Dgroup:DDP L1 L2
>>>        m=3Daudio 10000 RTP/AVP 0 8 98
>>>        a=3Dmid:foo
>>>        b=3DAS:200
>>>        a=3Drtpmap:0 PCMU/8000
>>>        a=3Drtpmap:8 PCMA/8000
>>>        a=3Drtpmap:98 iLBC/8000
>>>        a=3Dcandidate:1 1 UDP 1694498815
>>> host.atlanta.com
>>>  10000 typ host
>>>        m=3Dvideo 20000 RTP/AVP 96
>>>        a=3Drtpmap:96 H264/90000
>>>        a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst=
-mode=3DNI-T;
>>>        a=3Dmid:L1
>>>        m=3Dvideo 20002 RTP/AVP 97
>>>        a=3Drtpmap:97 H264-SVC/90000
>>>        a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>        a=3Dmid:L2
>>>        a=3Ddepend:97 lay L1:96
>>>        a=3Dcandidate:1 1 UDP 1694498815
>>> host.atlanta.com
>>>  20002 typ host
>>>        m=3Dbundle 10000 RTP/AVP 0 8 96 97 98
>>>        a=3Dmid:baz
>>>        b=3DAS:1200
>>>        a=3Dfull-rtpmap:0 audio/PCMU/8000
>>>        a=3Dfull-rtpmap:8 audio/PCMA/8000
>>>        a=3Dfull-rtpmap:98 audio/iLBC/8000
>>>        a=3Dfull-rtpmap:96 H264/90000
>>>        a=3Dfull-rtpmap:97 H264-SVC/90000
>>>        a=3Ddepend:97 lay L1:96
>>>        a=3Dcandidate:1 1 UDP 1694498815
>>> host.atlanta.com
>>>  10000 typ host
>>>=20
>>>=20
>>> =20
>>=20
>> I think it will work better if it just looked like
>>=20
>>        v=3D0
>>        o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>>        s=3D
>>        c=3DIN IP4 host.atlanta.com
>>=20
>>        t=3D0 0
>>        a=3Dgroup:BUNDLE foo L1 L2 baz
>>=20
>>        a=3Dgroup:DDP L1 L2
>>        m=3Daudio 10000 RTP/AVP 0 8 98
>>        a=3Dmid:foo
>>        b=3DAS:200
>>        a=3Drtpmap:0 PCMU/8000
>>        a=3Drtpmap:8 PCMA/8000
>>        a=3Drtpmap:98 iLBC/8000
>>        a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>>        m=3Dvideo 20000 RTP/AVP 96
>>        a=3Drtpmap:96 H264/90000
>>        a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst-=
mode=3DNI-T;
>>        a=3Dmid:L1
>>        m=3Dvideo 20002 RTP/AVP 97
>>        a=3Drtpmap:97 H264-SVC/90000
>>        a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>        a=3Dmid:L2
>>        a=3Ddepend:97 lay L1:96
>>        a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>>=20
>>=20
>> that seems to have all the same information as the version with m=3Dbundl=
e thing and AFAIC some firewalls are going to remove all the stuff under the=
 m=3Dbundle line as it is not a recognized media type.
> Not taking a position, but having firewalls remove all the m=3Dbundle stuf=
f (and presumably also the a=3Dgroup:BUNDLE line) is, in my view, actually a=
n advantage of this approach. (If the firewall removes the m=3Dbundle and no=
t the a=3Dgroup:BUNDLE, we're left with a somewhat strange SDP.)
>=20
> Cullen, I note you're using different port numbers on the m=3D sections. A=
re you assuming the semantics from a=3Dgroup:TOGETHER - that one picks the f=
irst one?
>=20
>=20

From christer.holmberg@ericsson.com  Sat Aug 25 11:36:00 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C01921F84FB for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 11:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.277
X-Spam-Level: 
X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44n2AO8Mp1sm for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 11:35:59 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BBBBD21F84F9 for <mmusic@ietf.org>; Sat, 25 Aug 2012 11:35:58 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-33-50391b0cfd48
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FA.06.11467.C0B19305; Sat, 25 Aug 2012 20:35:56 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Sat, 25 Aug 2012 20:35:57 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Harald Alvestrand <harald@alvestrand.no>
Date: Sat, 25 Aug 2012 20:35:55 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac2C4oRUcbN/uueqRTWlq5KwmwM84wAC8OlS
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl>
In-Reply-To: <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvrS6PtGWAwYRmM4v9Sy4zW3RMZrM4 1tfFZjF1+WMWBxaPKxOusHpM+b2R1eNxzxk2jyVLfjIFsERx2aSk5mSWpRbp2yVwZZxvXc1W 8MKk4v2OPpYGxnkaXYycHBICJhK/L15jgrDFJC7cW8/WxcjFISRwilFiwtQGFghnAaPE342T WbsYOTjYBCwkuv9pgzSICERKPJr5kRXEZhaIkJi/eys7iM0ioCqxaucBRhBbWCBe4u/HfiaI +gSJ2fOPsULYRhK7Fl9nBrF5BcIletf9ZofY9ZpJ4tfLGWDNnAK2Eu/X3gJrYAS67vupNUwQ y8Qlbj2ZD3W1gMSSPeeZIWxRiZeP/0HVi0rcaV/PCFGvI7Fg9yc2CFtbYtnC11CLBSVOznzC MoFRbBaSsbOQtMxC0jILScsCRpZVjMK5iZk56eWGeqlFmcnFxfl5esWpmxiBMXZwy2/dHYyn zokcYpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFkc/xe26Ly+Ul7DYtO dOVahTCV/uM3OX7F+Okeza1CSapbzVwv5FzNXHLkW+nCZ3cV1Ffvll5keD506xmnqG/KO3Qb Hvz9c1BAcOXchBi/97OWtlQxvDuivEeqqCrabOrsr6dmZnK+utlz6dtetkPK1+w9GPN+37F7 nSGw+94Znga/AGPfc1FKLMUZiYZazEXFiQBlv1LffwIAAA==
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line	for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 18:36:00 -0000

Hi,

> The different port number issue arises in multiple contexts here.  Firstl=
y, it arises within the dependency grouping.  RFC 6190 allows=20
> layers to use different ports as well as allowing multiple layers to be s=
ent to the same port. While the SDP example in RFC 6190=20
> (which I copied) shows different ports being offered, in practice, I beli=
eve that H.264/SVC implementations typically prefer using the=20
> same port.  However, using the same port in an SDP offer can cause answer=
ers to reject the SDP as invalid, which is presumably why=20
> that approach was chosen for the RFC 6190 example. So the potential solut=
ion is to offer different ports, and have the answer respond with the same =
port.=20

That is what Harald's original TOGETHER proposal was all about, and where I=
 had issues (related to intermediares who assume that the offered ports are=
 used, and if the offer wants to set the multiplex port to zero).

So, IF people think that offering the same port will cause problem, and IF =
people think that an m=3Dbundle m- line would be removed, maybe the only op=
tion is to have 2 offer/answers: the first is a "normal" offer, with differ=
ent ports, and if the answerer indicates that it supports bundle then the s=
econd offer will be sent with the same port.

Regards,

Christer




On Aug 25, 2012, at 7:28, "Harald Alvestrand" <harald@alvestrand.no> wrote:

> On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
>> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>>
>>> Harald said:
>>>> Bernard, since I'm so easily confused by how people transmit layers of
>>>> layered codecs, can you illustrate the particular scheme you want to
>>>> use, and can't think of how to represent in Jonathan's scheme?
>>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in =
SDP". An
>>> example of how this would be used with H.264/SVC is included in RFC 619=
0, Section 7.3.4:
>>>
>>>       a=3Dgroup:DDP L1 L2
>>>       m=3Dvideo 20000 RTP/AVP 96
>>>       a=3Drtpmap:96 H264/90000
>>>       a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst=
-mode=3DNI-T;
>>>       a=3Dmid:L1
>>>       m=3Dvideo 20002 RTP/AVP 97
>>>       a=3Drtpmap:97 H264-SVC/90000
>>>       a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>       a=3Dmid:L2
>>>       a=3Ddepend:97 lay L1:96
>>>
>>>
>>> Here the a=3Ddepend line is expressing the decoding dependency (layered=
 in this case).
>>>
>>> Let us assume that there is also audio, as in Jonathan's example:
>>>
>>>        m=3Daudio 10000 RTP/AVP 0 8 97
>>>        a=3Dmid:foo
>>>        b=3DAS:200
>>>        a=3Drtpmap:0 PCMU/8000
>>>        a=3Drtpmap:8 PCMA/8000
>>>        a=3Drtpmap:97 iLBC/8000
>>>
>>>
>>> Does the entire SDP offer with BUNDLE and dependency grouping  look lik=
e this (ignoring RTP/RTCP mux for the moment)?
>>>
>>>        v=3D0
>>>        o=3Dalice 2890844526 2890844526 IN IP4
>>> host.atlanta.com
>>>
>>>        s=3D
>>>        c=3DIN IP4
>>> host.atlanta.com
>>>
>>>        t=3D0 0
>>>        a=3Dgroup:BUNDLE foo L1 L2 baz
>>>
>>>        a=3Dgroup:DDP L1 L2
>>>        m=3Daudio 10000 RTP/AVP 0 8 98
>>>        a=3Dmid:foo
>>>        b=3DAS:200
>>>        a=3Drtpmap:0 PCMU/8000
>>>        a=3Drtpmap:8 PCMA/8000
>>>        a=3Drtpmap:98 iLBC/8000
>>>        a=3Dcandidate:1 1 UDP 1694498815
>>> host.atlanta.com
>>>  10000 typ host
>>>        m=3Dvideo 20000 RTP/AVP 96
>>>        a=3Drtpmap:96 H264/90000
>>>        a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;ms=
t-mode=3DNI-T;
>>>        a=3Dmid:L1
>>>        m=3Dvideo 20002 RTP/AVP 97
>>>        a=3Drtpmap:97 H264-SVC/90000
>>>        a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>        a=3Dmid:L2
>>>        a=3Ddepend:97 lay L1:96
>>>        a=3Dcandidate:1 1 UDP 1694498815
>>> host.atlanta.com
>>>  20002 typ host
>>>        m=3Dbundle 10000 RTP/AVP 0 8 96 97 98
>>>        a=3Dmid:baz
>>>        b=3DAS:1200
>>>        a=3Dfull-rtpmap:0 audio/PCMU/8000
>>>        a=3Dfull-rtpmap:8 audio/PCMA/8000
>>>        a=3Dfull-rtpmap:98 audio/iLBC/8000
>>>        a=3Dfull-rtpmap:96 H264/90000
>>>        a=3Dfull-rtpmap:97 H264-SVC/90000
>>>        a=3Ddepend:97 lay L1:96
>>>        a=3Dcandidate:1 1 UDP 1694498815
>>> host.atlanta.com
>>>  10000 typ host
>>>
>>>
>>>
>>
>> I think it will work better if it just looked like
>>
>>        v=3D0
>>        o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>>        s=3D
>>        c=3DIN IP4 host.atlanta.com
>>
>>        t=3D0 0
>>        a=3Dgroup:BUNDLE foo L1 L2 baz
>>
>>        a=3Dgroup:DDP L1 L2
>>        m=3Daudio 10000 RTP/AVP 0 8 98
>>        a=3Dmid:foo
>>        b=3DAS:200
>>        a=3Drtpmap:0 PCMU/8000
>>        a=3Drtpmap:8 PCMA/8000
>>        a=3Drtpmap:98 iLBC/8000
>>        a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>>        m=3Dvideo 20000 RTP/AVP 96
>>        a=3Drtpmap:96 H264/90000
>>        a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;mst=
-mode=3DNI-T;
>>        a=3Dmid:L1
>>        m=3Dvideo 20002 RTP/AVP 97
>>        a=3Drtpmap:97 H264-SVC/90000
>>        a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>        mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>       3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>        a=3Dmid:L2
>>        a=3Ddepend:97 lay L1:96
>>        a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>>
>>
>> that seems to have all the same information as the version with m=3Dbund=
le thing and AFAIC some firewalls are going to remove all the stuff under t=
he m=3Dbundle line as it is not a recognized media type.
> Not taking a position, but having firewalls remove all the m=3Dbundle stu=
ff (and presumably also the a=3Dgroup:BUNDLE line) is, in my view, actually=
 an advantage of this approach. (If the firewall removes the m=3Dbundle and=
 not the a=3Dgroup:BUNDLE, we're left with a somewhat strange SDP.)
>
> Cullen, I note you're using different port numbers on the m=3D sections. =
Are you assuming the semantics from a=3Dgroup:TOGETHER - that one picks the=
 first one?
>
>
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic=

From harald@alvestrand.no  Mon Aug 27 01:03:08 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD23221F8508 for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 01:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.46
X-Spam-Level: 
X-Spam-Status: No, score=-109.46 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taX5PoKBB-Wg for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 01:03:08 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9021F845E for <mmusic@ietf.org>; Mon, 27 Aug 2012 01:03:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B768E39E0FD; Mon, 27 Aug 2012 10:03:04 +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 SC810PWBG7Pm; Mon, 27 Aug 2012 10:03:03 +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 13C5A39E0F3; Mon, 27 Aug 2012 10:03:03 +0200 (CEST)
Message-ID: <503B29B6.5000000@alvestrand.no>
Date: Mon, 27 Aug 2012 10:03:02 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 08:03:09 -0000

On 08/25/2012 08:35 PM, Christer Holmberg wrote:
> Hi,
>
>> The different port number issue arises in multiple contexts here.  Firstly, it arises within the dependency grouping.  RFC 6190 allows
>> layers to use different ports as well as allowing multiple layers to be sent to the same port. While the SDP example in RFC 6190
>> (which I copied) shows different ports being offered, in practice, I believe that H.264/SVC implementations typically prefer using the
>> same port.  However, using the same port in an SDP offer can cause answerers to reject the SDP as invalid, which is presumably why
>> that approach was chosen for the RFC 6190 example. So the potential solution is to offer different ports, and have the answer respond with the same port.
> That is what Harald's original TOGETHER proposal was all about, and where I had issues (related to intermediares who assume that the offered ports are used, and if the offer wants to set the multiplex port to zero).
>
> So, IF people think that offering the same port will cause problem, and IF people think that an m=bundle m- line would be removed, maybe the only option is to have 2 offer/answers: the first is a "normal" offer, with different ports, and if the answerer indicates that it supports bundle then the second offer will be sent with the same port.
If "m=bundle m-line is removed" means "we'll negotiate the old style 
session with old equipment", then that's a success, not a failure.

>
> Regards,
>
> Christer
>
>
>
>
> On Aug 25, 2012, at 7:28, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>
>> On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
>>> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>>>
>>>> Harald said:
>>>>> Bernard, since I'm so easily confused by how people transmit layers of
>>>>> layered codecs, can you illustrate the particular scheme you want to
>>>>> use, and can't think of how to represent in Jonathan's scheme?
>>>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP". An
>>>> example of how this would be used with H.264/SVC is included in RFC 6190, Section 7.3.4:
>>>>
>>>>        a=group:DDP L1 L2
>>>>        m=video 20000 RTP/AVP 96
>>>>        a=rtpmap:96 H264/90000
>>>>        a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>>>        a=mid:L1
>>>>        m=video 20002 RTP/AVP 97
>>>>        a=rtpmap:97 H264-SVC/90000
>>>>        a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>>        a=mid:L2
>>>>        a=depend:97 lay L1:96
>>>>
>>>>
>>>> Here the a=depend line is expressing the decoding dependency (layered in this case).
>>>>
>>>> Let us assume that there is also audio, as in Jonathan's example:
>>>>
>>>>         m=audio 10000 RTP/AVP 0 8 97
>>>>         a=mid:foo
>>>>         b=AS:200
>>>>         a=rtpmap:0 PCMU/8000
>>>>         a=rtpmap:8 PCMA/8000
>>>>         a=rtpmap:97 iLBC/8000
>>>>
>>>>
>>>> Does the entire SDP offer with BUNDLE and dependency grouping  look like this (ignoring RTP/RTCP mux for the moment)?
>>>>
>>>>         v=0
>>>>         o=alice 2890844526 2890844526 IN IP4
>>>> host.atlanta.com
>>>>
>>>>         s=
>>>>         c=IN IP4
>>>> host.atlanta.com
>>>>
>>>>         t=0 0
>>>>         a=group:BUNDLE foo L1 L2 baz
>>>>
>>>>         a=group:DDP L1 L2
>>>>         m=audio 10000 RTP/AVP 0 8 98
>>>>         a=mid:foo
>>>>         b=AS:200
>>>>         a=rtpmap:0 PCMU/8000
>>>>         a=rtpmap:8 PCMA/8000
>>>>         a=rtpmap:98 iLBC/8000
>>>>         a=candidate:1 1 UDP 1694498815
>>>> host.atlanta.com
>>>>   10000 typ host
>>>>         m=video 20000 RTP/AVP 96
>>>>         a=rtpmap:96 H264/90000
>>>>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>>>         a=mid:L1
>>>>         m=video 20002 RTP/AVP 97
>>>>         a=rtpmap:97 H264-SVC/90000
>>>>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>>         a=mid:L2
>>>>         a=depend:97 lay L1:96
>>>>         a=candidate:1 1 UDP 1694498815
>>>> host.atlanta.com
>>>>   20002 typ host
>>>>         m=bundle 10000 RTP/AVP 0 8 96 97 98
>>>>         a=mid:baz
>>>>         b=AS:1200
>>>>         a=full-rtpmap:0 audio/PCMU/8000
>>>>         a=full-rtpmap:8 audio/PCMA/8000
>>>>         a=full-rtpmap:98 audio/iLBC/8000
>>>>         a=full-rtpmap:96 H264/90000
>>>>         a=full-rtpmap:97 H264-SVC/90000
>>>>         a=depend:97 lay L1:96
>>>>         a=candidate:1 1 UDP 1694498815
>>>> host.atlanta.com
>>>>   10000 typ host
>>>>
>>>>
>>>>
>>> I think it will work better if it just looked like
>>>
>>>         v=0
>>>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>>>         s=
>>>         c=IN IP4 host.atlanta.com
>>>
>>>         t=0 0
>>>         a=group:BUNDLE foo L1 L2 baz
>>>
>>>         a=group:DDP L1 L2
>>>         m=audio 10000 RTP/AVP 0 8 98
>>>         a=mid:foo
>>>         b=AS:200
>>>         a=rtpmap:0 PCMU/8000
>>>         a=rtpmap:8 PCMA/8000
>>>         a=rtpmap:98 iLBC/8000
>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>>>         m=video 20000 RTP/AVP 96
>>>         a=rtpmap:96 H264/90000
>>>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>>         a=mid:L1
>>>         m=video 20002 RTP/AVP 97
>>>         a=rtpmap:97 H264-SVC/90000
>>>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>         a=mid:L2
>>>         a=depend:97 lay L1:96
>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>>>
>>>
>>> that seems to have all the same information as the version with m=bundle thing and AFAIC some firewalls are going to remove all the stuff under the m=bundle line as it is not a recognized media type.
>> Not taking a position, but having firewalls remove all the m=bundle stuff (and presumably also the a=group:BUNDLE line) is, in my view, actually an advantage of this approach. (If the firewall removes the m=bundle and not the a=group:BUNDLE, we're left with a somewhat strange SDP.)
>>
>> Cullen, I note you're using different port numbers on the m= sections. Are you assuming the semantics from a=group:TOGETHER - that one picks the first one?
>>
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From christer.holmberg@ericsson.com  Mon Aug 27 01:39:52 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBF221F8551 for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 01:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.267
X-Spam-Level: 
X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-D8fHkn0yoM for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 01:39:51 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1302021F850C for <mmusic@ietf.org>; Mon, 27 Aug 2012 01:39:50 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-d8-503b3255554a
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.19.11467.5523B305; Mon, 27 Aug 2012 10:39:49 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 27 Aug 2012 10:39:49 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 27 Aug 2012 10:39:47 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac2EKmPIuZrWJAeWS9GjczdeFq8EYgABNFXw
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A292D94@ESESSCMS0356.eemea.ericsson.se>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>
In-Reply-To: <503B29B6.5000000@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvrW6okXWAwfmbyhb7l1xmtuiYzGZx rK+LzWLq8scsDiweVyZcYfWY8nsjq8fjnjNsHkuW/GQKYInisklJzcksSy3St0vgyri68CNb wWWLiu1t+1gaGDu0uxg5OSQETCSOrWhggbDFJC7cW8/WxcjFISRwilFi5fvZUM4CRolbnbOA qjg42AQsJLr/gTWLCOhIPNzfwARSwyzQzChxdtsJJpAEi4CqxJc9X9lAbGGBeIkV25YyQzQk SOyatJYRZI6IgJHEnCVeIGFegXCJDVeWsEPsusMs0XR6Nlg9p4CuRNfbV2BzGIGu+35qDdh8 ZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEYkGJ kzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYIwd3PJb dwfjqXMihxilOViUxHm5kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBs+v7cavcSC6OE 7g3/zbJTp76cvWSDQtfOxIe9p6I0s0U+XpuTLPZc+oxfzh7DXn8mfn0LwbBkeanT79du+i2u ayTN/VGlcO/yoL9R1xNkrKoki9xf+XSLJzqZP93qbyGkXiMV/4ZF4rG+l/hVthDXw9YzWno+ frJ7MO2YqpB9TdmR7otnXJVYijMSDbWYi4oTATs2YIJ/AgAA
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 08:39:52 -0000

Hi,

>>> The different port number issue arises in multiple contexts here. =20
>>> Firstly, it arises within the dependency grouping.  RFC 6190 allows=20
>>> layers to use different ports as well as allowing multiple layers to=20
>>> be sent to the same port. While the SDP example in RFC 6190 (which I=20
>>> copied) shows different ports being offered, in practice, I believe tha=
t H.264/SVC implementations typically prefer using the same port.  However,=
 using the same port in an SDP offer can cause answerers to reject the SDP =
as invalid, which is >>>presumably why that approach was chosen for the RFC=
 6190 example. So the potential solution is to offer different ports, and h=
ave the answer respond with the same port.
>> That is what Harald's original TOGETHER proposal was all about, and wher=
e I had issues (related to intermediares who assume that the offered ports =
are used, and if the offer wants to set the multiplex port to zero).
>>
>> So, IF people think that offering the same port will cause problem, and =
IF people think that an m=3Dbundle m- line would be removed, maybe the only=
 option is to have 2 offer/answers: the first is a "normal" offer, with dif=
ferent ports, and if the answerer >>indicates that it supports bundle then =
the second offer will be sent with the same port.
>If "m=3Dbundle m-line is removed" means "we'll negotiate the old style ses=
sion with old equipment", then that's a success, not a failure.

Agree. There would be no multiplexing, but the session establishment would =
still succeed.

Regards,

Christer


> On Aug 25, 2012, at 7:28, "Harald Alvestrand" <harald@alvestrand.no> wrot=
e:
>
>> On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
>>> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>>>
>>>> Harald said:
>>>>> Bernard, since I'm so easily confused by how people transmit=20
>>>>> layers of layered codecs, can you illustrate the particular scheme=20
>>>>> you want to use, and can't think of how to represent in Jonathan's sc=
heme?
>>>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency=20
>>>> in SDP". An example of how this would be used with H.264/SVC is includ=
ed in RFC 6190, Section 7.3.4:
>>>>
>>>>        a=3Dgroup:DDP L1 L2
>>>>        m=3Dvideo 20000 RTP/AVP 96
>>>>        a=3Drtpmap:96 H264/90000
>>>>        a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;m=
st-mode=3DNI-T;
>>>>        a=3Dmid:L1
>>>>        m=3Dvideo 20002 RTP/AVP 97
>>>>        a=3Drtpmap:97 H264-SVC/90000
>>>>        a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>>         mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c=
,
>>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>>        a=3Dmid:L2
>>>>        a=3Ddepend:97 lay L1:96
>>>>
>>>>
>>>> Here the a=3Ddepend line is expressing the decoding dependency (layere=
d in this case).
>>>>
>>>> Let us assume that there is also audio, as in Jonathan's example:
>>>>
>>>>         m=3Daudio 10000 RTP/AVP 0 8 97
>>>>         a=3Dmid:foo
>>>>         b=3DAS:200
>>>>         a=3Drtpmap:0 PCMU/8000
>>>>         a=3Drtpmap:8 PCMA/8000
>>>>         a=3Drtpmap:97 iLBC/8000
>>>>
>>>>
>>>> Does the entire SDP offer with BUNDLE and dependency grouping  look li=
ke this (ignoring RTP/RTCP mux for the moment)?
>>>>
>>>>         v=3D0
>>>>         o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>>>>
>>>>         s=3D
>>>>         c=3DIN IP4
>>>> host.atlanta.com
>>>>
>>>>         t=3D0 0
>>>>         a=3Dgroup:BUNDLE foo L1 L2 baz
>>>>
>>>>         a=3Dgroup:DDP L1 L2
>>>>         m=3Daudio 10000 RTP/AVP 0 8 98
>>>>         a=3Dmid:foo
>>>>         b=3DAS:200
>>>>         a=3Drtpmap:0 PCMU/8000
>>>>         a=3Drtpmap:8 PCMA/8000
>>>>         a=3Drtpmap:98 iLBC/8000
>>>>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com
>>>>   10000 typ host
>>>>         m=3Dvideo 20000 RTP/AVP 96
>>>>         a=3Drtpmap:96 H264/90000
>>>>         a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;=
mst-mode=3DNI-T;
>>>>         a=3Dmid:L1
>>>>         m=3Dvideo 20002 RTP/AVP 97
>>>>         a=3Drtpmap:97 H264-SVC/90000
>>>>         a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>>         mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c=
,
>>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>>         a=3Dmid:L2
>>>>         a=3Ddepend:97 lay L1:96
>>>>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com
>>>>   20002 typ host
>>>>         m=3Dbundle 10000 RTP/AVP 0 8 96 97 98
>>>>         a=3Dmid:baz
>>>>         b=3DAS:1200
>>>>         a=3Dfull-rtpmap:0 audio/PCMU/8000
>>>>         a=3Dfull-rtpmap:8 audio/PCMA/8000
>>>>         a=3Dfull-rtpmap:98 audio/iLBC/8000
>>>>         a=3Dfull-rtpmap:96 H264/90000
>>>>         a=3Dfull-rtpmap:97 H264-SVC/90000
>>>>         a=3Ddepend:97 lay L1:96
>>>>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com
>>>>   10000 typ host
>>>>
>>>>
>>>>
>>> I think it will work better if it just looked like
>>>
>>>         v=3D0
>>>         o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>>>         s=3D
>>>         c=3DIN IP4 host.atlanta.com
>>>
>>>         t=3D0 0
>>>         a=3Dgroup:BUNDLE foo L1 L2 baz
>>>
>>>         a=3Dgroup:DDP L1 L2
>>>         m=3Daudio 10000 RTP/AVP 0 8 98
>>>         a=3Dmid:foo
>>>         b=3DAS:200
>>>         a=3Drtpmap:0 PCMU/8000
>>>         a=3Drtpmap:8 PCMA/8000
>>>         a=3Drtpmap:98 iLBC/8000
>>>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ hos=
t
>>>         m=3Dvideo 20000 RTP/AVP 96
>>>         a=3Drtpmap:96 H264/90000
>>>         a=3Dfmtp:96 profile-level-id=3D4de00a; packetization-mode=3D0;m=
st-mode=3DNI-T;
>>>         a=3Dmid:L1
>>>         m=3Dvideo 20002 RTP/AVP 97
>>>         a=3Drtpmap:97 H264-SVC/90000
>>>         a=3Dfmtp:97 profile-level-id=3D53001F; packetization-mode=3D1;
>>>         mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,
>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>         a=3Dmid:L2
>>>         a=3Ddepend:97 lay L1:96
>>>         a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ=20
>>> host
>>>
>>>
>>> that seems to have all the same information as the version with m=3Dbun=
dle thing and AFAIC some firewalls are going to remove all the stuff under =
the m=3Dbundle line as it is not a recognized media type.
>> Not taking a position, but having firewalls remove all the m=3Dbundle=20
>> stuff (and presumably also the a=3Dgroup:BUNDLE line) is, in my view,=20
>> actually an advantage of this approach. (If the firewall removes the=20
>> m=3Dbundle and not the a=3Dgroup:BUNDLE, we're left with a somewhat=20
>> strange SDP.)
>>
>> Cullen, I note you're using different port numbers on the m=3D sections.=
 Are you assuming the semantics from a=3Dgroup:TOGETHER - that one picks th=
e first one?
>>
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From internet-drafts@ietf.org  Mon Aug 27 05:43:46 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3704A21F8645; Mon, 27 Aug 2012 05:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH+I-PI1OvtY; Mon, 27 Aug 2012 05:43:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BF321F861A; Mon, 27 Aug 2012 05:43:45 -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.34
Message-ID: <20120827124345.29134.13763.idtracker@ietfa.amsl.com>
Date: Mon, 27 Aug 2012 05:43:45 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 12:43:46 -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           : Miscellanoues 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-01.txt
	Pages           : 19
	Date            : 2012-08-27

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps=
-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From miguel.a.garcia@ericsson.com  Mon Aug 27 07:32:03 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC66521F8645 for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 07:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.212
X-Spam-Level: 
X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rYv0v0N9l8e for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 07:32:03 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AEE6B21F8611 for <mmusic@ietf.org>; Mon, 27 Aug 2012 07:32:02 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-51-503b84e1d89c
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 48.4D.25676.1E48B305; Mon, 27 Aug 2012 16:32:01 +0200 (CEST)
Received: from [159.107.25.85] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Mon, 27 Aug 2012 16:32:00 +0200
Message-ID: <503B84DF.9000303@ericsson.com>
Date: Mon, 27 Aug 2012 16:31:59 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
References: <20120827124345.29134.16722.idtracker@ietfa.amsl.com>
In-Reply-To: <20120827124345.29134.16722.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120827124345.29134.16722.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Vvdhi3WAwfR/ShZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq8715gLLglUfJ2R28D4gbeLkZNDQsBEonXtZUYIW0ziwr31 bF2MXBxCAqcYJd5t/ckEkhASWM0osehJAYjNK6AtcbrxGTOIzSKgKtH++CNYDZuAuUTrxo3s ILaoQKDE89lb2CHqBSVOznzCAmKLCMhI7N20GaxXWCBK4u7031DzHSVu730FFOfg4BRwkmg7 XwBxj6/E4kN/wW5jFrCQWPzmIDuELS+x/e0cZohWTYnJN5cyT2AUnIVk2ywkLbOQtCxgZF7F KJybmJmTXm6kl1qUmVxcnJ+nV5y6iREYkge3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MNq/lKzY6/Gi8U+tdIaCyl423lkVufPkhH/pzshu0475ZGa/ QLbtSZ+9xtmfdZvWK0hn9IXdXpX82nLRjEfXI3+nR0TYLJReLvcxmSl2lm/xw6l13S8ecgt5 3OT8fali46rom6/DZ19hr7eWKzHmiFB0nXBoQ/RE5U/LX3g4WSXYMh1L3/bbXomlOCPRUIu5 qDgRACe4FBIXAgAA
Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 14:32:03 -0000

Just a brief note that we have released a new version of the SDP 
miscellaneous capabilities draft.

There are no changes in this version. This is just to avoid expiration of 
the current draft.

/Miguel


-------- Original Message --------
Subject: New Version Notification for 
draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
Date: Mon, 27 Aug 2012 14:43:45 +0200
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
To: Miguel Garcia A <miguel.a.garcia@ericsson.com>
CC: simo.veikkolainen@nokia.com <simo.veikkolainen@nokia.com>, 
bob_gilman@comcast.net <bob_gilman@comcast.net>


A new version of I-D, draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
has been successfully submitted by Miguel A. Garcia-Martin and posted to the
IETF repository.

Filename:	 draft-ietf-mmusic-sdp-miscellaneous-caps
Revision:	 01
Title:		 Miscellanoues Capabilities Negotiation in the Session 
Description Protocol (SDP)
Creation date:	 2012-08-27
WG ID:		 mmusic
Number of pages: 19
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
Status: 
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps
Htmlized: 
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-01

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=' line), connection data ('c=' line), and titles ('i=' line for
    each session or media).

 



The IETF Secretariat




From abegen@cisco.com  Mon Aug 27 09:04:54 2012
Return-Path: <abegen@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA97721F8551 for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 09:04:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x02qBybmPRu for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 09:04:54 -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 04A8021F854E for <mmusic@ietf.org>; Mon, 27 Aug 2012 09:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3618; q=dns/txt; s=iport; t=1346083494; x=1347293094; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1ATf48tbAYeyJuXvENALOY7OV2lN3FV79qgeti5tU7Y=; b=T+c53qmCMnwb1mLB+5kHo2hhgmp4uh7rCtIfPoQ3deFT4GSiDw6qYoX4 olP/Lzc+5aDagcwvj7+zqWDz49+coYgtFO92RnYQvK8ykSnerMORe6s03 ngQWu6dNp/Lpo12x0/M8w8t4BGydWQD/37xcM6erb9/r0fl/QE3nQF5Wu A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANSZO1CtJV2b/2dsb2JhbABFgm24C4EHgiABAQEEEgFVHQQCAQgRBAEBCx0HMhQJCAEBBBMIGodrAZoroAuLCAKGL2ADpAOBZ4Jj
X-IronPort-AV: E=Sophos;i="4.80,321,1344211200"; d="scan'208";a="115691071"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 27 Aug 2012 16:04:53 +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 q7RG4r58023010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Mon, 27 Aug 2012 16:04:53 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 11:04:53 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
Thread-Index: Ac1z5irXaxvG+6IYTyi3BKqjoBMk/ABMAh4wAA/knVADxe27oA==
Date: Mon, 27 Aug 2012 16:04:52 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local>
In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.254.150]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.006
x-tm-as-result: No--56.604400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 16:04:55 -0000

Brett suggested the following change in the SDP draft. Any objections?

-acbegen

Current text:

"The connection ("c=3D") and attribute ("a=3D") information in the
 session-level section applies to all the media of that session unless
 overridden by connection information or an attribute of the same name
 in the media description.  For instance, in the example below, each
 media behaves as if it were given a "recvonly" attribute."

Proposed text:

"The connection ("c=3D") and attribute ("a=3D") information in the
 session-level section applies to all the media of that session unless
 overridden by connection information or an attribute of the same name
 or choice in the media description.  For instance, in the example=20
 below, each media behaves as if it were given a "recvonly" attribute.
 If the example had additionally contained a "sendrecv" media-level
 attribute for audio, only the video media would behave as if it were=20
 given a "recvonly" attribute."

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Wednesday, August 08, 2012 7:54 AM
> To: Ali C. Begen (abegen); mmusic@ietf.org
> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
>=20
> > > Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the
> > > following.
> > >
> > > "In general, session-level values are the default for all
> > > media unless overridden by an equivalent media-level value."
> > >
> > > "The connection ("c=3D") and attribute ("a=3D") information
> > > in the session-level section applies to all the media of
> > > that session unless overridden by connection information
> > > or an attribute of the same name in the media description.
> > > For instance, in the example below, each media behaves
> > > as if it were given a "recvonly" attribute."
> > >
> > > If the attributes are related but with different names
> > > (such as "inactive" and "sendrecv"), does the attribute
> > > at the media-level have precedence over the value at the
> > > session-level?  If so, I recommend that the draft be
> > > updated to clarify the topic.
> >
> > I believe so. at least that is my understanding from the
> > text. Does it really need clarification? Thoughts?
>=20
> I think that it should be clarified because it is unclear if "an attribut=
e of the same name" indicates the typical situation or only
> situation concerning application of "unless overridden by an equivalent m=
edia-level value".  For instance if I sent "a=3Dinactive"
> at session-level and "a=3Dsendrecv" at media-level, I'd be concerned that=
 the receiver may interpret the SDP as being
> abnormal (such as including both values at media-level) instead of allowi=
ng "a=3Dsendrecv" to override "a=3Dinactive".
>=20
> In case it matters from an extendibility perspective, requiring the same =
name might make it easier to recognize the override.
> However since section 6 already introduces complications with defaulting =
to "sendrecv" if a new option is defined/used and
> unknown, allowing the override even when the names are not the same doesn=
't make things too much worse; it actually
> allows communication of a backup attribute (such as "a=3Dinactive") if th=
ey don't understand the preferred new attribute (such
> as "a=3Dfoo").
>=20
> "If none of the attributes "sendonly", "recvonly", "inactive",
> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
> default for sessions that are not of the conference type
> "broadcast" or "H332" (see below)."
>=20
> Thanks for the response,
> Brett


From pkyzivat@alum.mit.edu  Mon Aug 27 10:03:59 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B752D21F851E for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 10:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.212
X-Spam-Level: 
X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wqGzbuSUgKh for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 10:03:59 -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 C7D5421F8512 for <mmusic@ietf.org>; Mon, 27 Aug 2012 10:03:58 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id rp7X1j0030QuhwU51t41Ej; Mon, 27 Aug 2012 17:04:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id rt3f1j00h3ZTu2S3Nt3fu0; Mon, 27 Aug 2012 17:03:40 +0000
Message-ID: <503BA87D.10203@alum.mit.edu>
Date: Mon, 27 Aug 2012 13:03:57 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 17:03:59 -0000

I've always thought this should be the way things work, for all 
attributes. But somewhere I came across an attribute (sorry, don't 
remember which one) where the attribute at session level means something 
different than the attribute at media level, and so can't be treated as 
a default for media level. (E.g. the session level is an aggregate limit 
for something, while the media level is a limit for a single m-line.)

Am I just dreaming this? Or can someone identify specific attributes 
that behave this way?

If there are existing attributes that behave this way, then we can't 
make a blanket statement like this. There will need to be an escape 
hatch. For example:

"The connection ("c=") information in the
  session-level section applies to all the media of that session unless
  overridden by connection information
  in the media description.  For instance, in the example
  below, TBD..."

"The attribute ("a=") information in the
  session-level section applies to all the media of that session unless
  overridden by connection information or an attribute of the same name
  or choice in the media description, or the specification of that
  attribute calls for a different treatment.
  For instance, in the example
  below, each media behaves as if it were given a "recvonly" attribute.
  If the example had additionally contained a "sendrecv" media-level
  attribute for audio, only the video media would behave as if it were
  given a "recvonly" attribute."

Even this could have some backward compatibility consequences. I think 
there are some attributes that are only defined for media level. This 
revision would mean that a session level value could override a default 
for media level. Implementations that aren't prepared for that might break.

	Thanks,
	Paul

On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote:
> Brett suggested the following change in the SDP draft. Any objections?
>
> -acbegen
>
> Current text:
>
> "The connection ("c=") and attribute ("a=") information in the
>   session-level section applies to all the media of that session unless
>   overridden by connection information or an attribute of the same name
>   in the media description.  For instance, in the example below, each
>   media behaves as if it were given a "recvonly" attribute."
>
> Proposed text:
>
> "The connection ("c=") and attribute ("a=") information in the
>   session-level section applies to all the media of that session unless
>   overridden by connection information or an attribute of the same name
>   or choice in the media description.  For instance, in the example
>   below, each media behaves as if it were given a "recvonly" attribute.
>   If the example had additionally contained a "sendrecv" media-level
>   attribute for audio, only the video media would behave as if it were
>   given a "recvonly" attribute."
>
>> -----Original Message-----
>> From: Brett Tate [mailto:brett@broadsoft.com]
>> Sent: Wednesday, August 08, 2012 7:54 AM
>> To: Ali C. Begen (abegen); mmusic@ietf.org
>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
>>
>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the
>>>> following.
>>>>
>>>> "In general, session-level values are the default for all
>>>> media unless overridden by an equivalent media-level value."
>>>>
>>>> "The connection ("c=") and attribute ("a=") information
>>>> in the session-level section applies to all the media of
>>>> that session unless overridden by connection information
>>>> or an attribute of the same name in the media description.
>>>> For instance, in the example below, each media behaves
>>>> as if it were given a "recvonly" attribute."
>>>>
>>>> If the attributes are related but with different names
>>>> (such as "inactive" and "sendrecv"), does the attribute
>>>> at the media-level have precedence over the value at the
>>>> session-level?  If so, I recommend that the draft be
>>>> updated to clarify the topic.
>>>
>>> I believe so. at least that is my understanding from the
>>> text. Does it really need clarification? Thoughts?
>>
>> I think that it should be clarified because it is unclear if "an attribute of the same name" indicates the typical situation or only
>> situation concerning application of "unless overridden by an equivalent media-level value".  For instance if I sent "a=inactive"
>> at session-level and "a=sendrecv" at media-level, I'd be concerned that the receiver may interpret the SDP as being
>> abnormal (such as including both values at media-level) instead of allowing "a=sendrecv" to override "a=inactive".
>>
>> In case it matters from an extendibility perspective, requiring the same name might make it easier to recognize the override.
>> However since section 6 already introduces complications with defaulting to "sendrecv" if a new option is defined/used and
>> unknown, allowing the override even when the names are not the same doesn't make things too much worse; it actually
>> allows communication of a backup attribute (such as "a=inactive") if they don't understand the preferred new attribute (such
>> as "a=foo").
>>
>> "If none of the attributes "sendonly", "recvonly", "inactive",
>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
>> default for sessions that are not of the conference type
>> "broadcast" or "H332" (see below)."
>>
>> Thanks for the response,
>> Brett
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From miguel.a.garcia@ericsson.com  Tue Aug 28 01:41:00 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A4121F84A5 for <mmusic@ietfa.amsl.com>; Tue, 28 Aug 2012 01:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.713
X-Spam-Level: 
X-Spam-Status: No, score=-3.713 tagged_above=-999 required=5 tests=[AWL=-2.464, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJodaSJPfW0X for <mmusic@ietfa.amsl.com>; Tue, 28 Aug 2012 01:41:00 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8621F844E for <mmusic@ietf.org>; Tue, 28 Aug 2012 01:40:59 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-26-503c841af440
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 72.8F.25676.A148C305; Tue, 28 Aug 2012 10:40:59 +0200 (CEST)
Received: from [159.107.24.223] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Tue, 28 Aug 2012 10:40:59 +0200
Message-ID: <503C8419.4020806@ericsson.com>
Date: Tue, 28 Aug 2012 10:40:57 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com> <503BA87D.10203@alum.mit.edu>
In-Reply-To: <503BA87D.10203@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvra50i02AQdNMRoupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY3vKQteAWb8Xu39/ZGxgvcHUxcnJICJhI 3Pq+ngnCFpO4cG89WxcjF4eQwClGiT//djNDOGsYJS6f/cUIUsUroC1x6NNNNhCbRUBV4vqv 32BxNgFzidaNG9lBbFGBQInns7ewQ9QLSpyc+YSli5GDQ0RAQ2LSVjWQMLNAsMTlA5NZQGxh AX+Jf0+OMELs2s0k8errDLCLOAW0JK48W88I0WArcWHOdRYIW15i+9s5zCC2kICmxOSbS5kn MArOQrJuFpKWWUhaFjAyr2IUzk3MzEkvN9JLLcpMLi7Oz9MrTt3ECAzWg1t+q+5gvHNO5BCj NAeLkjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYearvLmA5nnlJf8Yq6z1Li4yF /P6cC3IMm9ol/GXX6baWZP+K+8+iDLkZSw9/zjjMHr5L41q0+dv/D2e9NuAqfBiZOm/HLrmv 73uU9Q3jVj0sTG5QXP6g+oxbg1SmWu5xzhP7s3cKXBF20+P6zL5tfXzsn45TDb/tg/h2qXxc Oenncc01TduElFiKMxINtZiLihMBM5tauyQCAAA=
Cc: Alicia Moran <alicia.moran@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2012 08:41:00 -0000

Hi Paul,

perhaps you are thinking of the Bandwidth modifier for SDP, RFC 3890. 
Section 6.2.2. says:

    A new session and media level bandwidth modifier is defined:

       b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.

    The Transport Independent Application Specific Maximum (TIAS)
    bandwidth modifier has an integer bit-rate value in bits per second.
    A fractional bandwidth value SHALL always be rounded up to the next
    integer.  The bandwidth value is the maximum needed by the
    application (SDP session level) or media stream (SDP media level)
    without counting IP or other transport layers like TCP or UDP.

    At the SDP session level, the TIAS value is the maximal amount of
    bandwidth needed when all declared media streams are used.  This MAY
    be less than the sum of all the individual media streams values.
    This is due to the possibility that not all streams have their
    maximum at the same point in time.  This can normally only be
    verified for stored media streams.

Is this the example you were looking for?

/Miguel

On 27/08/2012 19:03, Paul Kyzivat wrote:
> I've always thought this should be the way things work, for all
> attributes. But somewhere I came across an attribute (sorry, don't
> remember which one) where the attribute at session level means something
> different than the attribute at media level, and so can't be treated as
> a default for media level. (E.g. the session level is an aggregate limit
> for something, while the media level is a limit for a single m-line.)
>
> Am I just dreaming this? Or can someone identify specific attributes
> that behave this way?

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From miguel.a.garcia@ericsson.com  Tue Aug 28 01:43:15 2012
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4421F84F7 for <mmusic@ietfa.amsl.com>; Tue, 28 Aug 2012 01:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.618
X-Spam-Level: 
X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-2.369, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gww1sKKs1TCW for <mmusic@ietfa.amsl.com>; Tue, 28 Aug 2012 01:43:15 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62C7521F84F3 for <mmusic@ietf.org>; Tue, 28 Aug 2012 01:43:14 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-d8-503c84a10895
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 76.62.11467.1A48C305; Tue, 28 Aug 2012 10:43:13 +0200 (CEST)
Received: from [159.107.24.223] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Tue, 28 Aug 2012 10:43:12 +0200
Message-ID: <503C849F.6050501@ericsson.com>
Date: Tue, 28 Aug 2012 10:43:11 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com> <503BA87D.10203@alum.mit.edu> <503C8419.4020806@ericsson.com>
In-Reply-To: <503C8419.4020806@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre7CFpsAgy8XFSwebJ/LaDF1+WMW ixUbDrA6MHv8ff+ByWPK742sHkuW/GQKYI7isklJzcksSy3St0vgynh+8CBrwSL+ihsv1jI2 MD7m7mLk4JAQMJFYO8+ii5ETyBSTuHBvPVsXIxeHkMApRokXm69DOWsYJZqP/WEEqeIV0JbY OuUYO4jNIqAqMe3YGbA4m4C5ROvGjWBxUYFAieezt7BD1AtKnJz5hAVkmYiAhsSkrWogYWaB aIn/DVvBSoQF/CX+PTnCCLHrNpNEf/8CNpAEp4COxINTf5kgGmwlLsy5zgJhy0tsfzuHGcQW EtCUmHxzKfMERsFZSNbNQtIyC0nLAkbmVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgeF7cMtv 3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRsizZTT+D+eqb 9yurqn+JznJaojTRxbFJ/hjrzofF02UbuC/odf5QyJ+j9qIl+fafG/sZf55c58mXJ/jLyk4y 5uiDOS8CJzbP/hKu/uaE/uXCLN4D7scu1UZmmkqynlsYcqeKg2OatImwWp3kjtIjqa+qUu4/ nyPE2P76SaX2mv6mSNUs4XYlluKMREMt5qLiRADCeuaBLQIAAA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2012 08:43:16 -0000

Resent. I wanted to include Ali in the discussion, but I failed at first 
time.

/Miguel

On 28/08/2012 10:40, Miguel A. Garcia wrote:
> Hi Paul,
>
> perhaps you are thinking of the Bandwidth modifier for SDP, RFC 3890.
> Section 6.2.2. says:
>
>     A new session and media level bandwidth modifier is defined:
>
>        b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.
>
>     The Transport Independent Application Specific Maximum (TIAS)
>     bandwidth modifier has an integer bit-rate value in bits per second.
>     A fractional bandwidth value SHALL always be rounded up to the next
>     integer.  The bandwidth value is the maximum needed by the
>     application (SDP session level) or media stream (SDP media level)
>     without counting IP or other transport layers like TCP or UDP.
>
>     At the SDP session level, the TIAS value is the maximal amount of
>     bandwidth needed when all declared media streams are used.  This MAY
>     be less than the sum of all the individual media streams values.
>     This is due to the possibility that not all streams have their
>     maximum at the same point in time.  This can normally only be
>     verified for stored media streams.
>
> Is this the example you were looking for?
>
> /Miguel
>
> On 27/08/2012 19:03, Paul Kyzivat wrote:
>> I've always thought this should be the way things work, for all
>> attributes. But somewhere I came across an attribute (sorry, don't
>> remember which one) where the attribute at session level means something
>> different than the attribute at media level, and so can't be treated as
>> a default for media level. (E.g. the session level is an aggregate limit
>> for something, while the media level is a limit for a single m-line.)
>>
>> Am I just dreaming this? Or can someone identify specific attributes
>> that behave this way?
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From pkyzivat@alum.mit.edu  Tue Aug 28 06:12:54 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E626211E80D3 for <mmusic@ietfa.amsl.com>; Tue, 28 Aug 2012 06:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.31
X-Spam-Level: *
X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[AWL=-3.253,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWbeKPzjkr0j for <mmusic@ietfa.amsl.com>; Tue, 28 Aug 2012 06:12:54 -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 DD52D21F845A for <mmusic@ietf.org>; Tue, 28 Aug 2012 06:12:53 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id sD591j0060cZkys5BDCxse; Tue, 28 Aug 2012 13:12:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id sDCu1j00F3ZTu2S3WDCufM; Tue, 28 Aug 2012 13:12:54 +0000
Message-ID: <503CC3D4.9020008@alum.mit.edu>
Date: Tue, 28 Aug 2012 09:12:52 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF526@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994D81B59@xmb-aln-x01.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F6654@EXMBXCLUS01.citservers.local> <C15918F2FCDA0243A7C919DA7C4BE994DCC6B8@xmb-aln-x01.cisco.com> <503BA87D.10203@alum.mit.edu> <503C8419.4020806@ericsson.com> <503C849F.6050501@ericsson.com>
In-Reply-To: <503C849F.6050501@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2012 13:12:55 -0000

While bandwidth has that property, it's not an *attribute*.
I was thinking that there is at least one attribute like that.
But I don't recall a specific one. :-(
It would be good if I'm wrong.

	Thanks,
	Paul

On 8/28/12 4:43 AM, Miguel A. Garcia wrote:
> Resent. I wanted to include Ali in the discussion, but I failed at first
> time.
>
> /Miguel
>
> On 28/08/2012 10:40, Miguel A. Garcia wrote:
>> Hi Paul,
>>
>> perhaps you are thinking of the Bandwidth modifier for SDP, RFC 3890.
>> Section 6.2.2. says:
>>
>>     A new session and media level bandwidth modifier is defined:
>>
>>        b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.
>>
>>     The Transport Independent Application Specific Maximum (TIAS)
>>     bandwidth modifier has an integer bit-rate value in bits per second.
>>     A fractional bandwidth value SHALL always be rounded up to the next
>>     integer.  The bandwidth value is the maximum needed by the
>>     application (SDP session level) or media stream (SDP media level)
>>     without counting IP or other transport layers like TCP or UDP.
>>
>>     At the SDP session level, the TIAS value is the maximal amount of
>>     bandwidth needed when all declared media streams are used.  This MAY
>>     be less than the sum of all the individual media streams values.
>>     This is due to the possibility that not all streams have their
>>     maximum at the same point in time.  This can normally only be
>>     verified for stored media streams.
>>
>> Is this the example you were looking for?
>>
>> /Miguel
>>
>> On 27/08/2012 19:03, Paul Kyzivat wrote:
>>> I've always thought this should be the way things work, for all
>>> attributes. But somewhere I came across an attribute (sorry, don't
>>> remember which one) where the attribute at session level means something
>>> different than the attribute at media level, and so can't be treated as
>>> a default for media level. (E.g. the session level is an aggregate limit
>>> for something, while the media level is a limit for a single m-line.)
>>>
>>> Am I just dreaming this? Or can someone identify specific attributes
>>> that behave this way?
>>
>


From bernard_aboba@hotmail.com  Thu Aug 30 18:30:35 2012
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84A321F8516 for <mmusic@ietfa.amsl.com>; Thu, 30 Aug 2012 18:30:35 -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_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iev4OuFuIBPP for <mmusic@ietfa.amsl.com>; Thu, 30 Aug 2012 18:30:35 -0700 (PDT)
Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id 514AF21F8512 for <mmusic@ietf.org>; Thu, 30 Aug 2012 18:30:34 -0700 (PDT)
Received: from BLU002-W229 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 30 Aug 2012 18:30:32 -0700
Message-ID: <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl>
Content-Type: multipart/alternative; boundary="_05bb94cb-6064-4e3d-9413-2733ebc94c71_"
X-Originating-IP: [72.11.69.66]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 30 Aug 2012 18:30:31 -0700
Importance: Normal
In-Reply-To: <503FDBA1.9000003@alvestrand.no>
References: <503E0B63.3020708@ericsson.com>, , <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <503FDBA1.9000003@alvestrand.no>
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Aug 2012 01:30:32.0295 (UTC) FILETIME=[36432F70:01CD8718]
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 01:30:35 -0000

--_05bb94cb-6064-4e3d-9413-2733ebc94c71_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Harald said:
=0A=

=0A=
I lack the background to think about this... in existing equipment=2C=0A=
    if you want to do SST=2C but would be willing to do MST if the other=0A=
    end did not support SST=2C how would your offer look (without BUNDLE)?
=0A=
=0A=
   =20
=0A=
=0A=
    My head hurts a little when trying to guess=2C but from your question=
=0A=
    it sounds like you've done it=2C so it's better if you just paste an=0A=
    example.
=0A=
=0A=
   =20
=0A=
=0A=
    (BTW=2C this is really an MMUSIC discussion)

[BA] RFC 6190 gives several examples of SST and MST offers:

7.3.1.  Example for Offering a Single SVC Session7.3.2.  Example for Offeri=
ng a Single SVC Session Using scalable-layer-Id7.3.3.  Example for Offering=
 Multiple Sessions in MST7.3.4.  Example for Offering Multiple Sessions in =
MST Including Operation with Answerer Using scalable-layer-id7.3.5.  Exampl=
e for Negotiating an SVC Stream with a Constrained Base Layer in SSTI belie=
ve that the answer to your question is closest to example 7.3.5 (SST) with =
a bit of 7.3.4 (MST) thrown in. Notice that Payload types 97 and 99 are sim=
ilar but not the same (97 is SST=2C 99 is MST):=20

Offer:=20
      a=3Dgroup:DDP L1 L2=0A=
      m=3Dvideo 20000 RTP/AVP 97 96=0A=
      a=3Drtpmap:96 H264-SVC/90000=0A=
      a=3Dfmtp:96 profile-level-id=3D53001e=3B packetization-mode=3D0=3B=0A=
      a=3Drtpmap:97 H264-SVC/90000=0A=
      a=3Dfmtp:97 profile-level-id=3D53001f=3B packetization-mode=3D1=3B
      a=3Dmid:SST
      m=3Dvideo 20002 RTP/AVP 98=0A=
      a=3Drtpmap:98 H264/90000=0A=
      a=3Dfmtp:98 profile-level-id=3D4de00a=3B packetization-mode=3D0=3B=0A=
       mst-mode=3DNI-T=3B=0A=
      a=3Dmid:L1=0A=
      m=3Dvideo 20004 RTP/AVP 99=0A=
      a=3Drtpmap:99 H264-SVC/90000=0A=
      a=3Dfmtp:99 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<2=2C0=2C1=2C0=2C53=
000c=2C=0A=
      3200=2C352=2C288=2C384=2C512>=2C<3=2C1=2C2=2C0=2C53001F=2C6400=2C704=
=2C576=2C768=2C1024>=3B=0A=
      a=3Dmid:L2=0A=
      a=3Ddepend:99 lay L1:98

On 08/30/2012 11:19 PM=2C Bernard Aboba=0A=
      wrote:
=0A=
    =0A=
    =0A=
      =0A=
      Harald said:=20
=0A=
       =20
=0A=
        > My assumption has always been that if you were=0A=
          operating on a network=20
=0A=
          > that could only apply diffserv to separate 5-tuples=2C you=0A=
          would allocate=20
=0A=
          > the SSRCs comprising a multilayer encoding to different=0A=
          5-tuples.
=0A=
         =20
=0A=
          [BA] RFC 6190 Section 1 says:
=0A=
         =20
=0A=
             This memo defines two basic modes for transmission of SVC data=
=2C=0A=
   single-session transmission (SST) and multi-session transmission=0A=
   (MST).  In SST=2C a single RTP session is used for the transmission of=
=0A=
   all scalability layers comprising an SVC bitstream=3B in MST=2C the=0A=
   scalability layers are transported on different RTP sessions.  =0A=
         =20
=0A=
          [BA] So it is possible either to use multiple 5-tuples (MST)=0A=
          or a single 5-tuple (SST).  However=2C my understanding=20
=0A=
          is that the SST approach is more popular than MST.=20
=0A=
         =20
=0A=
          > This choice seems to be a choice that the application=0A=
          writer should take=20
=0A=
          > before deciding whether or not to use BUNDLE=2C so it's a=0A=
          little hard to=20
=0A=
          > see what the relationship to BUNDLE is.
=0A=
         =20
=0A=
          [BA] The open question has been how to indicate the desire for=0A=
          both layered coding and BUNDLE in SDP=2C=20
=0A=
          given the backward compatibility issues we have talked about. =0A=
          For example=2C if it is desired to do SST and
=0A=
          BUNDLE=2C do you signal MST and BUNDLE on different ports in the=
=0A=
          offer and then if SST and BUNDLE are
=0A=
          supported by the answer=2C have the answer respond with BUNDLE=0A=
          as well as dependency groups using=20
=0A=
          the same port?  That would seem to imply an assumption that=0A=
          every MST implementation can also do SST. =20
=0A=
          Or do do you signal SST and BUNDLE on the same port=2C and then=
=0A=
          if the response indicates that the SDP
=0A=
          was rejected=2C formulate an alternative offer (MST with=0A=
          BUNDLE?  H.264/AVC with BUNDLE?=20
=0A=
          SST without BUNDLE??) =20
=0A=
        =0A=
      =0A=
    =0A=
   =20
=0A=
   =20
 		 	   		  =

--_05bb94cb-6064-4e3d-9413-2733ebc94c71_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>Harald said:<br>=0A=
<br>=0A=
I lack the background to think about this... in existing equipment=2C=0A=
    if you want to do SST=2C but would be willing to do MST if the other=0A=
    end did not support SST=2C how would your offer look (without BUNDLE)?<=
br>=0A=
=0A=
    <br>=0A=
=0A=
    My head hurts a little when trying to guess=2C but from your question=
=0A=
    it sounds like you've done it=2C so it's better if you just paste an=0A=
    example.<br>=0A=
=0A=
    <br>=0A=
=0A=
    (BTW=2C this is really an MMUSIC discussion)<br><br>[BA] RFC 6190 gives=
 several examples of SST and MST offers:<br><br><pre class=3D"newpage"><spa=
n class=3D"h4"><h4><a class=3D"selflink" name=3D"section-7.3.1" href=3D"htt=
p://tools.ietf.org/html/rfc6190#section-7.3.1">7.3.1</a>.  Example for Offe=
ring a Single SVC Session</h4></span><pre class=3D"newpage"><span class=3D"=
h4"><h4><a class=3D"selflink" name=3D"section-7.3.2" href=3D"http://tools.i=
etf.org/html/rfc6190#section-7.3.2">7.3.2</a>.  Example for Offering a Sing=
le SVC Session Using scalable-layer-Id</h4></span><pre class=3D"newpage"><s=
pan class=3D"h4"><h4><a class=3D"selflink" name=3D"section-7.3.3" href=3D"h=
ttp://tools.ietf.org/html/rfc6190#section-7.3.3">7.3.3</a>.  Example for Of=
fering Multiple Sessions in MST</h4></span><pre class=3D"newpage"><span cla=
ss=3D"h4"><h4><a class=3D"selflink" name=3D"section-7.3.4" href=3D"http://t=
ools.ietf.org/html/rfc6190#section-7.3.4">7.3.4</a>.  Example for Offering =
Multiple Sessions in MST Including Operation with Answerer Using scalable-l=
ayer-id</h4></span><pre class=3D"newpage"><span class=3D"h4"><h4><a class=
=3D"selflink" name=3D"section-7.3.5" href=3D"http://tools.ietf.org/html/rfc=
6190#section-7.3.5">7.3.5</a>.  Example for Negotiating an SVC Stream with =
a Constrained Base Layer in SST</h4></span></pre><span class=3D"h4"></span>=
</pre><span class=3D"h4"></span></pre><span class=3D"h4"></span></pre><span=
 class=3D"h4"></span></pre>I believe that the answer to your question is cl=
osest to example 7.3.5 (SST) with a bit of 7.3.4 (MST) thrown in. Notice th=
at Payload types 97 and 99 are similar but not the same (97 is SST=2C 99 is=
 MST): <br><br>Offer: <br><pre class=3D"newpage">      a=3Dgroup:DDP L1 L2=
=0A=
      m=3Dvideo 20000 RTP/AVP 97 96=0A=
      a=3Drtpmap:96 H264-SVC/90000=0A=
      a=3Dfmtp:96 profile-level-id=3D53001e=3B packetization-mode=3D0=3B=0A=
      a=3Drtpmap:97 H264-SVC/90000=0A=
      a=3Dfmtp:97 profile-level-id=3D53001f=3B packetization-mode=3D1=3B<br=
>      a=3Dmid:SST<br>      m=3Dvideo 20002 RTP/AVP 98=0A=
      a=3Drtpmap:98 H264/90000=0A=
      a=3Dfmtp:98 profile-level-id=3D4de00a=3B packetization-mode=3D0=3B=0A=
       mst-mode=3DNI-T=3B=0A=
      a=3Dmid:L1=0A=
      m=3Dvideo 20004 RTP/AVP 99=0A=
      a=3Drtpmap:99 H264-SVC/90000=0A=
      a=3Dfmtp:99 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D&lt=3B2=2C0=2C1=2C0=
=2C53000c=2C=0A=
      3200=2C352=2C288=2C384=2C512&gt=3B=2C&lt=3B3=2C1=2C2=2C0=2C53001F=2C6=
400=2C704=2C576=2C768=2C1024&gt=3B=3B=0A=
      a=3Dmid:L2=0A=
      a=3Ddepend:99 lay L1:98<br></pre><br><div><div class=3D"ecxmoz-cite-p=
refix">On 08/30/2012 11:19 PM=2C Bernard Aboba=0A=
      wrote:<br>=0A=
    </div>=0A=
    <blockquote cite=3D"mid:BLU002-W2102260755F0099C2AA98E93A70@phx.gbl">=
=0A=
      <style><!--=0A=
.ExternalClass .ecxhmmessage P=0A=
{padding:0px=3B}=0A=
.ExternalClass body.ecxhmmessage=0A=
{font-size:12pt=3Bfont-family:Calibri=3B}=0A=
=0A=
--></style>=0A=
      <div dir=3D"ltr">Harald said: <br>=0A=
        <br>=0A=
        <div>&gt=3B My assumption has always been that if you were=0A=
          operating on a network <br>=0A=
          &gt=3B that could only apply diffserv to separate 5-tuples=2C you=
=0A=
          would allocate <br>=0A=
          &gt=3B the SSRCs comprising a multilayer encoding to different=0A=
          5-tuples.<br>=0A=
          <br>=0A=
          [BA] RFC 6190 Section 1 says:<br>=0A=
          <br>=0A=
          <pre class=3D"ecxnewpage">   This memo defines two basic modes fo=
r transmission of SVC data=2C=0A=
   single-session transmission (SST) and multi-session transmission=0A=
   (MST).  In SST=2C a single RTP session is used for the transmission of=
=0A=
   all scalability layers comprising an SVC bitstream=3B in MST=2C the=0A=
   scalability layers are transported on different RTP sessions.  </pre>=0A=
          <br>=0A=
          [BA] So it is possible either to use multiple 5-tuples (MST)=0A=
          or a single 5-tuple (SST).&nbsp=3B However=2C my understanding <b=
r>=0A=
          is that the SST approach is more popular than MST. <br>=0A=
          <br>=0A=
          &gt=3B This choice seems to be a choice that the application=0A=
          writer should take <br>=0A=
          &gt=3B before deciding whether or not to use BUNDLE=2C so it's a=
=0A=
          little hard to <br>=0A=
          &gt=3B see what the relationship to BUNDLE is.<br>=0A=
          <br>=0A=
          [BA] The open question has been how to indicate the desire for=0A=
          both layered coding and BUNDLE in SDP=2C <br>=0A=
          given the backward compatibility issues we have talked about.&nbs=
p=3B=0A=
          For example=2C if it is desired to do SST and<br>=0A=
          BUNDLE=2C do you signal MST and BUNDLE on different ports in the=
=0A=
          offer and then if SST and BUNDLE are<br>=0A=
          supported by the answer=2C have the answer respond with BUNDLE=0A=
          as well as dependency groups using <br>=0A=
          the same port?&nbsp=3B That would seem to imply an assumption tha=
t=0A=
          every MST implementation can also do SST.&nbsp=3B <br>=0A=
          Or do do you signal SST and BUNDLE on the same port=2C and then=
=0A=
          if the response indicates that the SDP<br>=0A=
          was rejected=2C formulate an alternative offer (MST with=0A=
          BUNDLE?&nbsp=3B H.264/AVC with BUNDLE? <br>=0A=
          SST without BUNDLE??)&nbsp=3B <br>=0A=
        </div>=0A=
      </div>=0A=
    </blockquote>=0A=
    <br>=0A=
    <br></div> 		 	   		  </div></body>
</html>=

--_05bb94cb-6064-4e3d-9413-2733ebc94c71_--

From harald@alvestrand.no  Thu Aug 30 23:13:07 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2377621F845F for <mmusic@ietfa.amsl.com>; Thu, 30 Aug 2012 23:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.058
X-Spam-Level: 
X-Spam-Status: No, score=-110.058 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8Dr2yadljfA for <mmusic@ietfa.amsl.com>; Thu, 30 Aug 2012 23:13:06 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 84BEA21F845B for <mmusic@ietf.org>; Thu, 30 Aug 2012 23:13:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9D97739E0CE; Fri, 31 Aug 2012 08:13:04 +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 fyyo4QxPo0-F; Fri, 31 Aug 2012 08:13:03 +0200 (CEST)
Received: from [192.168.11.107] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EE4A639E020; Fri, 31 Aug 2012 08:13:02 +0200 (CEST)
Message-ID: <504055EF.5070300@alvestrand.no>
Date: Fri, 31 Aug 2012 08:13:03 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <503E0B63.3020708@ericsson.com>, , <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <503FDBA1.9000003@alvestrand.no> <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl>
In-Reply-To: <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl>
Content-Type: multipart/alternative; boundary="------------080204050604000100080005"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 06:13:07 -0000

This is a multi-part message in MIME format.
--------------080204050604000100080005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/31/2012 03:30 AM, Bernard Aboba wrote:
> Harald said:
>
> I lack the background to think about this... in existing equipment, if 
> you want to do SST, but would be willing to do MST if the other end 
> did not support SST, how would your offer look (without BUNDLE)?
>
> My head hurts a little when trying to guess, but from your question it 
> sounds like you've done it, so it's better if you just paste an example.
>
> (BTW, this is really an MMUSIC discussion)
>
> [BA] RFC 6190 gives several examples of SST and MST offers:
>
>
>         7.3.1 <http://tools.ietf.org/html/rfc6190#section-7.3.1>.
>         Example for Offering a Single SVC Session
>
>
>         7.3.2 <http://tools.ietf.org/html/rfc6190#section-7.3.2>.
>         Example for Offering a Single SVC Session Using scalable-layer-Id
>
>
>         7.3.3 <http://tools.ietf.org/html/rfc6190#section-7.3.3>.
>         Example for Offering Multiple Sessions in MST
>
>
>         7.3.4 <http://tools.ietf.org/html/rfc6190#section-7.3.4>.
>         Example for Offering Multiple Sessions in MST Including
>         Operation with Answerer Using scalable-layer-id
>
>
>         7.3.5 <http://tools.ietf.org/html/rfc6190#section-7.3.5>.
>         Example for Negotiating an SVC Stream with a Constrained Base
>         Layer in SST
>
> I believe that the answer to your question is closest to example 7.3.5 
> (SST) with a bit of 7.3.4 (MST) thrown in. Notice that Payload types 
> 97 and 99 are similar but not the same (97 is SST, 99 is MST):
Aha - so you'd send 3 video M-lines, an SST-only application would zero 
out the second and third, while an MST-only application would zero out 
the first, and one capable of doing both would accept all 3? and one 
could look at the payload type (96/97 vs 98 or 99) to decide which one a 
particular video stream belonged to?

It makes no sense (to my mind at least) to multiplex L1 and L2 together, 
but one could multiplex SST with L1 and save one port in the "both are 
supported" case:

a=group:BUNDLE SST L1

I think this would create sessions that would not create an unsolvable 
problem; if all were accepted, the decoder would have to look at the 
payload type of the first packet on an SSRC to figure out whether a 
particular SSRC was using SST or MST for that particular payload.
>
> Offer:
>        a=group:DDP L1 L2
>        m=video 20000 RTP/AVP 97 96
>        a=rtpmap:96 H264-SVC/90000
>        a=fmtp:96 profile-level-id=53001e; packetization-mode=0;
>        a=rtpmap:97 H264-SVC/90000
>        a=fmtp:97 profile-level-id=53001f; packetization-mode=1;
>        a=mid:SST
>        m=video 20002 RTP/AVP 98
>        a=rtpmap:98 H264/90000
>        a=fmtp:98 profile-level-id=4de00a; packetization-mode=0;
>         mst-mode=NI-T;
>        a=mid:L1
>        m=video 20004 RTP/AVP 99
>        a=rtpmap:99 H264-SVC/90000
>        a=fmtp:99 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>        a=mid:L2
>        a=depend:99 lay L1:98
>
> On 08/30/2012 11:19 PM, Bernard Aboba wrote:
>
>     Harald said:
>
>     > My assumption has always been that if you were operating on a
>     network
>     > that could only apply diffserv to separate 5-tuples, you would
>     allocate
>     > the SSRCs comprising a multilayer encoding to different 5-tuples.
>
>     [BA] RFC 6190 Section 1 says:
>
>         This memo defines two basic modes for transmission of SVC data,
>         single-session transmission (SST) and multi-session transmission
>         (MST).  In SST, a single RTP session is used for the transmission of
>         all scalability layers comprising an SVC bitstream; in MST, the
>         scalability layers are transported on different RTP sessions.
>
>
>     [BA] So it is possible either to use multiple 5-tuples (MST) or a
>     single 5-tuple (SST).  However, my understanding
>     is that the SST approach is more popular than MST.
>
>     > This choice seems to be a choice that the application writer
>     should take
>     > before deciding whether or not to use BUNDLE, so it's a little
>     hard to
>     > see what the relationship to BUNDLE is.
>
>     [BA] The open question has been how to indicate the desire for
>     both layered coding and BUNDLE in SDP,
>     given the backward compatibility issues we have talked about.  For
>     example, if it is desired to do SST and
>     BUNDLE, do you signal MST and BUNDLE on different ports in the
>     offer and then if SST and BUNDLE are
>     supported by the answer, have the answer respond with BUNDLE as
>     well as dependency groups using
>     the same port?  That would seem to imply an assumption that every
>     MST implementation can also do SST.
>     Or do do you signal SST and BUNDLE on the same port, and then if
>     the response indicates that the SDP
>     was rejected, formulate an alternative offer (MST with BUNDLE? 
>     H.264/AVC with BUNDLE?
>     SST without BUNDLE??)
>
>
>


--------------080204050604000100080005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/31/2012 03:30 AM, Bernard Aboba
      wrote:<br>
    </div>
    <blockquote cite="mid:BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl"
      type="cite">
      <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
      <div dir="ltr">Harald said:<br>
        <br>
        I lack the background to think about this... in existing
        equipment, if you want to do SST, but would be willing to do MST
        if the other end did not support SST, how would your offer look
        (without BUNDLE)?<br>
        <br>
        My head hurts a little when trying to guess, but from your
        question it sounds like you've done it, so it's better if you
        just paste an example.<br>
        <br>
        (BTW, this is really an MMUSIC discussion)<br>
        <br>
        [BA] RFC 6190 gives several examples of SST and MST offers:<br>
        <br>
        <pre class="newpage"><span class="h4"><h4><a moz-do-not-send="true" class="selflink" name="section-7.3.1" href="http://tools.ietf.org/html/rfc6190#section-7.3.1">7.3.1</a>.  Example for Offering a Single SVC Session</h4></span><pre class="newpage"><span class="h4"><h4><a moz-do-not-send="true" class="selflink" name="section-7.3.2" href="http://tools.ietf.org/html/rfc6190#section-7.3.2">7.3.2</a>.  Example for Offering a Single SVC Session Using scalable-layer-Id</h4></span><pre class="newpage"><span class="h4"><h4><a moz-do-not-send="true" class="selflink" name="section-7.3.3" href="http://tools.ietf.org/html/rfc6190#section-7.3.3">7.3.3</a>.  Example for Offering Multiple Sessions in MST</h4></span><pre class="newpage"><span class="h4"><h4><a moz-do-not-send="true" class="selflink" name="section-7.3.4" href="http://tools.ietf.org/html/rfc6190#section-7.3.4">7.3.4</a>.  Example for Offering Multiple Sessions in MST Including Operation with Answerer Using scalable-laye
 r-id</h4
 >
</span><pre class="newpage"><span class="h4"><h4><a moz-do-not-send="true" class="selflink" name="section-7.3.5" href="http://tools.ietf.org/html/rfc6190#section-7.3.5">7.3.5</a>.  Example for Negotiating an SVC Stream with a Constrained Base Layer in SST</h4></span></pre><span class="h4"></span></pre><span class="h4"></span></pre><span class="h4"></span></pre><span class="h4"></span></pre>
        I believe that the answer to your question is closest to example
        7.3.5 (SST) with a bit of 7.3.4 (MST) thrown in. Notice that
        Payload types 97 and 99 are similar but not the same (97 is SST,
        99 is MST): <br>
      </div>
    </blockquote>
    Aha - so you'd send 3 video M-lines, an SST-only application would
    zero out the second and third, while an MST-only application would
    zero out the first, and one capable of doing both would accept all
    3? and one could look at the payload type (96/97 vs 98 or 99) to
    decide which one a particular video stream belonged to?<br>
    <br>
    It makes no sense (to my mind at least) to multiplex L1 and L2
    together, but one could multiplex SST with L1 and save one port in
    the "both are supported" case:<br>
    <br>
    a=group:BUNDLE SST L1<br>
    <br>
    I think this would create sessions that would not create an
    unsolvable problem; if all were accepted, the decoder would have to
    look at the payload type of the first packet on an SSRC to figure
    out whether a particular SSRC was using SST or MST for that
    particular payload.<br>
    <blockquote cite="mid:BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl"
      type="cite">
      <div dir="ltr"><br>
        Offer: <br>
        <pre class="newpage">      a=group:DDP L1 L2
      m=video 20000 RTP/AVP 97 96
      a=rtpmap:96 H264-SVC/90000
      a=fmtp:96 profile-level-id=53001e; packetization-mode=0;
      a=rtpmap:97 H264-SVC/90000
      a=fmtp:97 profile-level-id=53001f; packetization-mode=1;
      a=mid:SST
      m=video 20002 RTP/AVP 98
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=4de00a; packetization-mode=0;
       mst-mode=NI-T;
      a=mid:L1
      m=video 20004 RTP/AVP 99
      a=rtpmap:99 H264-SVC/90000
      a=fmtp:99 profile-level-id=53001F; packetization-mode=1;
       mst-mode=NI-TC; sprop-operation-point-info=&lt;2,0,1,0,53000c,
      3200,352,288,384,512&gt;,&lt;3,1,2,0,53001F,6400,704,576,768,1024&gt;;
      a=mid:L2
      a=depend:99 lay L1:98
</pre>
        <br>
        <div>
          <div class="ecxmoz-cite-prefix">On 08/30/2012 11:19 PM,
            Bernard Aboba wrote:<br>
          </div>
          <blockquote
            cite="mid:BLU002-W2102260755F0099C2AA98E93A70@phx.gbl">
            <style><!--
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:12pt;font-family:Calibri;}

--></style>
            <div dir="ltr">Harald said: <br>
              <br>
              <div>&gt; My assumption has always been that if you were
                operating on a network <br>
                &gt; that could only apply diffserv to separate
                5-tuples, you would allocate <br>
                &gt; the SSRCs comprising a multilayer encoding to
                different 5-tuples.<br>
                <br>
                [BA] RFC 6190 Section 1 says:<br>
                <br>
                <pre class="ecxnewpage">   This memo defines two basic modes for transmission of SVC data,
   single-session transmission (SST) and multi-session transmission
   (MST).  In SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstream; in MST, the
   scalability layers are transported on different RTP sessions.  </pre>
                <br>
                [BA] So it is possible either to use multiple 5-tuples
                (MST) or a single 5-tuple (SST).&nbsp; However, my
                understanding <br>
                is that the SST approach is more popular than MST. <br>
                <br>
                &gt; This choice seems to be a choice that the
                application writer should take <br>
                &gt; before deciding whether or not to use BUNDLE, so
                it's a little hard to <br>
                &gt; see what the relationship to BUNDLE is.<br>
                <br>
                [BA] The open question has been how to indicate the
                desire for both layered coding and BUNDLE in SDP, <br>
                given the backward compatibility issues we have talked
                about.&nbsp; For example, if it is desired to do SST and<br>
                BUNDLE, do you signal MST and BUNDLE on different ports
                in the offer and then if SST and BUNDLE are<br>
                supported by the answer, have the answer respond with
                BUNDLE as well as dependency groups using <br>
                the same port?&nbsp; That would seem to imply an assumption
                that every MST implementation can also do SST.&nbsp; <br>
                Or do do you signal SST and BUNDLE on the same port, and
                then if the response indicates that the SDP<br>
                was rejected, formulate an alternative offer (MST with
                BUNDLE?&nbsp; H.264/AVC with BUNDLE? <br>
                SST without BUNDLE??)&nbsp; <br>
              </div>
            </div>
          </blockquote>
          <br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------080204050604000100080005--

From christer.holmberg@ericsson.com  Fri Aug 31 01:53:57 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84F21F8501 for <mmusic@ietfa.amsl.com>; Fri, 31 Aug 2012 01:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.572
X-Spam-Level: 
X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOGJJ8TdwEve for <mmusic@ietfa.amsl.com>; Fri, 31 Aug 2012 01:53:52 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2241921F84FD for <mmusic@ietf.org>; Fri, 31 Aug 2012 01:53:51 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-c0-50407b9d1bd8
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 64.BB.25676.D9B70405; Fri, 31 Aug 2012 10:53:50 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 31 Aug 2012 10:53:49 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>, Bernard Aboba <bernard_aboba@hotmail.com>
Date: Fri, 31 Aug 2012 10:53:48 +0200
Thread-Topic: [MMUSIC] H.264 SVC and BUNDLE
Thread-Index: Ac2HP7LkeXQkgNcnSXaMAq1DNJBrngADk32g
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se>
References: <503E0B63.3020708@ericsson.com>, , <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <503FDBA1.9000003@alvestrand.no> <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl> <504055EF.5070300@alvestrand.no>
In-Reply-To: <504055EF.5070300@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92ESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvre68aocAg68neS32L7nMbHGsr4vN YuryxywOzB5XJlxh9Xjcc4bNY8mSn0wBzFFcNimpOZllqUX6dglcGS/3d7IVzJnCWNHe+5Gx gXFqA2MXIyeHhICJxLMFB1kgbDGJC/fWs3UxcnEICZxilJj0eSUzhLOAUeLwt1tAHRwcbAIW Et3/tEEaRAQiJW48PcoMEmYWUJe4ujgIJMwioCqx6dN1JhBbWEBLYmPHYyaIcm2J35+6GCFs I4mbK48xg9i8AuESa3oWsECsmsAi8W7PabAEp4CuRNO2RrAGRqDjvp9aAzaIWUBc4taT+UwQ RwtILNlznhnCFpV4+fgfK0S9qMSd9vWMEPX5EleWXWKCWCYocXLmE5YJjKKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRODcxMye93EgvtSgzubg4P0+vOHUTIzAG D275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgVO3fvvrt PTnf+C9p5ZMmT3/mc09itsQnh5l7Hih+YGYp14ite+/JEJgdEdpwb0Hghwq3J/whby+KMC3d d7lN5Y9b84KlE1J/zvFp5781o1JcWqeQbeLb8pn1i8TznrBVLxUt2b/o+u1HUQ9SWEMXyfhe yJ1b2/fLQpBxX9oUlidhXDfm7Pa/osRSnJFoqMVcVJwIADgztGqPAgAA
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 08:53:57 -0000

--_000_7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92ESESSCMS0356e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,

One question is of course whether we are going to move ahead with the m=3Db=
undle proposal. In that case, I guess the m=3Dvideo lines would look like t=
hey do today, and the question is how we describe the multiplexed SVC withi=
n the m=3Dbundle line.

Regards,

Christer




From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: 31. elokuuta 2012 9:13
To: Bernard Aboba
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE

On 08/31/2012 03:30 AM, Bernard Aboba wrote:
Harald said:

I lack the background to think about this... in existing equipment, if you =
want to do SST, but would be willing to do MST if the other end did not sup=
port SST, how would your offer look (without BUNDLE)?

My head hurts a little when trying to guess, but from your question it soun=
ds like you've done it, so it's better if you just paste an example.

(BTW, this is really an MMUSIC discussion)

[BA] RFC 6190 gives several examples of SST and MST offers:
7.3.1<http://tools.ietf.org/html/rfc6190#section-7.3.1>.  Example for Offer=
ing a Single SVC Session
7.3.2<http://tools.ietf.org/html/rfc6190#section-7.3.2>.  Example for Offer=
ing a Single SVC Session Using scalable-layer-Id
7.3.3<http://tools.ietf.org/html/rfc6190#section-7.3.3>.  Example for Offer=
ing Multiple Sessions in MST
7.3.4<http://tools.ietf.org/html/rfc6190#section-7.3.4>.  Example for Offer=
ing Multiple Sessions in MST Including Operation with Answerer Using scalab=
le-laye
r-id



7.3.5<http://tools.ietf.org/html/rfc6190#section-7.3.5>.  Example for Negot=
iating an SVC Stream with a Constrained Base Layer in SST
I believe that the answer to your question is closest to example 7.3.5 (SST=
) with a bit of 7.3.4 (MST) thrown in. Notice that Payload types 97 and 99 =
are similar but not the same (97 is SST, 99 is MST):
Aha - so you'd send 3 video M-lines, an SST-only application would zero out=
 the second and third, while an MST-only application would zero out the fir=
st, and one capable of doing both would accept all 3? and one could look at=
 the payload type (96/97 vs 98 or 99) to decide which one a particular vide=
o stream belonged to?

It makes no sense (to my mind at least) to multiplex L1 and L2 together, bu=
t one could multiplex SST with L1 and save one port in the "both are suppor=
ted" case:

a=3Dgroup:BUNDLE SST L1

I think this would create sessions that would not create an unsolvable prob=
lem; if all were accepted, the decoder would have to look at the payload ty=
pe of the first packet on an SSRC to figure out whether a particular SSRC w=
as using SST or MST for that particular payload.


Offer:

      a=3Dgroup:DDP L1 L2

      m=3Dvideo 20000 RTP/AVP 97 96

      a=3Drtpmap:96 H264-SVC/90000

      a=3Dfmtp:96 profile-level-id=3D53001e; packetization-mode=3D0;

      a=3Drtpmap:97 H264-SVC/90000

      a=3Dfmtp:97 profile-level-id=3D53001f; packetization-mode=3D1;

      a=3Dmid:SST

      m=3Dvideo 20002 RTP/AVP 98

      a=3Drtpmap:98 H264/90000

      a=3Dfmtp:98 profile-level-id=3D4de00a; packetization-mode=3D0;

       mst-mode=3DNI-T;

      a=3Dmid:L1

      m=3Dvideo 20004 RTP/AVP 99

      a=3Drtpmap:99 H264-SVC/90000

      a=3Dfmtp:99 profile-level-id=3D53001F; packetization-mode=3D1;

       mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,53000c,

      3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;

      a=3Dmid:L2

      a=3Ddepend:99 lay L1:98

On 08/30/2012 11:19 PM, Bernard Aboba wrote:
Harald said:
> My assumption has always been that if you were operating on a network
> that could only apply diffserv to separate 5-tuples, you would allocate
> the SSRCs comprising a multilayer encoding to different 5-tuples.

[BA] RFC 6190 Section 1 says:

   This memo defines two basic modes for transmission of SVC data,

   single-session transmission (SST) and multi-session transmission

   (MST).  In SST, a single RTP session is used for the transmission of

   all scalability layers comprising an SVC bitstream; in MST, the

   scalability layers are transported on different RTP sessions.

[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-=
tuple (SST).  However, my understanding
is that the SST approach is more popular than MST.

> This choice seems to be a choice that the application writer should take
> before deciding whether or not to use BUNDLE, so it's a little hard to
> see what the relationship to BUNDLE is.

[BA] The open question has been how to indicate the desire for both layered=
 coding and BUNDLE in SDP,
given the backward compatibility issues we have talked about.  For example,=
 if it is desired to do SST and
BUNDLE, do you signal MST and BUNDLE on different ports in the offer and th=
en if SST and BUNDLE are
supported by the answer, have the answer respond with BUNDLE as well as dep=
endency groups using
the same port?  That would seem to imply an assumption that every MST imple=
mentation can also do SST.
Or do do you signal SST and BUNDLE on the same port, and then if the respon=
se indicates that the SDP
was rejected, formulate an alternative offer (MST with BUNDLE?  H.264/AVC w=
ith BUNDLE?
SST without BUNDLE??)



--_000_7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92ESESSCMS0356e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
h4
	{mso-style-priority:9;
	mso-style-link:"Heading 4 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.h4
	{mso-style-name:h4;}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;
	font-style:italic;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite lang=3DEN-US=
 link=3Dblue vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>=
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1=
F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font=
-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi,<o:p></o:=
p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p cla=
ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-=
serif";color:#1F497D'>One question is of course whether we are going to mov=
e ahead with the m=3Dbundle proposal. In that case, I guess the m=3Dvideo l=
ines would look like they do today, and the question is how we describe the=
 multiplexed SVC within the m=3Dbundle line.<o:p></o:p></span></p><p class=
=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-se=
rif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
>Regards,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-siz=
e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-famil=
y:"Calibri","sans-serif";color:#1F497D'>Christer<o:p></o:p></span></p><p cl=
ass=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans=
-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><sp=
an style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F49=
7D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-si=
ze:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:=
p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><=
div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0=
cm 0cm'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family=
:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style=3D'fon=
t-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> mmusic-b=
ounces@ietf.org [mailto:mmusic-bounces@ietf.org] <b>On Behalf Of </b>Harald=
 Alvestrand<br><b>Sent:</b> 31. elokuuta 2012 9:13<br><b>To:</b> Bernard Ab=
oba<br><b>Cc:</b> mmusic@ietf.org<br><b>Subject:</b> Re: [MMUSIC] H.264 SVC=
 and BUNDLE<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbs=
p;</o:p></p><div><p class=3DMsoNormal>On 08/31/2012 03:30 AM, Bernard Aboba=
 wrote:<o:p></o:p></p></div><blockquote style=3D'margin-top:5.0pt;margin-bo=
ttom:5.0pt'><div><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Harald=
 said:<br><br>I lack the background to think about this... in existing equi=
pment, if you want to do SST, but would be willing to do MST if the other e=
nd did not support SST, how would your offer look (without BUNDLE)?<br><br>=
My head hurts a little when trying to guess, but from your question it soun=
ds like you've done it, so it's better if you just paste an example.<br><br=
>(BTW, this is really an MMUSIC discussion)<br><br>[BA] RFC 6190 gives seve=
ral examples of SST and MST offers:<o:p></o:p></p><h4><a name=3Dsection-7.3=
.1></a><a href=3D"http://tools.ietf.org/html/rfc6190#section-7.3.1"><span s=
tyle=3D'font-family:"Courier New"'>7.3.1</span></a><span style=3D'font-fami=
ly:"Courier New"'>.&nbsp; Example for Offering a Single SVC Session<o:p></o=
:p></span></h4><h4><a name=3Dsection-7.3.2></a><a href=3D"http://tools.ietf=
.org/html/rfc6190#section-7.3.2"><span style=3D'font-family:"Courier New"'>=
7.3.2</span></a><span style=3D'font-family:"Courier New"'>.&nbsp; Example f=
or Offering a Single SVC Session Using scalable-layer-Id<o:p></o:p></span><=
/h4><h4><a name=3Dsection-7.3.3></a><a href=3D"http://tools.ietf.org/html/r=
fc6190#section-7.3.3"><span style=3D'font-family:"Courier New"'>7.3.3</span=
></a><span style=3D'font-family:"Courier New"'>.&nbsp; Example for Offering=
 Multiple Sessions in MST<o:p></o:p></span></h4><h4><a name=3Dsection-7.3.4=
></a><a href=3D"http://tools.ietf.org/html/rfc6190#section-7.3.4"><span sty=
le=3D'font-family:"Courier New"'>7.3.4</span></a><span style=3D'font-family=
:"Courier New"'>.&nbsp; Example for Offering Multiple Sessions in MST Inclu=
ding Operation with Answerer Using scalable-laye<o:p></o:p></span></h4><h4>=
<span style=3D'font-family:"Courier New"'> r-id<o:p></o:p></span></h4><pre>=
<span class=3Dh4><o:p>&nbsp;</o:p></span></pre><h4><a name=3Dsection-7.3.5>=
</a><a href=3D"http://tools.ietf.org/html/rfc6190#section-7.3.5"><span styl=
e=3D'font-family:"Courier New"'>7.3.5</span></a><span style=3D'font-family:=
"Courier New"'>.&nbsp; Example for Negotiating an SVC Stream with a Constra=
ined Base Layer in SST<o:p></o:p></span></h4><p class=3DMsoNormal>I believe=
 that the answer to your question is closest to example 7.3.5 (SST) with a =
bit of 7.3.4 (MST) thrown in. Notice that Payload types 97 and 99 are simil=
ar but not the same (97 is SST, 99 is MST): <o:p></o:p></p></div></blockquo=
te><p class=3DMsoNormal>Aha - so you'd send 3 video M-lines, an SST-only ap=
plication would zero out the second and third, while an MST-only applicatio=
n would zero out the first, and one capable of doing both would accept all =
3? and one could look at the payload type (96/97 vs 98 or 99) to decide whi=
ch one a particular video stream belonged to?<br><br>It makes no sense (to =
my mind at least) to multiplex L1 and L2 together, but one could multiplex =
SST with L1 and save one port in the &quot;both are supported&quot; case:<b=
r><br>a=3Dgroup:BUNDLE SST L1<br><br>I think this would create sessions tha=
t would not create an unsolvable problem; if all were accepted, the decoder=
 would have to look at the payload type of the first packet on an SSRC to f=
igure out whether a particular SSRC was using SST or MST for that particula=
r payload.<br><br><o:p></o:p></p><div><p class=3DMsoNormal><br>Offer: <o:p>=
</o:p></p><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=3Dgroup:DDP L1 L2<o:p>=
</o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m=3Dvideo 20000 RTP/AVP 97 =
96<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Drtpmap:96 H264-S=
VC/90000<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Dfmtp:96 pr=
ofile-level-id=3D53001e; packetization-mode=3D0;<o:p></o:p></pre><pre>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; a=3Drtpmap:97 H264-SVC/90000<o:p></o:p></pre><pre=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Dfmtp:97 profile-level-id=3D53001f; pack=
etization-mode=3D1;<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=
=3Dmid:SST<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m=3Dvideo 20=
002 RTP/AVP 98<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Drtpm=
ap:98 H264/90000<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Dfm=
tp:98 profile-level-id=3D4de00a; packetization-mode=3D0;<o:p></o:p></pre><p=
re>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mst-mode=3DNI-T;<o:p></o:p></pre><p=
re>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Dmid:L1<o:p></o:p></pre><pre>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; m=3Dvideo 20004 RTP/AVP 99<o:p></o:p></pre><pre>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; a=3Drtpmap:99 H264-SVC/90000<o:p></o:p></pre><pre=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=3Dfmtp:99 profile-level-id=3D53001F; pack=
etization-mode=3D1;<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; mst-mode=3DNI-TC; sprop-operation-point-info=3D&lt;2,0,1,0,53000c,<o:p><=
/o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3200,352,288,384,512&gt;,&lt=
;3,1,2,0,53001F,6400,704,576,768,1024&gt;;<o:p></o:p></pre><pre>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; a=3Dmid:L2<o:p></o:p></pre><pre>&nbsp; &nbsp;&nbsp;&nbs=
p;&nbsp;a=3Ddepend:99 lay L1:98<o:p></o:p></pre><p class=3DMsoNormal><o:p>&=
nbsp;</o:p></p><div><div><p class=3DMsoNormal>On 08/30/2012 11:19 PM, Berna=
rd Aboba wrote:<o:p></o:p></p></div><blockquote style=3D'margin-top:5.0pt;m=
argin-bottom:5.0pt'><div><p class=3DMsoNormal style=3D'margin-bottom:12.0pt=
'>Harald said: <o:p></o:p></p><div><p class=3DMsoNormal style=3D'margin-bot=
tom:12.0pt'>&gt; My assumption has always been that if you were operating o=
n a network <br>&gt; that could only apply diffserv to separate 5-tuples, y=
ou would allocate <br>&gt; the SSRCs comprising a multilayer encoding to di=
fferent 5-tuples.<br><br>[BA] RFC 6190 Section 1 says:<o:p></o:p></p><pre>&=
nbsp;&nbsp; This memo defines two basic modes for transmission of SVC data,=
<o:p></o:p></pre><pre>&nbsp;&nbsp; single-session transmission (SST) and mu=
lti-session transmission<o:p></o:p></pre><pre>&nbsp;&nbsp; (MST).&nbsp; In =
SST, a single RTP session is used for the transmission of<o:p></o:p></pre><=
pre>&nbsp;&nbsp; all scalability layers comprising an SVC bitstream; in MST=
, the<o:p></o:p></pre><pre>&nbsp;&nbsp; scalability layers are transported =
on different RTP sessions.&nbsp; <o:p></o:p></pre><p class=3DMsoNormal><br>=
[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-=
tuple (SST).&nbsp; However, my understanding <br>is that the SST approach i=
s more popular than MST. <br><br>&gt; This choice seems to be a choice that=
 the application writer should take <br>&gt; before deciding whether or not=
 to use BUNDLE, so it's a little hard to <br>&gt; see what the relationship=
 to BUNDLE is.<br><br>[BA] The open question has been how to indicate the d=
esire for both layered coding and BUNDLE in SDP, <br>given the backward com=
patibility issues we have talked about.&nbsp; For example, if it is desired=
 to do SST and<br>BUNDLE, do you signal MST and BUNDLE on different ports i=
n the offer and then if SST and BUNDLE are<br>supported by the answer, have=
 the answer respond with BUNDLE as well as dependency groups using <br>the =
same port?&nbsp; That would seem to imply an assumption that every MST impl=
ementation can also do SST.&nbsp; <br>Or do do you signal SST and BUNDLE on=
 the same port, and then if the response indicates that the SDP<br>was reje=
cted, formulate an alternative offer (MST with BUNDLE?&nbsp; H.264/AVC with=
 BUNDLE? <br>SST without BUNDLE??)&nbsp; <o:p></o:p></p></div></div></block=
quote><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p>=
</p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></ht=
ml>=

--_000_7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92ESESSCMS0356e_--

From harald@alvestrand.no  Fri Aug 31 01:59:53 2012
Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D7B21F8577 for <mmusic@ietfa.amsl.com>; Fri, 31 Aug 2012 01:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.774
X-Spam-Level: 
X-Spam-Status: No, score=-109.774 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGX-dTyQc3uB for <mmusic@ietfa.amsl.com>; Fri, 31 Aug 2012 01:59:51 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 392D021F84FD for <mmusic@ietf.org>; Fri, 31 Aug 2012 01:59:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55FEA39E173; Fri, 31 Aug 2012 10:59:20 +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 ViMlm6Vya2dc; Fri, 31 Aug 2012 10:59:18 +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 3E86639E020; Fri, 31 Aug 2012 10:59:18 +0200 (CEST)
Message-ID: <50407CE5.3080407@alvestrand.no>
Date: Fri, 31 Aug 2012 10:59:17 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <503E0B63.3020708@ericsson.com>, , <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <503FDBA1.9000003@alvestrand.no> <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl> <504055EF.5070300@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se>
Content-Type: multipart/alternative; boundary="------------040704050308030902060606"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 08:59:53 -0000

This is a multi-part message in MIME format.
--------------040704050308030902060606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/31/2012 10:53 AM, Christer Holmberg wrote:
>
> Hi,
>
> One question is of course whether we are going to move ahead with the 
> m=bundle proposal. In that case, I guess the m=video lines would look 
> like they do today, and the question is how we describe the 
> multiplexed SVC within the m=bundle line.
>

The SVC session is simple - just use the same lines (except rtpmap 
H.264/ -> mime-type-map video/H.264, or whatever we decide to call it).
The MVC additional session can't be bundled, so it remains outside the 
BUNDLE line.


> Regards,
>
> Christer
>
> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On 
> Behalf Of *Harald Alvestrand
> *Sent:* 31. elokuuta 2012 9:13
> *To:* Bernard Aboba
> *Cc:* mmusic@ietf.org
> *Subject:* Re: [MMUSIC] H.264 SVC and BUNDLE
>
> On 08/31/2012 03:30 AM, Bernard Aboba wrote:
>
>     Harald said:
>
>     I lack the background to think about this... in existing
>     equipment, if you want to do SST, but would be willing to do MST
>     if the other end did not support SST, how would your offer look
>     (without BUNDLE)?
>
>     My head hurts a little when trying to guess, but from your
>     question it sounds like you've done it, so it's better if you just
>     paste an example.
>
>     (BTW, this is really an MMUSIC discussion)
>
>     [BA] RFC 6190 gives several examples of SST and MST offers:
>
>
>             7.3.1 <http://tools.ietf.org/html/rfc6190#section-7.3.1>. 
>             Example for Offering a Single SVC Session
>
>
>             7.3.2 <http://tools.ietf.org/html/rfc6190#section-7.3.2>. 
>             Example for Offering a Single SVC Session Using
>             scalable-layer-Id
>
>
>             7.3.3 <http://tools.ietf.org/html/rfc6190#section-7.3.3>. 
>             Example for Offering Multiple Sessions in MST
>
>
>             7.3.4 <http://tools.ietf.org/html/rfc6190#section-7.3.4>. 
>             Example for Offering Multiple Sessions in MST Including
>             Operation with Answerer Using scalable-laye
>
>
>             r-id
>
>       
>
>
>             7.3.5 <http://tools.ietf.org/html/rfc6190#section-7.3.5>. 
>             Example for Negotiating an SVC Stream with a Constrained
>             Base Layer in SST
>
>     I believe that the answer to your question is closest to example
>     7.3.5 (SST) with a bit of 7.3.4 (MST) thrown in. Notice that
>     Payload types 97 and 99 are similar but not the same (97 is SST,
>     99 is MST):
>
> Aha - so you'd send 3 video M-lines, an SST-only application would 
> zero out the second and third, while an MST-only application would 
> zero out the first, and one capable of doing both would accept all 3? 
> and one could look at the payload type (96/97 vs 98 or 99) to decide 
> which one a particular video stream belonged to?
>
> It makes no sense (to my mind at least) to multiplex L1 and L2 
> together, but one could multiplex SST with L1 and save one port in the 
> "both are supported" case:
>
> a=group:BUNDLE SST L1
>
> I think this would create sessions that would not create an unsolvable 
> problem; if all were accepted, the decoder would have to look at the 
> payload type of the first packet on an SSRC to figure out whether a 
> particular SSRC was using SST or MST for that particular payload.
>
>
> Offer:
>
>        a=group:DDP L1 L2
>        m=video 20000 RTP/AVP 97 96
>        a=rtpmap:96 H264-SVC/90000
>        a=fmtp:96 profile-level-id=53001e; packetization-mode=0;
>        a=rtpmap:97 H264-SVC/90000
>        a=fmtp:97 profile-level-id=53001f; packetization-mode=1;
>        a=mid:SST
>        m=video 20002 RTP/AVP 98
>        a=rtpmap:98 H264/90000
>        a=fmtp:98 profile-level-id=4de00a; packetization-mode=0;
>         mst-mode=NI-T;
>        a=mid:L1
>        m=video 20004 RTP/AVP 99
>        a=rtpmap:99 H264-SVC/90000
>        a=fmtp:99 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>        a=mid:L2
>        a=depend:99 lay L1:98
>
> On 08/30/2012 11:19 PM, Bernard Aboba wrote:
>
>     Harald said:
>
>     > My assumption has always been that if you were operating on a
>     network
>     > that could only apply diffserv to separate 5-tuples, you would
>     allocate
>     > the SSRCs comprising a multilayer encoding to different 5-tuples.
>
>     [BA] RFC 6190 Section 1 says:
>
>         This memo defines two basic modes for transmission of SVC data,
>
>         single-session transmission (SST) and multi-session transmission
>
>         (MST).  In SST, a single RTP session is used for the transmission of
>
>         all scalability layers comprising an SVC bitstream; in MST, the
>
>         scalability layers are transported on different RTP sessions.
>
>
>     [BA] So it is possible either to use multiple 5-tuples (MST) or a
>     single 5-tuple (SST).  However, my understanding
>     is that the SST approach is more popular than MST.
>
>     > This choice seems to be a choice that the application writer
>     should take
>     > before deciding whether or not to use BUNDLE, so it's a little
>     hard to
>     > see what the relationship to BUNDLE is.
>
>     [BA] The open question has been how to indicate the desire for
>     both layered coding and BUNDLE in SDP,
>     given the backward compatibility issues we have talked about.  For
>     example, if it is desired to do SST and
>     BUNDLE, do you signal MST and BUNDLE on different ports in the
>     offer and then if SST and BUNDLE are
>     supported by the answer, have the answer respond with BUNDLE as
>     well as dependency groups using
>     the same port?  That would seem to imply an assumption that every
>     MST implementation can also do SST.
>     Or do do you signal SST and BUNDLE on the same port, and then if
>     the response indicates that the SDP
>     was rejected, formulate an alternative offer (MST with BUNDLE? 
>     H.264/AVC with BUNDLE?
>     SST without BUNDLE??)
>


--------------040704050308030902060606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/31/2012 10:53 AM, Christer
      Holmberg wrote:<br>
    </div>
    <blockquote
cite="mid:7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
h4
	{mso-style-priority:9;
	mso-style-link:"Heading 4 Char";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.h4
	{mso-style-name:h4;}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 4";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;
	font-style:italic;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">One
            question is of course whether we are going to move ahead
            with the m=bundle proposal. In that case, I guess the
            m=video lines would look like they do today, and the
            question is how we describe the multiplexed SVC within the
            m=bundle line.</span></p>
      </div>
    </blockquote>
    <br>
    The SVC session is simple - just use the same lines (except rtpmap
    H.264/ -&gt; mime-type-map video/H.264, or whatever we decide to
    call it).<br>
    The MVC additional session can't be bundled, so it remains outside
    the BUNDLE line.<br>
    <br>
    <br>
    <blockquote
cite="mid:7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Christer<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0cm 0cm 0cm">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">
                <a class="moz-txt-link-abbreviated" href="mailto:mmusic-bounces@ietf.org">mmusic-bounces@ietf.org</a> [<a class="moz-txt-link-freetext" href="mailto:mmusic-bounces@ietf.org">mailto:mmusic-bounces@ietf.org</a>]
                <b>On Behalf Of </b>Harald Alvestrand<br>
                <b>Sent:</b> 31. elokuuta 2012 9:13<br>
                <b>To:</b> Bernard Aboba<br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:mmusic@ietf.org">mmusic@ietf.org</a><br>
                <b>Subject:</b> Re: [MMUSIC] H.264 SVC and BUNDLE<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <div>
          <p class="MsoNormal">On 08/31/2012 03:30 AM, Bernard Aboba
            wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <div>
            <p class="MsoNormal" style="margin-bottom:12.0pt">Harald
              said:<br>
              <br>
              I lack the background to think about this... in existing
              equipment, if you want to do SST, but would be willing to
              do MST if the other end did not support SST, how would
              your offer look (without BUNDLE)?<br>
              <br>
              My head hurts a little when trying to guess, but from your
              question it sounds like you've done it, so it's better if
              you just paste an example.<br>
              <br>
              (BTW, this is really an MMUSIC discussion)<br>
              <br>
              [BA] RFC 6190 gives several examples of SST and MST
              offers:<o:p></o:p></p>
            <h4><a moz-do-not-send="true" name="section-7.3.1"></a><a
                moz-do-not-send="true"
                href="http://tools.ietf.org/html/rfc6190#section-7.3.1"><span
                  style="font-family:&quot;Courier New&quot;">7.3.1</span></a><span
                style="font-family:&quot;Courier New&quot;">.&nbsp; Example
                for Offering a Single SVC Session<o:p></o:p></span></h4>
            <h4><a moz-do-not-send="true" name="section-7.3.2"></a><a
                moz-do-not-send="true"
                href="http://tools.ietf.org/html/rfc6190#section-7.3.2"><span
                  style="font-family:&quot;Courier New&quot;">7.3.2</span></a><span
                style="font-family:&quot;Courier New&quot;">.&nbsp; Example
                for Offering a Single SVC Session Using
                scalable-layer-Id<o:p></o:p></span></h4>
            <h4><a moz-do-not-send="true" name="section-7.3.3"></a><a
                moz-do-not-send="true"
                href="http://tools.ietf.org/html/rfc6190#section-7.3.3"><span
                  style="font-family:&quot;Courier New&quot;">7.3.3</span></a><span
                style="font-family:&quot;Courier New&quot;">.&nbsp; Example
                for Offering Multiple Sessions in MST<o:p></o:p></span></h4>
            <h4><a moz-do-not-send="true" name="section-7.3.4"></a><a
                moz-do-not-send="true"
                href="http://tools.ietf.org/html/rfc6190#section-7.3.4"><span
                  style="font-family:&quot;Courier New&quot;">7.3.4</span></a><span
                style="font-family:&quot;Courier New&quot;">.&nbsp; Example
                for Offering Multiple Sessions in MST Including
                Operation with Answerer Using scalable-laye<o:p></o:p></span></h4>
            <h4><span style="font-family:&quot;Courier New&quot;"> r-id<o:p></o:p></span></h4>
            <pre><span class="h4"><o:p>&nbsp;</o:p></span></pre>
            <h4><a moz-do-not-send="true" name="section-7.3.5"></a><a
                moz-do-not-send="true"
                href="http://tools.ietf.org/html/rfc6190#section-7.3.5"><span
                  style="font-family:&quot;Courier New&quot;">7.3.5</span></a><span
                style="font-family:&quot;Courier New&quot;">.&nbsp; Example
                for Negotiating an SVC Stream with a Constrained Base
                Layer in SST<o:p></o:p></span></h4>
            <p class="MsoNormal">I believe that the answer to your
              question is closest to example 7.3.5 (SST) with a bit of
              7.3.4 (MST) thrown in. Notice that Payload types 97 and 99
              are similar but not the same (97 is SST, 99 is MST): <o:p></o:p></p>
          </div>
        </blockquote>
        <p class="MsoNormal">Aha - so you'd send 3 video M-lines, an
          SST-only application would zero out the second and third,
          while an MST-only application would zero out the first, and
          one capable of doing both would accept all 3? and one could
          look at the payload type (96/97 vs 98 or 99) to decide which
          one a particular video stream belonged to?<br>
          <br>
          It makes no sense (to my mind at least) to multiplex L1 and L2
          together, but one could multiplex SST with L1 and save one
          port in the "both are supported" case:<br>
          <br>
          a=group:BUNDLE SST L1<br>
          <br>
          I think this would create sessions that would not create an
          unsolvable problem; if all were accepted, the decoder would
          have to look at the payload type of the first packet on an
          SSRC to figure out whether a particular SSRC was using SST or
          MST for that particular payload.<br>
          <br>
          <o:p></o:p></p>
        <div>
          <p class="MsoNormal"><br>
            Offer: <o:p></o:p></p>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=group:DDP L1 L2<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m=video 20000 RTP/AVP 97 96<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=rtpmap:96 H264-SVC/90000<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=fmtp:96 profile-level-id=53001e; packetization-mode=0;<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=rtpmap:97 H264-SVC/90000<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=fmtp:97 profile-level-id=53001f; packetization-mode=1;<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=mid:SST<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m=video 20002 RTP/AVP 98<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=rtpmap:98 H264/90000<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=fmtp:98 profile-level-id=4de00a; packetization-mode=0;<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mst-mode=NI-T;<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=mid:L1<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m=video 20004 RTP/AVP 99<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=rtpmap:99 H264-SVC/90000<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=fmtp:99 profile-level-id=53001F; packetization-mode=1;<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mst-mode=NI-TC; sprop-operation-point-info=&lt;2,0,1,0,53000c,<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3200,352,288,384,512&gt;,&lt;3,1,2,0,53001F,6400,704,576,768,1024&gt;;<o:p></o:p></pre>
          <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=mid:L2<o:p></o:p></pre>
          <pre>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;a=depend:99 lay L1:98<o:p></o:p></pre>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <div>
            <div>
              <p class="MsoNormal">On 08/30/2012 11:19 PM, Bernard Aboba
                wrote:<o:p></o:p></p>
            </div>
            <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
              <div>
                <p class="MsoNormal" style="margin-bottom:12.0pt">Harald
                  said: <o:p></o:p></p>
                <div>
                  <p class="MsoNormal" style="margin-bottom:12.0pt">&gt;
                    My assumption has always been that if you were
                    operating on a network <br>
                    &gt; that could only apply diffserv to separate
                    5-tuples, you would allocate <br>
                    &gt; the SSRCs comprising a multilayer encoding to
                    different 5-tuples.<br>
                    <br>
                    [BA] RFC 6190 Section 1 says:<o:p></o:p></p>
                  <pre>&nbsp;&nbsp; This memo defines two basic modes for transmission of SVC data,<o:p></o:p></pre>
                  <pre>&nbsp;&nbsp; single-session transmission (SST) and multi-session transmission<o:p></o:p></pre>
                  <pre>&nbsp;&nbsp; (MST).&nbsp; In SST, a single RTP session is used for the transmission of<o:p></o:p></pre>
                  <pre>&nbsp;&nbsp; all scalability layers comprising an SVC bitstream; in MST, the<o:p></o:p></pre>
                  <pre>&nbsp;&nbsp; scalability layers are transported on different RTP sessions.&nbsp; <o:p></o:p></pre>
                  <p class="MsoNormal"><br>
                    [BA] So it is possible either to use multiple
                    5-tuples (MST) or a single 5-tuple (SST).&nbsp; However,
                    my understanding <br>
                    is that the SST approach is more popular than MST. <br>
                    <br>
                    &gt; This choice seems to be a choice that the
                    application writer should take <br>
                    &gt; before deciding whether or not to use BUNDLE,
                    so it's a little hard to <br>
                    &gt; see what the relationship to BUNDLE is.<br>
                    <br>
                    [BA] The open question has been how to indicate the
                    desire for both layered coding and BUNDLE in SDP, <br>
                    given the backward compatibility issues we have
                    talked about.&nbsp; For example, if it is desired to do
                    SST and<br>
                    BUNDLE, do you signal MST and BUNDLE on different
                    ports in the offer and then if SST and BUNDLE are<br>
                    supported by the answer, have the answer respond
                    with BUNDLE as well as dependency groups using <br>
                    the same port?&nbsp; That would seem to imply an
                    assumption that every MST implementation can also do
                    SST.&nbsp; <br>
                    Or do do you signal SST and BUNDLE on the same port,
                    and then if the response indicates that the SDP<br>
                    was rejected, formulate an alternative offer (MST
                    with BUNDLE?&nbsp; H.264/AVC with BUNDLE? <br>
                    SST without BUNDLE??)&nbsp; <o:p></o:p></p>
                </div>
              </div>
            </blockquote>
            <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------040704050308030902060606--

From christer.holmberg@ericsson.com  Fri Aug 31 03:30:08 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77E721F8578 for <mmusic@ietfa.amsl.com>; Fri, 31 Aug 2012 03:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.567
X-Spam-Level: 
X-Spam-Status: No, score=-5.567 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B84g9ghu8jN for <mmusic@ietfa.amsl.com>; Fri, 31 Aug 2012 03:30:08 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 588DF21F8550 for <mmusic@ietf.org>; Fri, 31 Aug 2012 03:30:07 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-51-5040922d1319
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E3.6B.25676.D2290405; Fri, 31 Aug 2012 12:30:06 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 31 Aug 2012 12:30:05 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 31 Aug 2012 12:30:04 +0200
Thread-Topic: [MMUSIC] H.264 SVC and BUNDLE
Thread-Index: Ac2HVulHuVkA1NiXSU+YndueyJckSAABH3EA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A3DCE65@ESESSCMS0356.eemea.ericsson.se>
References: <503E0B63.3020708@ericsson.com>, , <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <503FDBA1.9000003@alvestrand.no> <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl> <504055EF.5070300@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92@ESESSCMS0356.eemea.ericsson.se> <50407CE5.3080407@alvestrand.no>
In-Reply-To: <50407CE5.3080407@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra7eJIcAg/2nWSz2L7nMbHGsr4vN YuryxywOzB5XJlxh9Xjcc4bNY8mSn0wBzFFcNimpOZllqUX6dglcGTcbVAue6VU8PzuPvYFx uVoXIyeHhICJxI/bs5khbDGJC/fWs3UxcnEICZxilOjY/4AJwlnAKDFx9hXWLkYODjYBC4nu f9ogDSICOhIP9zcwgdjMAiESSzv/sIHYLAKqElu2HGAHsYUFtCQ2djxmgqjXlvj9qYsRwjaS eL24hQXE5hUIl3h3eyMjxK5GVon5Xz6AJTgFdCVaFp0HG8oIdN33U2uglolL3HoynwniagGJ JXvOQ30gKvHy8T9WiHpRiTvt6xkh6vUkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaS lllIWmYhaVnAyLKKUTg3MTMnvdxIL7UoM7m4OD9Przh1EyMwng5u+a26g/HOOZFDjNIcLEri vNZb9/gLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYEy9uWh36B82mff8PxbqcUT7ruLmEui7 XXnw0WdWqZcBftM6NaT+V6w26pX5vtEzRqFx91+BwOS9QjbODmbnPbLcK4/8DNU9tuUnb2ft 95gz6XaHFwhN1zO9m7IwlffZ7IYEkzeuTqF9Jaw/VwhUf5OJvmn6P1v+2/pf2zc/Le04qnD2 wBa5m0osxRmJhlrMRcWJAFVUPeh1AgAA
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 10:30:08 -0000

Hi,
=A0
>>One question is of course whether we are going to move ahead with the m=
=3Dbundle proposal. In that case, I guess the m=3Dvideo lines=20
>>would look like they do today, and the question is how we describe the mu=
ltiplexed SVC within the m=3Dbundle line.
>
> The SVC session is simple - just use the same lines (except rtpmap H.264/=
 -> mime-type-map video/H.264, or whatever we decide to call it).

Correct.

And, as you indicate, if we move ahead with the m=3Dbundle alternative, we =
need to decide whether we will use the rtpmap attribute, or whether we need=
 something else. But, that's a separate thread :)

>The MVC additional session can't be bundled, so it remains outside the BUN=
DLE line.

Why do you think it can't be bundled? Because it can't use the same port, a=
nd/or because it uses multiple RTP sessions?

Regards,

Christer
=A0
=A0
=A0
=A0
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: 31. elokuuta 2012 9:13
To: Bernard Aboba
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
=A0
On 08/31/2012 03:30 AM, Bernard Aboba wrote:
Harald said:

I lack the background to think about this... in existing equipment, if you =
want to do SST, but would be willing to do MST if the other end did not sup=
port SST, how would your offer look (without BUNDLE)?

My head hurts a little when trying to guess, but from your question it soun=
ds like you've done it, so it's better if you just paste an example.

(BTW, this is really an MMUSIC discussion)

[BA] RFC 6190 gives several examples of SST and MST offers:
7.3.1.=A0 Example for Offering a Single SVC Session
7.3.2.=A0 Example for Offering a Single SVC Session Using scalable-layer-Id
7.3.3.=A0 Example for Offering Multiple Sessions in MST
7.3.4.=A0 Example for Offering Multiple Sessions in MST Including Operation=
 with Answerer Using scalable-laye
r-id
=A0
7.3.5.=A0 Example for Negotiating an SVC Stream with a Constrained Base Lay=
er in SST
I believe that the answer to your question is closest to example 7.3.5 (SST=
) with a bit of 7.3.4 (MST) thrown in. Notice that Payload types 97 and 99 =
are similar but not the same (97 is SST, 99 is MST):=20
Aha - so you'd send 3 video M-lines, an SST-only application would zero out=
 the second and third, while an MST-only application would zero out the fir=
st, and one capable of doing both would accept all 3? and one could look at=
 the payload type (96/97 vs 98 or 99) to decide which one a particular vide=
o stream belonged to?

It makes no sense (to my mind at least) to multiplex L1 and L2 together, bu=
t one could multiplex SST with L1 and save one port in the "both are suppor=
ted" case:

a=3Dgroup:BUNDLE SST L1

I think this would create sessions that would not create an unsolvable prob=
lem; if all were accepted, the decoder would have to look at the payload ty=
pe of the first packet on an SSRC to figure out whether a particular SSRC w=
as using SST or MST for that particular payload.



Offer:=20
=A0=A0=A0=A0=A0=A0a=3Dgroup:DDP L1 L2
=A0=A0=A0=A0=A0 m=3Dvideo 20000 RTP/AVP 97 96
=A0=A0=A0=A0=A0 a=3Drtpmap:96 H264-SVC/90000
=A0=A0=A0=A0=A0 a=3Dfmtp:96 profile-level-id=3D53001e; packetization-mode=
=3D0;
=A0=A0=A0=A0=A0 a=3Drtpmap:97 H264-SVC/90000
=A0=A0=A0=A0=A0 a=3Dfmtp:97 profile-level-id=3D53001f; packetization-mode=
=3D1;
=A0=A0=A0=A0=A0 a=3Dmid:SST
=A0=A0=A0=A0=A0 m=3Dvideo 20002 RTP/AVP 98
=A0=A0=A0=A0=A0 a=3Drtpmap:98 H264/90000
=A0=A0=A0=A0=A0 a=3Dfmtp:98 profile-level-id=3D4de00a; packetization-mode=
=3D0;
=A0=A0=A0=A0=A0=A0 mst-mode=3DNI-T;
=A0=A0=A0=A0=A0 a=3Dmid:L1
=A0=A0=A0=A0=A0 m=3Dvideo 20004 RTP/AVP 99
=A0=A0=A0=A0=A0 a=3Drtpmap:99 H264-SVC/90000
=A0=A0=A0=A0=A0 a=3Dfmtp:99 profile-level-id=3D53001F; packetization-mode=
=3D1;
=A0=A0=A0=A0=A0=A0 mst-mode=3DNI-TC; sprop-operation-point-info=3D<2,0,1,0,=
53000c,
=A0=A0=A0=A0=A0 3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024=
>;
=A0=A0=A0=A0=A0 a=3Dmid:L2
=A0 =A0=A0=A0=A0a=3Ddepend:99 lay L1:98
=A0
On 08/30/2012 11:19 PM, Bernard Aboba wrote:
Harald said:=20
> My assumption has always been that if you were operating on a network=20
> that could only apply diffserv to separate 5-tuples, you would allocate=20
> the SSRCs comprising a multilayer encoding to different 5-tuples.

[BA] RFC 6190 Section 1 says:
=A0=A0 This memo defines two basic modes for transmission of SVC data,
=A0=A0 single-session transmission (SST) and multi-session transmission
=A0=A0 (MST).=A0 In SST, a single RTP session is used for the transmission =
of
=A0=A0 all scalability layers comprising an SVC bitstream; in MST, the
=A0=A0 scalability layers are transported on different RTP sessions.=A0=20

[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-=
tuple (SST).=A0 However, my understanding=20
is that the SST approach is more popular than MST.=20

> This choice seems to be a choice that the application writer should take=
=20
> before deciding whether or not to use BUNDLE, so it's a little hard to=20
> see what the relationship to BUNDLE is.

[BA] The open question has been how to indicate the desire for both layered=
 coding and BUNDLE in SDP,=20
given the backward compatibility issues we have talked about.=A0 For exampl=
e, if it is desired to do SST and
BUNDLE, do you signal MST and BUNDLE on different ports in the offer and th=
en if SST and BUNDLE are
supported by the answer, have the answer respond with BUNDLE as well as dep=
endency groups using=20
the same port?=A0 That would seem to imply an assumption that every MST imp=
lementation can also do SST.=A0=20
Or do do you signal SST and BUNDLE on the same port, and then if the respon=
se indicates that the SDP
was rejected, formulate an alternative offer (MST with BUNDLE?=A0 H.264/AVC=
 with BUNDLE?=20
SST without BUNDLE??)=A0=20
=A0
=A0