Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Jul 2013 00:48:50 +0300

Hi,
Some comments. 
In section 2 bullet 2 is changing RFC 5576 semantics and not for good. Why
do you want more than one SSRC for m-line but allow only one at a time, is
this for the simulcast case?

Others which are not on section 2

1. The document talks about the case when there are multiple participants
each sending multiple streams as mentioned in section 1.1.1 and the receiver
may want to select among all these sources as discussed in section 1.1.2.
The document focus on the point to point case and does not address the issue
of how all the m-lines from all participants are distributes and how a late
joiner gets all this information.

2. In the examples using the ssrc attribute note that according to RFC 5576
section 4.1 you must provide for each SSRC the CNAME attribute

3. The simulcast example and description allows the case of sending one of
the resolutions at a time but in simulcast the source may be able to send
multiple resolutions at the same time. To further complicate this case the
offer can support three resolutions but can only send any two at a time
which the receiver can select. How do you signal this, my view is with the
maxsendssrc attribute.

4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an
integer) used for correlation;" I think that it must be a byte string or
token not integer

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adam Roach
> Sent: 15 July, 2013 10:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] Unified Plan for SDP Handling
> 
> [Cross-posting to RTCWEB; follow-ups to MMUSIC, please]
> 
> After significant work, Justin, Martin and I have managed to produce a
> compromise plan that provides a high degree of interoperability with
existing
> devices (and future non-WebRTC devices) while not being excessively
> onerous for WebRTC implementations or applications that use them. It's
> been a tricky balancing act, but I think we've found a good mix between
the
> two that can form a solid basis for the working group to move forward.
> 
> Rather than summarize the key points of the document in this email, I
direct
> interested parties to section 2 of the document, which summarizes the key
> aspects of the plan in eight relatively concise bullet points.
> 
> I apologize for the late publication date of this document -- there's
actually
> been a lot more work put into coming up with a unified draft than I
originally
> anticipated, and the production of this document took at least two weeks
> longer than I expected it to.
> 
> Note that this document is intended to be a plan for the work to be done
in
> this area, and not a specification in itself. The intention is that its
contents are
> used as the basis for work in several other drafts -- some new, some not
--
> that form the corpus of work necessary for RTCWEB (and potentially CLUE)
to
> move forward. Except in rare cases, the document does not attempt to
> explicitly call out venues or documents for such work, as we (or, at the
very
> least, I) anticipate guidance from the various working group chairs to
assist in
> such decisions.
> 
> Comments prior to Berlin would be very helpful, although this will clearly
be a
> point of significant discussion at the face-to-face meeting.
> 
> Document link:
> 
> http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt
> 
> /a
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jul 2013 15:12:29 -0700

Hi Roni,

> this for the simulcast case?

The text includes "Absent any other signaled extension, [...]" for
exactly that reason.  The plan is to include a specific extension for
simulcast, layering and FEC that would avoid this specific problem.

> joiner gets all this information.

The assumption is that there is always a point-to-point leg that is
being negotiated.  That doesn't remove the need to combine information
from a multi-party session into a single description.

> which the receiver can select. How do you signal this, my view is with the

(Full disclosure, I didn't keep track of the changes in this area
effectively, my views may differ from Adam and Justin on this point.)

The combination of FID grouping and the newly defined SIMULCAST
grouping might provide enough information.  In that way, I can suggest
that I don't want to see both A and C at the same time, even though
A+B or B+C might be OK.

I'd rather not rely on maxsendssrc, which is based on a very different
set assumption on the meaning of an m-line to what this document
describes.

> integer) used for correlation;" I think that it must be a byte string or

There have been serious concerns raised regarding size of packets,
even though the header extension is not sent on many packets.  While
it's true that a 16-bit identifier is restrictive, but you'll need to
motivate a size increase a little better than that.

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2013 17:25:39 -0500

> this for the simulcast case?

No, simulcast is signaled explicitly (I will point out and emphasize the 
phrase "absent any other signaled extension"). This is "default 
behavior" is intended to accommodate MCUs that perform packet switching 
for RTP (and similar architectures that require different timing and/or 
sequence number spaces on a single stream).

> joiner gets all this information.

The intention is that these changes to the session be explicitly 
described via SDP.

> section 4.1 you must provide for each SSRC the CNAME attribute

I think we had that in some early examples, but they were later removed. 
I agree that the text in 5576 requires its presence, and see no reason 
not to add it to the examples.

> multiple resolutions at the same time.

The intention is definitely that sending multiple resolutions in 
parallel would be facilitated. Do you see any specific text prohibiting 
doing so, or is this fallout from your misunderstanding of section 2 
bullet 2?

> integer) used for correlation;" I think that it must be a byte string or

Do you have some rationale for your assertion?

The goal here is to limit expansion of the RTP packets as much as 
possible. Given that there is a natural limit of 65536 streams in a 
single RTP session, 16 bits for a correlator seems sufficient.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2013 17:36:05 -0500

> single RTP session, 16 bits for a correlator seems sufficient.

