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