Re: [clue] Using BUNDLE with CLUE

[Christer Holmberg <[e-mail]>]

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.