Gack. I had crosswired some bytefield lengths in my brain here. SSRCs 
are 32 bits, not 16. I'm game for increasing the size to 32 bits for the 
correlator if we really think we need more than 64k streams in a session 
-- but I'm going to ask for some justification if someone makes that 
argument.

/a

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 16 Jul 2013 18:46:29 -0400

> motivate a size increase a little better than that.

Have you read http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt ?  This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan.

The important difference the version of the idea presented in application-token, and the version in Unified is, I think, to the fact that once you have the correlator (app-id) signaled in SDP, you no longer *need* the SSRC to also be signaled -- the correlation can be done entirely based on the app-id, if you so desire.  This gives you a lot more flexibility, with less need for a fresh offer-answer when something changes.

In app-id, we chose to use a token, rather than an integer, for this field.  One important reason for this is that it's useful to be able to send this identifier in RTCP SDES[*] packets, so you can pre-announce correlations before sending media; however, SDES fields are defined by RFC 3550 as UTF-8 strings.  (There are also some RTP architectural-cleanliness reasons for having the primary location for the correlator be in RTCP, with the header extension being a rapid-convergence optimization.) 

[*note: RTCP "SDES" (Source Description) packets are entirely unrelated to SDP "SDES" (Security Description) SRTP key exchange; this is an unfortunate acronym collision.]

Both RFC 5285 header extensions and RTCP SDES fields are length-delimited, so making the app identifiers be variable-length has no intrinsic packet overhead cost.  A sender is always free to choose short identifiers.  (Probably the spec should make short identifiers RECOMMENDED.)  It adds a bit of implementation complexity, but it doesn't seem like very much compared with all the rest of an RTP pipeline.

--
Jonathan Lennox
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jul 2013 15:57:30 -0700

> Have you read http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt ?  This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnost…

I have read that draft.  I don't see any major problems with it.  That
is, aside from some serious ugliness when it comes to no-plan to the
extent that I don't believe it to be practical (if I've understood the
intent).

My current leaning is toward a (small) number if the unified plan is
chosen, simply because so much else depends on the existence of
signaling; a no-plan-style approach would provide greater motivation
for having all the bits present.  That said, I don't have enough
information yet to be able to make the header extension size vs. need
for signaling trade-off.

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2013 23:24:57 -0500

On 7/16/13 17:46, Jonathan Lennox wrote:
> Have you readhttp://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt  ?  This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan.

Thanks for the pointer -- I had missed this.

On a first read, this proposal seems to be backwards from what we need. 
The token scoping appears to be summed up by the following passage:

    The token is chosen by the sender, and represents the RTP stream that
    will be sent to the receiver.

What we need is a token chosen by the *receiver* representing what will 
be sent to the receiver. The crux of the matter is that the recipient 
may start receiving an RTP stream prior to receiving any signaling from 
the far end that can be used to correlate a token to the stream. We need 
to include something in an offer that allows us to correlate streams 
*before* the answer arrives.

That's not to say we couldn't add such functionality to this draft. But, 
unless I've completely misunderstood the meaning of the passage I quote 
above, the current application token proposal doesn't solve the clipping 
problem that we're trying to avoid.

/a

---

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Jul 2013 07:24:53 +0300

Hi,
> > integer) used for correlation;" I think that it must be a byte string
> > or token not integer
> 
possible.
> Given that there is a natural limit of 65536 streams in a single RTP
session, 16
> bits for a correlator seems sufficient.
> 
> /a
[Roni Even] This is the syntax of the header extension and
extensionattributes in RFC5285. It is a byte string and not an integer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Jul 2013 08:34:34 +0300

I think that the problem in bullet 2 of section 2  when reading bullet 1 is
that it is not clear. Bullet 1 says "nor may a single m-line    represent
multiple media stream tracks".  Since there is no definition of media stream
track in this document and of source I looked at section 2.3 of
http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01
which tries to clarify the terminology based on existing documents. 
To me even though bullet 2 says "in the absent of other signaled extension"
it will be not correct according to bullet 1 to have one m-line that have
multiple sources (according to my reading of the taxonomy source and media
stream track are equivalent)

As for "although senders can   switch between the SSRCs as frequently as
desired, only one    should be sent at any given time." It got me confused,
in simulcast  does it mean that a sender can send one packet of one
resolution followed by a packet of a second resolution each has a unique
SSRC but they should have a different timestamp. What is "at any given
time"?

Roni

> From: Adam Roach [mailto:[email-masked]]
> Sent: 17 July, 2013 1:26 AM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media
> sources
> 
> > In section 2 bullet 2 is changing RFC 5576 semantics and not for good.
> > Why do you want more than one SSRC for m-line but allow only one at a
> > time, is this for the simulcast case?
> 
phrase
> "absent any other signaled extension"). This is "default behavior" is
intended
> to accommodate MCUs that perform packet switching for RTP (and similar
> architectures that require different timing and/or sequence number spaces
> on a single stream).
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Jul 2013 00:52:21 -0500

On Jul 17, 2013, at 0:34, "Roni Even" <[email-masked]> wrote:

> in simulcast...

This bullet has no bearing on simulcast behavior, other than to say that simulcast must be explicitly signaled.

