Subject: Re: [MMUSIC] Unified Plan for SDP Handling

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

IMHO, correlation needs to be supported in an RTP extension as well as RTCP SDES, regardless of the SDP discussion. In WebRTC we shouldn't be wedded to SDP signalling and even if we are, the dynamism implied by simulcast and layered coding can't be accommodated in signalling.

Roni Even <[email-masked]> wrote:

Adam,
For correlation when the SSRC is not known in the SDP look at
http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the
option to use SDES and not only RTP header extension.

BTW: there are other cases when the SSRC is not known using SDP before the
RTP stream arrives like when an MCU switch the video. Note that SDES is
distributed to the session when the source joins the RTP session which can
be long before the RTP media is sent to a specific receiver in the group.

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