[MMUSIC] Simulcast draft feedback

Byron Campen <docfaraday@gmail.com> Mon, 19 October 2015 20:22 UTC

Return-Path: <docfaraday@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2111C1AC3CC for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 13:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VEGvkh6AKWah for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 13:22:24 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113C71AC3B5 for <mmusic@ietf.org>; Mon, 19 Oct 2015 13:22:13 -0700 (PDT)
Received: by obbda8 with SMTP id da8so149129953obb.1 for <mmusic@ietf.org>; Mon, 19 Oct 2015 13:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=IRMT3UJiahWJVzYUCW97D0uD1r4leKGf6+9loM/FLIw=; b=dLJ6+NncrN29i2pa7s4FFz6SjtbVJvvGheuhYGR8y+mbe8thgh/O1nxGfucMT+fwFn CrzBazWhr9hWhEeglRUE5ml5kiqZHdY6zdworXvEdDJIsdc8Nn7zHLClwJwPRurlMERh bPzNFbEDrTThDdoJNG5vn4fIhmU0dePbFzKjzzgKUfwx0yaCnPXKgYWeYo9dJs+18IJO BRefsCplM2AWxIq83jJrZ62P5bfzfvfMsYtB1zXmypRG78wcA45t/AqDdmQP/VWdwgpx 9qRbMzcoBiZUkiAGpwhaoG8bLhLx33tDlrMXW8zRYZ6rZhOTE71OKHW5o13BVEN+OT4d QoXw==
X-Received: by with SMTP id po3mr21062193oeb.68.1445286132133; Mon, 19 Oct 2015 13:22:12 -0700 (PDT)
Received: from ?IPv6:2602:306:83ae:c480:9d3f:b127:18ed:2e86? ([2602:306:83ae:c480:9d3f:b127:18ed:2e86]) by smtp.googlemail.com with ESMTPSA id a4sm15819810obx.9.2015. for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 13:22:11 -0700 (PDT)
To: mmusic@ietf.org
From: Byron Campen <docfaraday@gmail.com>
Message-ID: <562550F9.2020101@gmail.com>
Date: Mon, 19 Oct 2015 15:22:17 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------060408090401030800080103"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/_YrK6yqM1gXI32IF-irP4_KLYbk>
Subject: [MMUSIC] Simulcast draft feedback
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 19 Oct 2015 20:22:26 -0000

**** Identification type shenanigans ****

     The draft currently allows the following:

a=simulcast: send rid=foo;bar;baz recv pt=96;97;98

     Here we have different identification types for each direction. Is 
this something the spec should allow? Also, things get really 
interesting when you add sendrecv:

a=simulcast: send rid=foo;bar;baz recv pt=96;97;98 sendrecv pt=100

     Now we have three simulcast streams that use rid, and a fourth that 
uses pt, for the send direction. This strikes me as a bad idea. Removing 
sendrecv is something that sounds like a good idea, for this and other 

     (I would also point out that this would be a complete non-issue if 
we just used rid)

**** Payload type asymmetry confusion ****

     Consider the following simulcast offer/answer exchange, where the 
answerer removes a simulcast version and changes payload types:

a=rtpmap:96 VP8/90000
a=rtpmap:97 VP8/90000
a=rtpmap:98 VP8/90000
// a=fmtp that differ for the above three
a=simulcast: send pt=96;97;98

a=simulcast: recv pt=42;101

     What did the answerer just accept? We cannot infer from rtpmap, 
since those are all the same, and we probably cannot infer from fmtp 
either, since that isn't symmetric. Perhaps if imageattr were used, the 
offerer could attempt to determine which of the imageattrs in the answer 
matched what was placed in the offer, but this is a bit of a stretch.

     We could work around this with syntax like the following, perhaps:

a=simulcast: recv pt=42;;101

     (Again, I would point out that this would be a non-issue if we just 
used rid)

**** Requirements for support of PT-based simulcast ***

*    My understanding of the draft is that support for PT-based 
simulcast is mandatory, while RID-based simulcast is optional to 
implement. Is this correct? If so, how is negotiation supposed to look 
between an offerer that offers to use rid, and an answerer that does not 
support rid? Is the simulcast attribute simply removed? Is changing the 
identification type in an answer permitted under any circumstances?

**** Renegotiation questions ****

     This draft does not mention renegotiation at all. I'm assuming 
adding/removing simulcast versions and alternatives is ok. What about 
switching from PT-based to RID-based simulcast (or vice versa) in a reoffer?

Best regards,
Byron Campen