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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92E5821F9B2A for <>; Tue, 16 Jul 2013 21:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 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 cceNGkQ2zfw7 for <>; Tue, 16 Jul 2013 21:13:03 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 6D72921F8C0C for <>; Tue, 16 Jul 2013 21:13:03 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r6H4CtYk056826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 23:12:56 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Tue, 16 Jul 2013 23:12:50 -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: Bernard Aboba <>
References: <BLU401-EAS46E4A7B1B6E70D598F788B93600@phx.gbl>
In-Reply-To: <BLU401-EAS46E4A7B1B6E70D598F788B93600@phx.gbl>
Content-Type: multipart/alternative; boundary="------------070802000300070903020003"
Received-SPF: pass ( is authenticated by a trusted mechanism)
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:13:04 -0000

On 7/16/13 18:29, Bernard Aboba wrote:
> Yes, it is annoying when new docs attempt to redefine behavior in existing deployed RFCs.

And it's annoying when people try to comment on a proposal based solely 
on the mailing list discussion as opposed to reading the document in 

Let's set the mudslinging aside for a moment.

>    RFC 5576 has multiple implementations today, and none of them have a one-at-a-time restriction.

Roni was confused, and you're riffing off his confusion. His comment was 
on the second bullet of section 2, which tries to clear up historical 
ambiguity by defining clear semantics for what it means to have multiple 
SSRCs specified in a single m-line IN THE ABSENCE of any signaling 
indicating their purpose.

Now, this clarification is nearly meaningless outside the context of the 
*first* bullet of section 2, which explains that each m-line corresponds 
to exactly one media stream track. I suppose it is this context you are 
missing, because I've worked with you in the past and know that you're 
smart enough to connect these dots and arrive at the conclusion that the 
second bullet, combined with the constraint imposed by the first bullet, 
is making things better, not worse.

In case we need to connect the dots for other working group 
participants, I'll be explicit. There are quite a number of use cases in 
which it is perfectly reasonable to have several SSRCs associated with a 
single media stream track, all of which are sent simultaneously. 
However, without explicit signaling (" Absent any other signaled 
extension", to use the exact phrase from the draft), there is very 
little hope of recipients having the first clue about what to do with 
these simultaneous streams all associated with the same media stream 
track. So we don't allow that, in general.

There's an exception, and it ties back to legacy use. In the 
preponderance of legacy cases in which a single m-line (historically, 
transport 5-tuple) was associated with multiple SSRCs, these multiple 
streams were sent in an exclusive (that is, non-parallel, one-at-a-time) 
fashion, and were meant to replace each other [1]. To maximize 
interoperability with legacy systems, the draft takes this 
(traditionally non-signaled) behavior and makes it the default when 
multiple SSRCs are present but not otherwise explained by the signaling. 
The bullet we're discussing requires signaling for all other uses; and, 
in doing so, effectively forbids multiple SSRCs only in the cases where 
sending them would be undefined or ambiguous.

If you don't think this course of action is a wise decision, please 
weigh in on the semantics you think should be implied when several SSRCs 
are present for a single media stream track without explicit signaling 
about their purpose. It's certainly something that I'd be happy to 
engage in useful discussion around. We had what I think is sound logic 
behind our choice, but there's no way we thought of everything. Your 
insights may be useful. However, simply sniping that you don't like this 
aspect of the proposal is counter to the goal (which I hope you share) 
of making progress.


[1] I recognize that this observation about common historical behavior 
is based on my own experiences dealing with an admittedly limited set of 
products, and does not represent an exhaustive survey of the entire 
implementaion space. I'd love to hear what other people's observations 
of implementations' intended semantics when multiple SSRCs are present 
for a single logical stream without any signaling as to their purpose.