[MMUSIC] How to arrange for the rejection of the bundle media description?

[[e-mail] (Dale R. Worley)]

Assuming that there is a separate bundle media description in the
offer -- and I think that there are many benefits of having a separate
bundle media description -- we must arrange that an answerer that does
not implement bundling will always reject that media description.

As far as I can tell, there are three possible ways to force the
answerer to reject a media description:

1. The media description uses a special media type that is not
otherwise implemented.

2. The media description uses a special proto value that is not
otherwise implemented.

3. The media description only provides encoding names (codec names)
that are not otherwise implemented.

(Although this seems to be an obvious application of SDP capability
negotiation, I see no way to use capneg to specify alternative port
numbers (zero or non-zero) depending on what capabilities the answerer
supports.  And we probably can't rely on legacy SBCs to handle
properly a situation where the offered port number is zero and the
answered port number is non-zero.)

Solution 1 is the cleanest from a design point of view.  (I personally
like using "m=multipart".)  But Hadriel tells me that a lot of legacy
SBCs reject any SDP that contains a media type that is not "audio" or
"video".

Regarding solution 2, there are now 32 defined proto values
(http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-2),
so it is more likely that a legacy SBC (that is, one not designed to
support bundling) will pass unknown proto values.  But we need
feedback on that point from people who understand what is now deployed
in the Internet.

Solution 2 is also reasonably sound from a design point of view, as
the proto value is allowed to modify the significance of the fmt
values in the m= line.  If do not use an encapsulating payload format,
then the payloads are a mix of various RTP payload formats and
SCTP-over-DTLS packets, and that mixture is not accurately described
by any of the defined proto values; defining a new proto value
allows the m= line to describe the situation accurately.

Solution 3 is the safest from a legacy interoperation point of view.
If bundling encapsulates all the constituent media packets, it is also
correct from a design point of view, as the encapsulation payload
format is the only payload type being sent (at this layer of the
stack).  But if bundling does not encapsulate RTP packets, then
providing only one encoding name is not correct from a design point of
view.  (Although the feedback I get is that SBCs are not very
particular about the encoding names and payload types in media
descriptions.)

How are we to handle this problem?  At this point, I favor defining a
new proto value, as it avoids the legacy SBC problems that I know of,
but also accurately describes the multiplexed packet stream.

Dale