Re: [MMUSIC] Review of unified-plan-00

Martin Thomson <> Thu, 18 July 2013 17:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7768E11E8150 for <>; Thu, 18 Jul 2013 10:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ACdOzoCp4c92 for <>; Thu, 18 Jul 2013 10:06:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::235]) by (Postfix) with ESMTP id 630E311E81A2 for <>; Thu, 18 Jul 2013 10:06:49 -0700 (PDT)
Received: by with SMTP id hq4so3455872wib.8 for <>; Thu, 18 Jul 2013 10:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FHI7q2kV6SQGVxSS8UnTE+OjmFCrIKaMgqjrtCwnKFs=; b=Dhwde+YgnsH8cOi1fyuILAutjWv0QMzjbpLFD2tLDUEbPaPEQT/ychZmpJpHm/a1dz pzsHihy1bThy4hi+YOw51g4S4dfVCQdu5ETe5VDoeP0DQP3plIn9y1lLDZAvKzkhZrvi 6nwEwv7UzyARlCJPLHbladABb12hC/hJ0K86EQu6X39DxVTxZtz4OyCgRT/eCxFUVuxs zFsRVuMHRHXtM3SqnN7mMaShSLdO+Gv22ZGYKhlU9vUmnPYx19n/B0ItfEgtIyFkBFIh Zmn/ODtYyrBISPBq8MZtgHCQ8vbC/rQMBmzCPxU3UEgOtoYdDX8npYLyqWW50OFrFs3L GrCQ==
MIME-Version: 1.0
X-Received: by with SMTP id fv11mr8716842wic.65.1374167208409; Thu, 18 Jul 2013 10:06:48 -0700 (PDT)
Received: by with HTTP; Thu, 18 Jul 2013 10:06:48 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 18 Jul 2013 10:06:48 -0700
Message-ID: <>
From: Martin Thomson <>
To: Harald Alvestrand <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [MMUSIC] Review of unified-plan-00
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: Thu, 18 Jul 2013 17:06:51 -0000

On 18 July 2013 02:40, Harald Alvestrand <> wrote:
>    The standard way of encoding this information in SDP is to have each
>    RTP flow (i.e., SSRC) appear on its own m-line.
> This is not strictly true, since the proposal continues to use each m-line
> for up to two flows, one in each direction, and some of the . Suggested
> rephrase:
>   One common way of encoding this information uses each M-line to
>   describe one media source in each direction.

That's fine with me.  It seems that there is some contention around
what an m-line actually is, and this has no substantive impact.  So
weasel away.

> It needs to note that this specification modifies RFC 5888 section 9.2

Yes.  We've talked about that lots, but we missed it somehow.

> 4.1 Simple example
> "It also shows unique payload across the audio and video m=lines for the
> Answerer that does not support BUNDLE semantics." - this doesn't make sense
> to me; unique payloads are needed for answerers that support BUNDLE
> semantics. Copy/paste error?
> Would be consistent if it said "for the Answerer that supports BUNDLE
> semantics".

Actually, this has nothing to do with BUNDLE.  It assumes that you
support BUNDLE, but might not support the RTP header extension and
might want to have media play out at the offerer prior to receiving an

> 4.4 Multiple Video with Simulcast
> If it's intended that draft-westerlund-avtcore-rtp-simulcast is used, the
> ssrc-group lines should probably say SCS rather than SIMULCAST.

Maybe this is a veiled comment along the lines of : "SCS" is a
strangely perverse choice of label, why don't you call a spade a spade

> Interaction with a=content
> Previously, we had discussed having a "content" attribute on
> MediaStreamTracks that would make a track link to an m-line with the same
> "a=content" attribute. If this is still expected to work, it might be worthy
> of inclusion here.

The purpose to which a=content was put in plan B isn't really
necessary any more.  No actual feature would depend on this, so don't
see a particular reason to mention this in the plan.

Maybe this is one of the SDP mutations we've been looking for.
Perhaps you can take this to the W3C.