IETF Logo Mail Archive

Re: [MMUSIC] Unified Plan for SDP Handling

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 16 July 2013 23:21 UTC

Return-Path: <bernard_aboba@hotmail.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 D821221F9D71 for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 16:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Level:
X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 s69LXUxNVkvL for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 16:21:47 -0700 (PDT)
Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by ietfa.amsl.com (Postfix) with ESMTP id 89C5821F9E28 for <mmusic@ietf.org>; Tue, 16 Jul 2013 16:21:46 -0700 (PDT)
Received: from BLU401-EAS2 ([65.55.111.72]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 16:21:46 -0700
X-TMN: [+pc7vRCC7QcYknPEK1YGTLacQzCSxO2h4IOb7HuV7Mw=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU401-EAS23CBB88519F32CC778A2993600@phx.gbl>
Date: Tue, 16 Jul 2013 16:21:43 -0700
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-OriginalArrivalTime: 16 Jul 2013 23:21:46.0115 (UTC) FILETIME=[3D49AD30:01CE827B]
Cc: mmusic@ietf.org
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 23:21:52 -0000

The app-id idea is useful for multiple reasons.  One reason similar RTP extensions are used today is to avoid having to parse the payload to figure out what the stream is (e.g. looking for parameter sets or SEI NAL units).  It is cleaner to solve this in as generic rather than a codec-specific way.  I see no conflict with no-plan; in fact, I believe no plan suggested an RTP extension, no?

Jonathan Lennox <jonathan@vidyo.com> wrote:


On Jul 16, 2013, at 4:38 PM, Adam Roach <adam@nostrum.com> wrote:

> On 7/16/13 15:28, Roni Even 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.
>
> Roni:
>
> Thanks for the pointer. That's an interesting approach; however, for
> RTCWEB at least, need a solution that also works with DTLS-SRTP.


Acronym collision: This uses RTCP Source Description packets, not SDP Security Descriptions.

I think the (related) app-id approach described in http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt will also be of interest.

--
Jonathan Lennox
jonathan@vidyo.com


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

v2.23.0 | Report a Bug | By Email