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

Bernard Aboba <> Wed, 17 July 2013 05:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 546F221F84A8 for <>; Tue, 16 Jul 2013 22:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p9VT9UxzYpl9 for <>; Tue, 16 Jul 2013 22:07:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E331921F92C2 for <>; Tue, 16 Jul 2013 22:07:35 -0700 (PDT)
Received: from BLU404-EAS239 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 22:07:32 -0700
X-TMN: [/FNtsQdOUAk0OFKr8CEtHsYhko8QftNm]
X-Originating-Email: []
Message-ID: <BLU404-EAS239F8A08169E5647100494293610@phx.gbl>
Content-Type: multipart/related; boundary="_c1325d40-388e-408f-bc52-82bf96fd61c7_"
Date: Tue, 16 Jul 2013 22:07:29 -0700
From: Bernard Aboba <>
To: Adam Roach <>
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Jul 2013 05:07:32.0786 (UTC) FILETIME=[8B447120:01CE82AB]
Cc: Jonathan Lennox <>,
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jul 2013 05:07:44 -0000

Indeed, unless the RTP extension is self-describing it has to be chosen by the receiver in order to provide guidance to the receiver before an answer arrives.  If it is opaque and chosen by the sender it isn't all that different from an SSRC chosen by the sender and potentially signalled in the answer.

Adam Roach <> wrote:

On 7/16/13 17:46, Jonathan Lennox wrote:
> Have you read  ?  This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan.

Thanks for the pointer -- I had missed this.

On a first read, this proposal seems to be backwards from what we need.
The token scoping appears to be summed up by the following passage:

    The token is chosen by the sender, and represents the RTP stream that
    will be sent to the receiver.

What we need is a token chosen by the *receiver* representing what will
be sent to the receiver. The crux of the matter is that the recipient
may start receiving an RTP stream prior to receiving any signaling from
the far end that can be used to correlate a token to the stream. We need
to include something in an offer that allows us to correlate streams
*before* the answer arrives.

That's not to say we couldn't add such functionality to this draft. But,
unless I've completely misunderstood the meaning of the passage I quote
above, the current application token proposal doesn't solve the clipping
problem that we're trying to avoid.

mmusic mailing list