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

Adam Roach <> Wed, 17 July 2013 04:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E34EB21F9B5D for <>; Tue, 16 Jul 2013 21:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8e2Gj-2Qps2J for <>; Tue, 16 Jul 2013 21:25:19 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 23D8721F9A98 for <>; Tue, 16 Jul 2013 21:25:07 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r6H4P2gt058078 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 23:25:03 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Tue, 16 Jul 2013 23:24:57 -0500
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Jonathan Lennox <>
References: <00ad01ce826e$43666300$ca332900$> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080808080407000601010105"
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: "" <>
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 04:25:21 -0000

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.