Re: [MMUSIC] Unified Plan for SDP Handling

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 <ron.even.tlv@gmail.com> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Adam Roach
> Sent: 15 July, 2013 10:05 PM
> To: mmusic@ietf.org
> Cc: rtcweb@ietf.org
> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

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