Subject: [MMUSIC] Difficulties accepting and rejecting with bundling

From: [email-masked] (Dale R. Worley)
Date: Sun, 10 Mar 2013 22:37:55 -0400 (EDT)

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

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 11 Mar 2013 18:21:36 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dale R. Worley

> 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.)
> 

Considering the following text from RFC 3264:

"Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled.  An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer."

There is no ambiguity here about the meaning of zero port.

While this text could be interpreted to not specifically preclude the peer that indicates an unspecified address from sending RTCP to the peer indicating a valid address, this seems really far-fetched to me.  Sending this RTCP would be pointless and wasteful since by definition it would have nothing to report on and there is no possibility to receive reports.  

If would be nice to eliminate this ambiguity by ending the quoted sentence "...neither RTP nor RTCP should be sent to either peer."

The text also says that the peer indicating an unspecified address "...doesn't know the addresses and ports at the time..."  Again, it seems like a real stretch to assume that the peer can send RTCP if it doesn't have an address or port available for receipt of RTP.

Richard

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Mar 2013 03:31:42 +0800

> If would be nice to eliminate this ambiguity by ending the quoted sentence "...neither RTP nor RTCP should be sent to either peer."

AFAIK it was never the intent that a zero address on one end would block 
media flow in the other direction.

	Thanks,
	Paul

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 11 Mar 2013 17:50:38 -0400 (EDT)

> From: "Ejzak, Richard P (Richard)" <[email-masked]>
> 
> "Of course, when used, the port number MUST NOT be zero, which would
> specify that the stream has been disabled.  An agent MUST be capable
> of receiving SDP with a connection address of 0.0.0.0, in which case
> it means that neither RTP nor RTCP should be sent to the peer."
> 
> While this text could be interpreted to not specifically preclude
> the peer that indicates an unspecified address from sending RTCP to
> the peer indicating a valid address, this seems really far-fetched
> to me.  Sending this RTCP would be pointless and wasteful since by
> definition it would have nothing to report on and there is no
> possibility to receive reports.  
> 
> If would be nice to eliminate this ambiguity by ending the quoted
> sentence "...neither RTP nor RTCP should be sent to either peer."
> 
> The text also says that the peer indicating an unspecified address
> "...doesn't know the addresses and ports at the time..."  Again, it
> seems like a real stretch to assume that the peer can send RTCP if
> it doesn't have an address or port available for receipt of RTP.

Sorry, I was hasty in writing the message.  What I should have said is

    (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 answerer to send RTCP.)
                                            ^^^^^^^^

The problem being that an offer with a real address and an answer with
a null address historically has meant that the answerer has put the
call on hold; the answerer is expected to send media to the offerer
but the offerer is not expected to send media to the answerer.  The
answerer is also expected to send RTCP, but of course the offerer
cannot send RTCP (as it has no address to send it to).

If the answerer specifies "a=inactive" with a real address, then
neither the offerer nor the answerer should send media, but both are
expected to send RTCP:

    RFC 4566, section 6, item "a=inactive"

      a=inactive

         This specifies that the tools should be started in inactive
         mode.  This is necessary for interactive conferences where
         users can put other users on hold.  No media is sent over an
         inactive media stream.  Note that an RTP-based system SHOULD
         still send RTCP, even if started inactive.  [...]

Combining the two techniques suppresses everything but expectation of
RTCP from the answerer to the offerer.

Unfortunately, I expect dialog-stateful SBCs to pay attention to that
RTCP in order to time out abandoned dialogs.

Dale

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 11 Mar 2013 22:35:18 +0000

Dale,

I don't think the hold argument below hold. 
More inline

Dale R. Worley wrote:
>>> 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.) 
>> 
> call on hold; 

In 2543 hold indicated by the offerer sending 0.0.0.0.
It would we awkward if I sent out a valid offer and being suddenly 
held by the answerer.
Further this pratice is no longer recommended since 3264, i.e. I don't we 
need to bother anymore.

I think from the cited text of 3264 it is clear what receipt of 0.0.0.0 
from the answerer means. 

Regards
Thomas

> the answerer is expected to send media to the offerer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 11 Mar 2013 22:52:45 +0000

Agreed that an endpoint signaling a valid address and port is required to be capable of receiving RTP and RTCP, irrespective of what is signaled by the peer.

