[MMUSIC] The role of signaling

Martin Thomson <martin.thomson@gmail.com> Wed, 05 June 2013 17:37 UTC

Return-Path: <martin.thomson@gmail.com>
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 1A3AC21F9AF5 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 10:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GmTq+a176Y0c for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 10:37:38 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A286321F8E37 for <mmusic@ietf.org>; Wed, 5 Jun 2013 10:37:37 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id z12so946398wgg.19 for <mmusic@ietf.org>; Wed, 05 Jun 2013 10:37:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oYzzYwiaVDGRVWkCelmRgh6jKuCgr22v49GlNmxar4E=; b=m5TSddPDltaLlYXGE7mRWiqoeGCoEHWRb5TfFg2b9YHAWvsgfreCnQuVLppiI6IW6H 29YljlWaettiZqjAD1cbjFdms+f+t0Zwk4+riQDzfX5OFecIV0mDerlFpCUrxFio8A0G 8DMxHBj+awN4u2eXunUDJcwvOGEgVX+gZSuY2MhjgEY5SYLdpUNFvyZTlkWPQ3OEdx8b dRFp7mZaGv5GS3l1hV0OiTwecAwio+HuFYWpatsXUvdJ24ZVdSTTTHGM75qFdRPyjJaV FObzBjiB92l3+aXTOAL7NyMuC222sNwLSALjNSy0WrzTu3QcpyRgO/jULPdntT4aFYDJ ksYg==
MIME-Version: 1.0
X-Received: by with SMTP id fz1mr12006wic.34.1370453856774; Wed, 05 Jun 2013 10:37:36 -0700 (PDT)
Received: by with HTTP; Wed, 5 Jun 2013 10:37:36 -0700 (PDT)
Date: Wed, 5 Jun 2013 10:37:36 -0700
Message-ID: <CABkgnnVuydix9oJpCZG5G=y66K8+PDd69stgaXyFofSYDGu5=g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [MMUSIC] The role of signaling
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: Wed, 05 Jun 2013 17:37:39 -0000

I actually think that noplan bears serious consideration, but only
with respect to what it says about the role of signaling.

Plan A/B assume some things about these questions that we clearly
haven't reached consensus on.  The questions that I think we've been
working towards are:

 - What role does signaling play in session establishment?
 - What information does signaling convey vs. what information is
conveyed in the signaled medium?
 - Does SDP represent ALL signaling?  (Clearly not.)  What parts of
signaling is SDP responsible for?

I don't think that we resolve anything on A/B until we agree on what
SDP is and does.  Of course, once we agree on principles, we are
always free to choose expediency over those principles.

I think that Emil was right to recognize that SDP O/A doesn't need to
be the only signaling mechanism.  The fact that WebRTC is using a
signaling protocol as part of an API surface is, in my opinion, the
reason for this affliction.  It appears as though SDP is the carpet to
sweep all the muck under when it doesn't fit anywhere else, simply
because we took the other options (read: SIP) away.  That puts a lot
of pressure on SDP.

For instance, to pick an easy example, adding identity assertions to
SDP could be the wrong choice.  In SIP, identity is the domain of the
SIP part of signaling.