Re: [clue] Using BUNDLE with CLUE
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 02 April 2014 05:47 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80011A0137 for <clue@ietfa.amsl.com>; Tue, 1 Apr 2014 22:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.451
X-Spam-Level:
X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBAI7Wj-ib3s for <clue@ietfa.amsl.com>; Tue, 1 Apr 2014 22:47:16 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 325311A0135 for <clue@ietf.org>; Tue, 1 Apr 2014 22:47:15 -0700 (PDT)
X-AuditID: c1b4fb25-b7f3b8e0000006f1-72-533ba45eeb25
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.B8.01777.E54AB335; Wed, 2 Apr 2014 07:47:10 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Wed, 2 Apr 2014 07:47:09 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: [clue] Using BUNDLE with CLUE
Thread-Index: Ac9Nkg5IUPNx7ldUTDK8kHk510O6AQAAOGwQACGOwwAAB1PM0A==
Date: Wed, 02 Apr 2014 05:47:09 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D272932@ESESSMB209.ericsson.se>
References: <C6252EA94E00E44EADC3A2FEB59D4402020DF93F@xmb-aln-x07.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D271311@ESESSMB209.ericsson.se> <533B8E76.2090009@nteczone.com>
In-Reply-To: <533B8E76.2090009@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW7cEutgg8ldahZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mo4v3wpa8HclIo55yewNjBuCuhi5OSQEDCR 2HB+NwuELSZx4d56NhBbSOAwo8Tr9SVdjFxA9mJGiTMz/zB2MXJwsAlYSHT/0wapEREIl+jY doURxBYW0JJYff0PK0RcW2LF/R4mkHIRASeJrWtzQMIsAioSSzdsACvnFfCVeLJ3HxvE+E2M EpdenWQBqecU0JHoPgxWzwh0zvdTa5hAbGYBcYlbT+YzQZwpILFkz3lmCFtU4uXjf6wQtqJE +9MGRoh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGJkz03M zEkvN9rECIyDg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoY10rLft+wV5V3vlrFHvE7m62dIlIdPvjuesByUTnU/DkjT8+H3W8cmHMm31uadfOtme4T bjObBWK63/W27b/MxSHPdUfG/W9twNFCro5fGyoSmfUZWGfdiqprSa6fv4kr7WTD7xeJk67V 7I95U/wjO6889UdPorLw8/jW4kcZZjKyin/2vDmlxFKckWioxVxUnAgAVfSFBFECAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LA9V6U2LtyG_Ki1ptuaNsbnacyk
Subject: Re: [clue] Using BUNDLE with CLUE
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Apr 2014 05:47:20 -0000
Hi, >With respect to Q2, I didn't think the media feature tag was instead of group:CLUE? We would still use group:CLUE to group m= lines controlled by CLUE, but we would not use group:CLUE as a generic CLUE support indicator. I.e. you would not include group:CLUE unless you are actually grouping CLUE m= lines. >What happens if we have two m=application SCTP/DTLS lines in an SDP? If we only use the media feature tag how do we indicate which m= would be specific to CLUE via SDP? The idea has been that, within a CLUE group, we only have ONE m=application SCTP/DTLS line. Regards, Christer Regards, Christian On 1/04/2014 9:27 PM, Christer Holmberg wrote: > > Hi, > > *Q1*: If the remote part has indicated support of BUNDLE in the first > answer, then I see no problem in adding the BUNDLE m- lines in the BAS > offer. But, of course you can also first send a BAS offer containing > the initial m- lines, and after that send a third offer with the > BUNDLE m- lines. I am not sure whether we would need to mandate one > way or another, but it would probably be good to describe both. > > *Q2*: Regarding your example, I hope we'll use a media feature tag > instead of group:CLUE to indicate support of CLUE. At least nobody has > objected to it :) > > *Q3*: Regarding your text on Demultiplexing of RTP, the status has > changed. > > You CAN re-use the same PT value in multiple m- lines (due to the > limited number range), as long as the codec configuration associated > with the PT value is the same. The plan is that BUNDLE will specify > usage of an identifier, associated with an m- line, which is inserted > into the RTP packet by the sender, so that the receiver knows to which > m- line the RTP packet belongs. This will reflected in bundle-06, > which will be submitted in the near future. > > *Q4*: Regarding the directionality and number of BUNDLE groups, using > a BUNDLE group per direction was one option. Another could be to use a > BUNDLE group per media type. Etc. There could e.g. be QoS related > reasons why you want to use different BUNDLE groups (read: different > media 5-tuples). I guess the question is whether it would be useful > for CLUE entities to be able to indicate which "BUNDLE configurations" > they support. "Everything in one BUNDLE group" could be default. > > Regards, > > Christer > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Robert > Hansen (rohanse2) > *Sent:* 1. huhtikuuta 2014 13:07 > *To:* clue@ietf.org > *Subject:* [clue] Using BUNDLE with CLUE > > Introduction: > > A fundamental aspect of CLUE is the sending of multiple streams of > media. We are using conventional SDP to specify the encodings we > support, and hence each media stream necessitates a separate m-line. > For most use-cases, however, using a separate port per m-line is > suboptimal: it means opening more ports, more NAT work, more resources > consumed for ICE, etc. As such, a method to allow multiple m-lines to > share the same 5-tuple address is highly desirable. > > Until now the signalling work has focused on the demultiplexed case. > As such, this is an attempt to evaluate the use of BUNDLE with CLUE - > those with a much better understanding of BUNDLE than I will be able > to correct the mistakes I'll inevitably make. > > We have generally figured that CLUE would not raise any particular > issues with BUNDLE, given that CLUE now uses separate m-lines for > encodings, but we need to go through and make sure, as well as > providing guidance in the CLUE documentation on how BUNDLE interacts > with it. > > Obviously I'm not going to duplicate the BUNDLE draft here, instead > I'll just make reference to the draft. > > Initial offer/answer: > > One of the principle concerns of BUNDLE is to ensure that a receiver > does not receive an SDP it considers invalid due to its lack of > support for bundling m-lines. The fact that we recommend that > CLUE-controlled m-lines are not included in the initial O/A means that > I think that we can combine the extra O/A that BUNDLE normally adds > over an unBUNDLEd call with one of the O/As required by CLUE... > > Adding CLUE-controlled m-lines during the Bundle Address > Synchronization (BAS) offer: > > Having completed the initial O/A and established BUNDLE support the > initial offerer needs to send a new offer to synchronise the BUNDLE > addresses and make any intermediary devices aware of the addresses in use. > > In CLUE, the subsequent offer is also when we would like to start > adding CLUE-controlled m-lines. However, section 6.4.3. of the BUNDLE > specification warns that it important that the BAS offer is accepted, > and while it makes clear that the offerer MAY change the SDP, it warns > to avoid changes that could cause the answerer to reject the new offer. > > CLUE definitely needs to provide guidance here. My belief is that > adding the CLUE-controlled m-lines at this stage should not increase > the chance of the offer as a whole being rejected, so long as they > share the same media types and attributes as the existing media lines. > This would also help resolve the glare issue at the start of a CLUE > call: since a BAS is mandatory in BUNDLE this provides an obvious 'who > should reINVITE first' case for CLUE, where the initial offerer has to > send an new offer even if they don't have any CLUE encodings to add. > > If we did feel that adding new m-lines in the BAS offer was too high a > risk then BUNDLE and CLUE become sequential: BAS should be done first, > and then CLUE-controlled m-lines should be added in a subsequent > INVITE. In this case BUNDLE would include one extra O/A compared to > the unBUNDLEd case. > > I've included an example below, modifying the example from the BUNDLE > draft to show the initial offerer using the BAS offer to also add > CLUE-controlled media. > > Initial offer example - the offer includes an audio and video line > with unique ports, both in the same BUNDLE group (indicating that the > offerer supports BUNDLE and wants to multiplex these media flows). > There is also a data channel that will be used for CLUE, which is > included in the CLUE group. > > a=group:BUNDLE foo bar > > a=group:CLUE zen > > m=audio 10000 RTP/AVP 0 8 106 > > ... > > a=mid:foo > > m=video 10002 RTP/AVP 96 97 > > ... > > a=mid:bar > > m=application 10004 SCTP/DTLS 10004 > > ... > > a=mid:zen > > Initial answer example - the answer picks a local BUNDLE address and > (via ordering in the group attribute) selects an address for the offerer. > > a=group:BUNDLE foo bar > > a=group:CLUE zen > > m=audio 20000 RTP/AVP 106 > > ... > > a=mid:foo > > m=video 20000 RTP/AVP 96 > > ... > > a=mid:bar > > m=application 20002 SCTP/DTLS 20002 > > ... > > a=mid:zen > > Subsequent offer example - the offerer synchronises addresses and adds > CLUE-controlled media lines using the same address; these are included > in both the BUNDLE and CLUE groups. > > a=group:BUNDLE foo bar enc1 enc2 enc3 > > a=group:CLUE zen enc1 enc2 enc3 > > m=audio 10000 RTP/AVP 0 8 106 > > ... > > a=mid:foo > > m=video 10000 RTP/AVP 96 97 > > ... > > a=mid:bar > > m=application 10004 SCTP/DTLS 10004 > > ... > > a=mid:zen > > m=video 10000 RTP/AVP 96 97 > > ... > > a=mid:enc1 > > a=label:1 > > m=video 10000 RTP/AVP 96 97 > > ... > > a=mid:enc2 > > a=label:2 > > m=video 10000 RTP/AVP 96 97 > > ... > > a=mid:enc3 > > a=label:3 > > Answerer rejects BUNDLE: > > If the answer does not support BUNDLE then the offerer continues as in > the disaggregated case, though it may decide to offer fewer streams, > or even not do CLUE at all (in the latter case it should reINVITE and > remove the CLUE group and data channel). > > Effects of multiplexing on CLUE-relevant SDP attributes: > > The BUNDLE draft specifies how certain SDP attributes are affected by > multiplexing the m-lines, and draft-ietf-mmusic-sdp-mux-attributes > describes how multiplexing affects many other SDP attributes. I can't > see any CLUE-specific issues here: the 'label' attribute is unaffected > by multiplexing, nor is the directionality of the m-lines, and the > 'mid' attribute needed by CLUE is also needed by BUNDLE. > > Directionality of CLUE-controlled media: > > CLUE-controlled m-lines are currently unidirectional. I don't believe > this raises any specific BUNDLE issues. Christer suggests that > potentially the encodings on each side could be in separate BUNDLE > groups - I suggest we use the same group for both sides, which would > also make it easier to move to bidirectional streams if we ever wanted > to do that. > > BUNDLE support in CLUE: > > While in most cases multiplexing m-lines onto a single 5-tuple will be > preferable we do have use cases involving disaggregated media. Because > of this, and because my understanding of BUNDLE is that it does not > support the aggregated to disaggregated use case (where one device > send/receives media associated with multiple m-lines on a single > IP/port, while the other sends/receives the media associated with > multiple m-lines on multiple IP/ports) I don't see a reason to mandate > BUNDLE support for CLUE devices that only operate in disaggregated > mode. As such, while CLUE should document how to use BUNDLE to > multiplex media streams, it shouldn't be mandatory for CLUE devices to > support it. > > Demultiplexing of RTP: > > Media flows from the same BUNDLE group all belong to the same RTP > session; hence a receiver needs a method is needed to separate the > various capture encodings. The method currently defined in BUNDLE is > very straightforward: all of the dynamic payload types in each m-line > in a BUNDLE group must be unique; as such, any received RTP packet can > be mapped to a specific m-line and codec. > > This method, however, does suffer from the fact that the dynamic > payload type range is limited. In the case of many m-lines, of audio > (with potentially many codecs) and video bundled together, and/or the > increasing use of scalable video codecs with multiple layers and the > use of FEC repair flows, this space may be insufficient. > > There are other methods that could be used for this demultiplexing. > For implementation with static sources or RTP mixers, streams will > have a consistent SSRC, and hence the a=ssrc attribute can be supplied > by the sender to allow the receiver to differentiate flows via their > SSRC. For implementations where the streams being sent do not have a > static SSRC, such as source projection mixers, a specific > stream-correlator can be used, such as an AppID token specified by the > sender in SDP and in an RTP header extension. > > How stream demultiplexing is performed with BUNDLE is not a problem > specific to CLUE, and is not a problem that should be solved in a > CLUE-specific fashion. However, it is one that we need to ensure is > solved in a way consistent with our use-cases, and the number of > encodings we envisage allowing. Given that the simultaneous sending of > many capture encodings is a primary motivator behind CLUE I believe > that demultiplexing via payload will not be sufficient, and that we > would need additional methods of differentiation. > > If not all payload types must be unique then the question of under > what circumstances codecs on two m-lines can share the same payload > type becomes relevant. > > Summary: > > I believe BUNDLE is a good solution for how we can multiplex media > streams when doing CLUE, and I can't see any CLUE-specific issues that > would need to be addressed in BUNDLE. I think the main decision CLUE > would need to make is whether do first do BUNDLE negotiation > (including address synchronisation) and then begin adding CLUE > m-lines, or whether the CLUE media negotiation process can begin with > the BAS, essentially eliminating the extra O/A 'cost' of BUNDLE. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue
- Re: [clue] Using BUNDLE with CLUE Christian Groves
- [clue] Using BUNDLE with CLUE Robert Hansen (rohanse2)
- Re: [clue] Using BUNDLE with CLUE Christer Holmberg
- Re: [clue] Using BUNDLE with CLUE Christer Holmberg
- Re: [clue] Using BUNDLE with CLUE Christian Groves
- Re: [clue] Using BUNDLE with CLUE Christer Holmberg