IETF Logo Mail Archive

Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 12 December 2015 17:21 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362621A8969 for <mmusic@ietfa.amsl.com>; Sat, 12 Dec 2015 09:21:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uuuj-ejcchnP for <mmusic@ietfa.amsl.com>; Sat, 12 Dec 2015 09:21:27 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10401A8966 for <mmusic@ietf.org>; Sat, 12 Dec 2015 09:21:26 -0800 (PST)
X-AuditID: c1b4fb25-f79876d0000011ee-69-566c5794b521
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DD.AE.04590.4975C665; Sat, 12 Dec 2015 18:21:25 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Sat, 12 Dec 2015 18:21:24 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01
Thread-Index: AQHRNOoS2qXUjP1aPESTEBX6wH/FCJ7HmKvg
Date: Sat, 12 Dec 2015 17:21:23 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37CC2BEA@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37C8D07A@ESESSMB209.ericsson.se> <CAD5OKxsP0_epa+16XgX-v3CumvQ9Uqg7qZuPfuNweo9a9Q1peQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37C96443@ESESSMB209.ericsson.se> <CAD5OKxvcZNQx=v+hRZrxXUMi001rafn5MjeNVaor7gkoFL+P9g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37CBF877@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CBF877@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdQndqeE6YwcNWFoupyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZVy9cIatoEGp4vzKTqYGxgmKXYycHBICJhL7 H05ng7DFJC7cWw9kc3EICRxmlNj68x0rhLOYUWLXn4vMXYwcHGwCFhLd/7RBGkQEVCX+fp/M BBJmFlCXuLo4CMQUFgiUuPHGD6IiSOL/34nMELaRxIPeI+wgNgtQ56oZy8FsXgFfif7Zz6DW PmaSuDRhLSNIglPAT+LJrF4WEJsR6Lbvp9YwgdjMAuISt57MZ4K4WUBiyZ7zzBC2qMTLx/9Y IWwliRXbLzFCnKYpsX6XPkSrosSU7odQewUlTs58wjKBUWwWkqmzEDpmIemYhaRjASPLKkbR 4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAuDm45bfqDsbLbxwPMQpwMCrx8G7ozQ4TYk0sK67M PcQowcGsJMJ7LyAnTIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvM9ODUCGB9MSS1OzU1ILUIpgs EwenVANj0S5Ti6t1HwQr/ILXuWRnnnCPUwo69ud+lPleRplzubbH9l9hO66x/fXlFQ8eF6Sd 3GbLtFu1bY97dNfWWf+7fIW2Z/dGuFdnKQcxfU9gLy/dZnuz4t/L3nO32rbVXk54Xz5j5ZVO pnVMrx7GqRS0CEttC8l0Tnl8cOnl52e2xPvGeKt0/X6qxFKckWioxVxUnAgAbwc4ZpcCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/HTwgaZLuh1VmIC9RZ81TgnkVmgI>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Dec 2015 17:21:29 -0000

One question related to this: is there are reason we need to use the SDP 'rtcp' attribute for trickle to begin with? What purpose does it serve? 

If someone sends "9 IN IP4 0.0.0.0" I think it is pretty clear it also applies to RTCP...

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 12 December 2015 16:33
To: Roman Shpount <roman@telurix.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

Hi,

>>> 1. Are you stating the rtcp attribute for mux-exclusive MUST not 
>>> contain the optional [nettype space addrtype space connection-address] or that it may contain this address and it should be set to the value from the c= line?
>>
>> Good question.
>>
>> My idea was that the attribute only contains the port, but I do agree that we should say something about the optional parts. Either we:
>>
>> 1)       say MUST NOT use it; or
>> 2)      we say MUST use the value from the c= line; or
>> 3       we allow both 1) and 2).
>
> Unless there is a reason, we should go with 3. Any endpoint that 
> supports this draft should fully support SDP rtcp attribute and must be able to parse rtcp attribute with and without the optional address.
> After the attribute is parsed there is no additional burden to determine that rtcp attribute points to the same address/port as c= and m= lines.

Correct.

Then text is needed, saying that the address information must also be the same as for the associated c- line address.

> We can also specify that 1 SHOULD be preferred, simply to send less redundant data in SDP.

Sounds ok.

--------- 

>>> 2. In cases when trickle ICE is used, should rtcp SDP attribute 
>>> contain "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your draft? Does this mean that JSEP complaint offer is always rtcp-mux exclusive?
>>
>> Good question.
>>
>> In that case, if you are yet not providing any candidates to begin with, I assume you don't know.
>>
>> Of course, if we want to distinguish the cases, one option would be to e.g. use a port value of zero for mux-exclusive?
>>
>> Perhaps the b=RR/RS bandwidth indicators could also be used somehow, but I hope we can avoid that.
>>
> This is a tricky situation. When no initial candidates are collected, 
> rtcp attribute set to port 9 can either mean that no rtcp candidates 
> are yet available or that mux exclusive is used. I do not know what is 
> the solution here. We definitely do not want to change mux only to require rtcp attribute with port 0, since this will break legacy interop with end points that support rtcp attribute but do not rtcp-mux. We might need an additional SDP attribute to indicate that rtcp mux exclusive is required.

Would we then need to require trickle UAs to understand such attributes?

(Of course, if the trickle agent is an WebRTC entity, it will support the attribute)

Regards,

Christer

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

v2.23.0 | Report a Bug | By Email