IETF Logo Mail Archive

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

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 18 July 2013 03:35 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 1042F21F9A5F for <mmusic@ietfa.amsl.com>; Wed, 17 Jul 2013 20:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XLmz8BiUKSHB for <mmusic@ietfa.amsl.com>; Wed, 17 Jul 2013 20:35:02 -0700 (PDT)
Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1980621F9655 for <mmusic@ietf.org>; Wed, 17 Jul 2013 20:35:02 -0700 (PDT)
Received: from BLU169-W26 ([65.55.111.136]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 20:35:02 -0700
X-TMN: [UvhbByk067HEg/ekNTBY7vRjDA6aJFlc]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W26C4E9085CBD88AE55060F93620@phx.gbl>
Content-Type: multipart/alternative; boundary="_ca3bc5a5-325a-4274-b533-777b1bdfdfbf_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 17 Jul 2013 20:35:01 -0700
Importance: Normal
In-Reply-To: <CABkgnnVVFxYtMcn06iS1J7_4PaLsEXwCcy-OWG6CmWsFXRsNKg@mail.gmail.com>
References: <00ad01ce826e$43666300$ca332900$@gmail.com>, <CABkgnnVWL71QPOjqxXJCEr1NK93JOwpmY_CgiObpcUdfaDk2jA@mail.gmail.com>, <AE206958-4085-4B6C-A747-D4D60C5CD7FE@vidyo.com>, <51E61C99.8040305@nostrum.com>, <A0791C6A-9F74-4FA6-BD6B-FCBAF9A5E966@vidyo.com>, <51E71052.7010206@nostrum.com>, <CABkgnnVVFxYtMcn06iS1J7_4PaLsEXwCcy-OWG6CmWsFXRsNKg@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jul 2013 03:35:02.0211 (UTC) FILETIME=[C947A930:01CE8367]
Cc: Jonathan Lennox <jonathan@vidyo.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources
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: Thu, 18 Jul 2013 03:35:15 -0000

Martin said: 

> I did consider this, but there are several reasons that I prefer to have signaling.  
 
[BA] The RTP Extension is by definition, optional.  So it cannot be used instead of initial signaling, because of reliability issues (same issue applies with SDES packets) and because it might not be there.  However, in the event of an SSRC collision it can be useful.  Also,  RTP extensions are deployed today to label temporal, spatial or quality scalability streams, so that the SRTP packets don't have to be decrypted and parsed before figuring out what layer they pertain to.

v2.23.0 | Report a Bug | By Email