[MMUSIC] Difficulties accepting and rejecting with bundling

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

I believe that the current SDP grouping framework (RFC 5888) causes a
problem for the offer/answer operations of SDP bundling, and we need
to reconsider using SDP grouping, or alter the rules for SDP grouping.

Most of the bundling proposals have "constituent" media descriptions,
that is, m= lines that describe only components of the bundle, not the
bundle as a whole.  (In some proposals, these MDs are called
"subsequent" MDs, because the first MD in the bundle is used to
describe the bundle as a whole.  In other proposals, there is a
separate MD for the bundle as a whole, and all of the components of the
bundle are "constituent" MDs.)

Generally, a constituent MD is offered like this:

	c=10.1.1.1

        a=group:BUNDLE bundle con1 con2 ...

        m=audio 10002 RTP/AVP 0 8
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

The MD is declared to be part of a bundle by a "group" attribute, and
the MD provides a transport address and port.  For backward
compatibility with answerers that do not support bundling, most
proposals require that the address and port of the MD are a real
transport address of the offerer.

If the answerer wishes the reject the constituent MD, it responds
like this:

	c=10.1.1.1

        a=group:BUNDLE bundle con2 ...

        m=audio 0 RTP/AVP 0 8
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

(If the answerer does not support bundling at all, it removes the
group attribute.  But if it supports bundling, it may want to accept
other parts of the bundle and yet reject this MD, so it will include
the group attribute for the bundle.)

The port number is zero.  Due to RFC 5888 section 9.2, the mid of this
MD MUST be removed from the group attribute describing this bundle.
That fact isn't interesting here, but it will become more important
later in this discussion.

If the answerer wishes to accept the constituent MD not as part of the
bundle (perhaps because the answerer does not support bundling), it
responds like this:

	c=10.1.1.1

        m=audio 20002 RTP/AVP 0 8
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

The group attribute is omitted (showing that the bundle is not
accepted) and a transport address of the answerer is provided.

Note that both of these answer patterns are determined by "legacy" SDP
processing rules, and we are not free to change them.

If the answerer wishes to accept the constituent MD as part of the
bundle, how should it respond?

The natural method is something like this:

	c=10.1.1.1

        a=group:BUNDLE bundle con1 con2 ...

        m=audio 0 RTP/AVP 0 8
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

We want to include the constituent MD in the group attribute, in order
to show that it is part of the bundle.

However, we want to answer with a zero port number so that
intermediate entities will not be expecting media on this transport
association.  If an intermediate entity believes that a valid
transport association has been established, the entity may time out
the multimedia session when it does not see media.  (It does not
suffice for the answerer to provide a null transport address and
non-zero port for the MD, or for the answerer to send "a=inactive", as
an intermediate entity may see the MD as being accepted and expect the
offerer to send RTCP.)

But if the m= line has a zero port number, RFC 5888 section 9.2
requires that the MD's mid label not be included in the group
attribute.  This prevents the answerer from signaling that the MD has
been accepted, but that the media is sent within the bundle, not on a
separate transport association.

Seven of the nine proposals cataloged in draft-worley-sdp-bundle-05
section 7 have this problem.  Currently, only way to avoid this
problem is the answerer provides a non-zero port with a null transport
address, and then the offerer provides an immediate SDP update that
provides a non-zero port with a null transport address.  After that,
intermediate entities will be warned that they might not see media on
the transport association (as both endpoints seem to be managing
third-party entities).

But a better solution is to allow the answerer to accept the
constituent MD as part of the bundle, while at the same time giving a
zero port, thus rejecting the constituent MD from a "legacy" point of
view.  Signaling the acceptance within the bundle is easy enough; we
can define a new attribute for doing so:

	c=10.1.1.1

        a=group:BUNDLE bundle con1 con2 ...

        m=audio 0 RTP/AVP 0 8
	a=bundle-accept
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

The difficulty is how to indicate that the MD is part of the bundle.
There are at least four choices:

1. The membership of the MD in the bundle is not signaled in the
answer; it is implied by the signaling in the offer.

	c=10.1.1.1

        m=audio 0 RTP/AVP 0 8
	a=bundle-accept
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

2. We define a new grouping attribute for signaling bundling, one
which does not have the restriction that MDs with zero port numbers
may not appear in the group.

	c=10.1.1.1

        a=relaxed-group:BUNDLE bundle con1 con2 ...

        m=audio 0 RTP/AVP 0 8
	a=bundle-accept
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

3. We define an attribute for signaling bundle membership in some
other way.  E.g., a pointer from the constituent MD to the bundle MD:

	c=10.1.1.1

        m=audio 0 RTP/AVP 0 8
	a=bundle-owner:bundle
	a=bundle-accept
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

where the bundle MD is:

	m=audio 15000 RTP/AVP 0 8
        a=mid:bundle

4. We normatively relax RFC 5888 section 9.2 to allow MDs with zero
port numbers to appear in group attributes.  (This would only have
meaning for BUNDLE groups, not LS and FID groups.)

	c=10.1.1.1

        a=group:BUNDLE bundle con1 con2 ...

        m=audio 0 RTP/AVP 0 8
	a=bundle-accept
        a=mid:con1
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000

At this point, I prefer the fourth choice, updating RFC 5888.  Would
this likely cause any backward compatibility problems?

Dale