Re: [clue] Using BUNDLE with CLUE

[Christian Groves <[e-mail]>]

Hello Christer,

With respect to Q2, I didn't think the media feature tag was instead of 
group:CLUE?

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?

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:[e-mail]] *On Behalf Of *Robert 
> Hansen (rohanse2)
> *Sent:* 1. huhtikuuta 2014 13:07
> *To:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue