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

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jul 2013 16:29:22 -0700

Yes, it is annoying when new docs attempt to redefine behavior in existing deployed RFCs.  RFC 5576 has multiple implementations today, and none of them have a one-at-a-time restriction.

The problem with max-send-ssrc is that it conflates ssrcs with streams. If you have layering or simulcast you need to have something like max-streams and max-sources. max-send-ssrc is confusing.

Roni Even <[email-masked]> wrote:

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

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

---

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

On 7/16/13 18:29, Bernard Aboba wrote:
> Yes, it is annoying when new docs attempt to redefine behavior in existing deployed RFCs.

And it's annoying when people try to comment on a proposal based solely 
on the mailing list discussion as opposed to reading the document in 
question.

Let's set the mudslinging aside for a moment.

>    RFC 5576 has multiple implementations today, and none of them have a one-at-a-time restriction.

Roni was confused, and you're riffing off his confusion. His comment was 
on the second bullet of section 2, which tries to clear up historical 
ambiguity by defining clear semantics for what it means to have multiple 
SSRCs specified in a single m-line IN THE ABSENCE of any signaling 
indicating their purpose.

Now, this clarification is nearly meaningless outside the context of the 
*first* bullet of section 2, which explains that each m-line corresponds 
to exactly one media stream track. I suppose it is this context you are 
missing, because I've worked with you in the past and know that you're 
smart enough to connect these dots and arrive at the conclusion that the 
second bullet, combined with the constraint imposed by the first bullet, 
is making things better, not worse.

In case we need to connect the dots for other working group 
participants, I'll be explicit. There are quite a number of use cases in 
which it is perfectly reasonable to have several SSRCs associated with a 
single media stream track, all of which are sent simultaneously. 
However, without explicit signaling (" Absent any other signaled 
extension", to use the exact phrase from the draft), there is very 
little hope of recipients having the first clue about what to do with 
these simultaneous streams all associated with the same media stream 
track. So we don't allow that, in general.

There's an exception, and it ties back to legacy use. In the 
preponderance of legacy cases in which a single m-line (historically, 
transport 5-tuple) was associated with multiple SSRCs, these multiple 
streams were sent in an exclusive (that is, non-parallel, one-at-a-time) 
fashion, and were meant to replace each other [1]. To maximize 
interoperability with legacy systems, the draft takes this 
(traditionally non-signaled) behavior and makes it the default when 
multiple SSRCs are present but not otherwise explained by the signaling. 
The bullet we're discussing requires signaling for all other uses; and, 
in doing so, effectively forbids multiple SSRCs only in the cases where 
sending them would be undefined or ambiguous.

If you don't think this course of action is a wise decision, please 
weigh in on the semantics you think should be implied when several SSRCs 
are present for a single media stream track without explicit signaling 
about their purpose. It's certainly something that I'd be happy to 
engage in useful discussion around. We had what I think is sound logic 
behind our choice, but there's no way we thought of everything. Your 
insights may be useful. However, simply sniping that you don't like this 
aspect of the proposal is counter to the goal (which I hope you share) 
of making progress.

/a

___
[1] I recognize that this observation about common historical behavior 
is based on my own experiences dealing with an admittedly limited set of 
products, and does not represent an exhaustive survey of the entire 
implementaion space. I'd love to hear what other people's observations 
of implementations' intended semantics when multiple SSRCs are present 
for a single logical stream without any signaling as to their purpose.