[MMUSIC] Comments on draft-westerlund-mmusic-max-ssrc-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 01 November 2012 23:04 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 99D5B21F9503 for <mmusic@ietfa.amsl.com>; Thu, 1 Nov 2012 16:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.39
X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QF2Q0i4QMQMg for <mmusic@ietfa.amsl.com>; Thu, 1 Nov 2012 16:04:03 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B421F94F0 for <mmusic@ietf.org>; Thu, 1 Nov 2012 16:04:02 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([]) by qmta03.westchester.pa.mail.comcast.net with comcast id JANw1k0041ZXKqc53P47Q6; Thu, 01 Nov 2012 23:04:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by omta21.westchester.pa.mail.comcast.net with comcast id JP5H1k00V3ZTu2S3hP5Hdq; Thu, 01 Nov 2012 23:05:17 +0000
Message-ID: <5092FFE0.6080304@alum.mit.edu>
Date: Thu, 01 Nov 2012 19:04:00 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: IETF MMUSIC WG <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Comments on draft-westerlund-mmusic-max-ssrc-00
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, 01 Nov 2012 23:04:04 -0000

I just reviewed this and have some comments:

In Section 4.4 on o/a usage, *an* offerer must use this mechanism in the 
*initial* offer, while *the* answerer must use the mechanism in *each* 
subsequent *offer* and *answer*.

IIUC this means the initial offerer on the initial o/a of a session 
might use the mechanism on the initial offer and never again, while the 
answerer of the initial o/a has to use it on every offer and answer.

This is very asymmetric, and I suspect not what you intend.

I *think* what you intend is that a supporter generating an initial 
offer in a session must use the mechanism. Then, if the answer doesn't 
use the mechanism the offerer should cease using it in subsequent o/a 
exchanges in the session.

OTOH, if the initial answer uses the mechanism then it should be used by 
both ends for all subsequent o/a exchanges.

Is that what you intended?

That makes more sense. But this won't necessarily work right if there is 
a B2BUA that passes SDP through unchanged, and then at some point 
replaces a one session with another on one side of the B2BUA. (I.e. a 
3pcc transfer.) If the other end of the new session differs in support 
for this draft from the replaced endpoint it won't be properly 
negotiated for the new session.

This can be solved by the B2BUA editing the SDP, but that is a high 
burden for some B2BUAs.

ISTM that there is no real harm in an end that supports this *always* 
including it in offers.

A smaller point:

Is there any reason not to also allow this as a session level attribute, 
applying to all the media descriptions that don't have their own?

It could be convenient to just put the following at session level:


And finally, section 5 has an example with the following which must be 
wrong because it is missing a ":":

a=max-send-ssrc:{* 1}