But ICE cannot succeed without valid addresses/candidates from both endpoints.  Consent cannot be established without valid addresses from both endpoints.  Many systems require symmetric RTP, which also is not possible without valid addresses from both endpoints.  So if either endpoint signals an unspecified address, then packets will not usually be able to flow in either direction.

It is not reasonable (or intelligent) for any intermediate to time out a session for a lack of packet transmissions that cannot possibly occur (or at least that frequently cannot occur).  This is the only compatibility concern identified with the asymmetric use of the unspecified address, but this concern is clearly misplaced for rtcweb applications where ICE and consent are mandatory.

Richard

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Monday, March 11, 2013 4:51 PM
> To: Ejzak, Richard P (Richard)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Difficulties accepting and rejecting with
> bundling
> 
> may
> > > see the MD as being accepted and expect the offerer to send RTCP.)
> >
> > While this text could be interpreted to not specifically preclude the
> > peer that indicates an unspecified address from sending RTCP to the
> > peer indicating a valid address, this seems really far-fetched to me.
> > Sending this RTCP would be pointless and wasteful since by definition
> > it would have nothing to report on and there is no possibility to
> > receive reports.
> >
> > seems like a real stretch to assume that the peer can send RTCP if it
> > doesn't have an address or port available for receipt of RTP.
> 
> for
> call on hold; the answerer is expected to send media to the offerer but
> the offerer is not expected to send media to the answerer.  The

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 11 Mar 2013 21:02:32 -0400 (EDT)

> This is the only compatibility concern identified with the
> asymmetric use of the unspecified address, but this concern is
> clearly misplaced for rtcweb applications where ICE and consent are
> mandatory.

I'm not limiting my attention to WebRTC only.  Even in situations
where WebRTC is gatewayed to existing SIP infrastructure these
problems appear.  If we restrict ourselves to WebRTC, then we have
even more freedom, and in that case, I'd simply remove the rule
regarding rejects MDs as members of groups.

Dale

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 13 Mar 2013 12:38:24 -0700

I am just curios ... instead of playing with connection address and port
numbers for indicating accepting/rejecting a m=line in BUNDLE O/A, would
making a particular m=line direction inactive make things simpler ....
since for m=lines with direction as inactive would mean no ICE setup , no
reject port needed , no resource allocation on intermediary(?)

Any thoughts ?

./Suhas

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 13 Mar 2013 19:42:17 +0000

The direction attribute is one that needs to be preserved for each m line to indicate direction of the media associated with that m line.  It is just not available for other purposes.  Furthermore, inactive does not disable ICE or RTCP, which would still be expected to proceed.

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 2:38 PM
To: Dale R. Worley
Cc: Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [MMUSIC] Difficulties accepting and rejecting with bundling

I am just curios ... instead of playing with connection address and port numbers for indicating accepting/rejecting a m=line in BUNDLE O/A, would making a particular m=line direction inactive make things simpler ....
since for m=lines with direction as inactive would mean no ICE setup , no reject port needed , no resource allocation on intermediary(?)

Any thoughts ?

./Suhas
On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
> From: "Ejzak, Richard P (Richard)" <[email-masked]<mailto:[email-masked]>>
>

Dale
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 13 Mar 2013 13:24:59 -0700

Ah ! my bad, That's true

On Wed, Mar 13, 2013 at 12:42 PM, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

>  The direction attribute is one that needs to be preserved for each m
> line to indicate direction of the media associated with that m line.  It is
> just not available for other purposes.  Furthermore, inactive does not
> disable ICE or RTCP, which would still be expected to proceed.****
>
> ** **
>
> *From:* Suhas Nandakumar [mailto:[email-masked]]
> *Sent:* Wednesday, March 13, 2013 2:38 PM
> *To:* Dale R. Worley
> *Cc:* Ejzak, Richard P (Richard); [email-masked]
>
> *Subject:* Re: [MMUSIC] Difficulties accepting and rejecting with bundling
> ****
>
>  ** **
>
> making a particular m=line direction inactive make things simpler ....****
>
> reject port needed , no resource allocation on intermediary(?) ****
>
> ** **
>
> Any thoughts ?****
>
> ** **
>
> ./Suhas****
>
> On Mon, Mar 11, 2013 at 6:02 PM, Dale R. Worley <[email-masked]>
> wrote:****
>
> >****
> > mandatory.****
> regarding rejects MDs as members of groups.****
>
>
> Dale
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> ** **
>