/a

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 17 Jul 2013 17:40:11 -0400

On Jul 17, 2013, at 12:24 AM, Adam Roach <[email-masked]> wrote:

> What we need is a token chosen by the *receiver* representing what will be sent to the receiver. The crux of the matter is that the recipient may start receiving an RTP stream prior to receiving any signaling from the far end that can be used to correlate a token to the stream. We need to include something in an offer that allows us to correlate streams *before* the answer arrives.
> 
> That's not to say we couldn't add such functionality to this draft. But, unless I've completely misunderstood the meaning of the passage I quote above, the current application token proposal doesn't solve the clipping problem that we're trying to avoid.

Ah, interesting.  The problem case is an offerer offering a new bundled sendrecv or recvonly m-line, where the answerer can start sending media for it immediately, outracing the answer?

Yes, I see how a receiver-chosen correlator solves that case.

That said, what I still don't see is, if you have the correlator, why you then actually need to send the a=ssrc in the SDP at all? The correlator should be sufficient for disambiguation, and it lets the sender switch the ssrc it's sending for an m-line without needing a fresh offer/answer.

(The use case I'm thinking about here is something like the CLUE "dynamic capture" in the context of what Magnus named the "Source-projecting mixer" topology -- where the ssrc sent for a given m-line switches dynamically and quickly, e.g. with loudest-speaker switching.)

--
Jonathan Lennox
[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Jul 2013 16:44:50 -0500

> That said, what I still don't see is, if you have the correlator, why you then actually need to send the a=ssrc in the SDP at all? The correlator should be sufficient for disambiguation, and it let…

That might be worth exploring. I honestly haven't given it a whole lot 
of thought. Perhaps Justin or Martin have a more well-formed opinion on 
the topic?

/a

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jul 2013 19:21:21 -0700

On 17 July 2013 14:44, Adam Roach <[email-masked]> wrote:
>> That said, what I still don't see is, if you have the correlator, why you
>> then actually need to send the a=ssrc in the SDP at all? The correlator
>> should be sufficient for disambiguation, and it lets the sender switch the
>> ssrc it's sending for an m-line without needing a fresh offer/answer.
>
>
> That might be worth exploring. I honestly haven't given it a whole lot of
> thought. Perhaps Justin or Martin have a more well-formed opinion on the
> topic?

I did consider this, but there are several reasons that I prefer to
have signaling.  The main one being that it is the only guaranteed way
to get this information through.  In the happy cases, the RTP header
is enough, but if you are losing packets at session startup (a real
possibility in some configurations), or RTP header extensions are
being dropped, or you need to communicate about an in progress stream
and can't guarantee that you can cause the sender to re-send a few
packets with the header extension, or ...

Basically, there are too many ways for the RTP extension to break.
Not enough that it isn't hugely valuable for dealing with the race,
but it can't be the only mechanism that you rely on.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Jul 2013 20:35:01 -0700

Martin said: 

> I did consider this, but there are several reasons that I prefer to have signaling.  
 
[BA] The RTP Extension is by definition, optional.  So it cannot be used instead of initial signaling, because of reliability issues (same issue applies with SDES packets) and because it might not be there.  However, in the event of an SSRC collision it can be useful.  Also,  RTP extensions are deployed today to label temporal, spatial or quality scalability streams, so that the SRTP packets don't have to be decrypted and parsed before figuring out what layer they pertain to.

---

From: "Roni Even" <[email-masked]>
Date: Fri, 19 Jul 2013 09:13:48 +0300

> Behalf Of Martin Thomson
> Sent: 18 July, 2013 5:21 AM
> To: Adam Roach
> Cc: Jonathan Lennox; [email-masked]
> >> That said, what I still don't see is, if you have the correlator, why
> >> you then actually need to send the a=ssrc in the SDP at all? The
> >> correlator should be sufficient for disambiguation, and it lets the
> >> sender switch the ssrc it's sending for an m-line without needing a
fresh
> offer/answer.
> > of thought. Perhaps Justin or Martin have a more well-formed opinion
> > on the topic?
> 
> I did consider this, but there are several reasons that I prefer to have
> signaling.  The main one being that it is the only guaranteed way to get
this
> information through.  In the happy cases, the RTP header is enough, but if
> you are losing packets at session startup (a real possibility in some
> configurations), or RTP header extensions are being dropped, or you need
to
> communicate about an in progress stream and can't guarantee that you can
> cause the sender to re-send a few packets with the header extension, or
...
> Not enough that it isn't hugely valuable for dealing with the race, but it
can't
> be the only mechanism that you rely on.
[Roni Even]  One of the reasons we have also SDES message with the ID is
because the header extension is optional and can be removed on the path.

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Jul 2013 17:08:24 -0500

> extensionattributes in RFC5285. It is a byte string and not an integer

Forgive the imprecision in the draft. What we mean to say is something 
along the lines of "a 16-bit identifier, expressed as an integer in the 
SDP, encoded in the RTP header as a two-byte byte string, in network 
byte order."

I apologize for the confusion. I thought this much would be obvious 
without needing to spell it out explicitly.

/a