Re: [MMUSIC] Unified Plan for SDP Handling
"Roni Even" <ron.even.tlv@gmail.com> Tue, 16 July 2013 20:30 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B864921F9EC2 for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 13:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skknqzrlpt1d for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 13:30:29 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4021F9E98 for <mmusic@ietf.org>; Tue, 16 Jul 2013 13:30:27 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hq4so1155570wib.14 for <mmusic@ietf.org>; Tue, 16 Jul 2013 13:30:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=4Cd2xRRoBWArS0Kpa9V7txbyU0q1yay2dZbe8JNHF2c=; b=gEct7TGUVr1IdOsVNPokeiCNGle+hSuFLjhXqTs9/0KSqmmakwkIYlxppzxPw+WaFL zdjx/4KsaXU4Hf6VjzqpWYF456ehlFpxz7VpGS/riOltQVXNpCZhYDXK0sI8xPmOiC1X 3NdZ2p5xDwJuhZTJS4CmlVOOI7+VKCQgGdx6gNb7s1CDJLlIjyeeGjzlkXhHHProkoW6 ANBzBmvEQc2H9ar4hbIVfzj9RZSfK8zd9oBpRaN5a4HBf+8nr4SUwgXaguR47aaq4LbT F4wGNZbQLkc01e7U5BCQy6vWRwo3nmDLuurEOBaVZq3ujOMPAgj0XAyVctxJsFBuHZTO JYMA==
X-Received: by 10.194.9.101 with SMTP id y5mr2457441wja.86.1374006626755; Tue, 16 Jul 2013 13:30:26 -0700 (PDT)
Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id r8sm4963085wiy.8.2013.07.16.13.30.25 for <mmusic@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 13:30:26 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: mmusic@ietf.org
References: <51E447C8.1000701@nostrum.com>
In-Reply-To: <51E447C8.1000701@nostrum.com>
Date: Tue, 16 Jul 2013 23:28:37 +0300
Message-ID: <009001ce8263$0ed498b0$2c7dca10$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGN3Ok6C3zH+O6O1w6NRgFPJ+xPXJnpBllA
Content-Language: en-us
Subject: Re: [MMUSIC] Unified Plan for SDP Handling
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 20:30:31 -0000
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: 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
- Re: [MMUSIC] Unified Plan for SDP Handling Jonathan Lennox
- [MMUSIC] Unified Plan for SDP Handling Adam Roach
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Roman Shpount
- Re: [MMUSIC] Unified Plan for SDP Handling Roni Even
- Re: [MMUSIC] Unified Plan for SDP Handling Adam Roach
- Re: [MMUSIC] Unified Plan for SDP Handling Bernard Aboba
- Re: [MMUSIC] Unified Plan for SDP Handling Emil Ivov
- Re: [MMUSIC] Unified Plan for SDP Handling Bernard Aboba
- Re: [MMUSIC] Unified Plan for SDP Handling Roni Even
- Re: [MMUSIC] Unified Plan for SDP Handling Stefan Håkansson LK
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Paul Kyzivat
- Re: [MMUSIC] Unified Plan for SDP Handling Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Adam Roach
- Re: [MMUSIC] Unified Plan for SDP Handling Adam Roach
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Harald Alvestrand
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Harald Alvestrand
- Re: [MMUSIC] Unified Plan for SDP Handling - msid… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] Unified Plan for SDP Handling Bernard Aboba
- Re: [MMUSIC] Unified Plan for SDP Handling Justin Uberti
- Re: [MMUSIC] Unified Plan for SDP Handling Cullen Jennings
- Re: [MMUSIC] Unified Plan for SDP Handling Cullen Jennings
- Re: [MMUSIC] Unified Plan for SDP Handling Jonathan Lennox
- Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handli… Matt Fredrickson
- Re: [MMUSIC] Unified Plan for SDP Handling Stefan Håkansson LK