[MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

Jonathan Lennox <jonathan@vidyo.com> Wed, 01 August 2012 18:56 UTC

Return-Path: <jonathan@vidyo.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 D234011E831C for <mmusic@ietfa.amsl.com>; Wed, 1 Aug 2012 11:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id V26xK2LC3r8k for <mmusic@ietfa.amsl.com>; Wed, 1 Aug 2012 11:56:32 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com []) by ietfa.amsl.com (Postfix) with ESMTP id EB38A11E829A for <mmusic@ietf.org>; Wed, 1 Aug 2012 11:56:31 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost []) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8B036556C1F for <mmusic@ietf.org>; Wed, 1 Aug 2012 14:56:31 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB025.mail.lan (unknown []) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2F073556C1B for <mmusic@ietf.org>; Wed, 1 Aug 2012 14:56:28 -0400 (EDT)
Received: from BE235.mail.lan ([]) by HUB025.mail.lan ([]) with mapi; Wed, 1 Aug 2012 14:56:08 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Date: Wed, 01 Aug 2012 14:56:33 -0400
Thread-Topic: Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac1wF0+T5NaAB5VuSRCtWQNsyZAJTw==
Message-ID: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
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, 01 Aug 2012 18:56:32 -0000

As I mentioned at the mic, BUNDLE currently generates an implicit combined description of the bundled RTP session, and a lot of the problems and standardization issues we're having relate to the fact that the bundled session's media description is implicit.  Therefore, you need a lot of language specifying when parts of bundled m=lines must be the same, when they must be different, and when they may be independent.  Such specifications would need to be defined for every existing SDP attribute used in offer-answer, and every new SDP attribute going forward.

The alternative to having an implicit description, I think, would be to have an explicit description.  The basic idea is to have a new m-line representing the bundled session explicitly, defined in a way that a non-bundle-aware endpoint should see it as an unknown type of m-line and reject it.  The BUNDLE grouping semantic then says that you either use all the traditional m-lines, rejecting the bundled one, or you use the one bundled m-line, rejecting all the others.

As a straw man example, a variant of bundle-negotiation-00's example offer with ICE:

       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar baz
       m=audio 10000 RTP/AVP 0 8 97
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 10002 RTP/AVP 31 32
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
       m=bundle 10000 RTP/AVP 0 8 97 31 32
       a=full-rtpmap:0 audio/PCMU/8000
       a=full-rtpmap:8 audio/PCMA/8000
       a=full-rtpmap:97 audio/iLBC/8000
       a=full-rtpmap:31 video/H261/90000
       a=full-rtpmap:32 video/MPV/90000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host

Points to note:

* Outside the m=bundle line and its attributes, this is entirely current-standard SDP.

* The m=bundle is a complete description of an entirely separate m-line; if it's used, the other m-lines in the group are rejected and the information they carry is ignored.

* We'll need to make sure that we have a syntax for this new m-line (what I've called m=bundle) that existing implementations will reject (with port 0), rather than interpreting as an SDP syntax error.  We'll need input from interop people to know what's safe to do here.

* The ports and ICE candidates specified in the m=bundle line are entirely up to the whim of the offerer; they may overlap with one of the other m-lines, but don't have to.

* Because the media type of the payload types isn't given by the m-line, we need new syntax to specify the top-level media type.  I've called this "full-rtpmap", but this is just a strawman.

* Because there's one list of payload types, the RFC 3264 payload preference order needs a bit of finessing. I'd suggest saying that the preference order should be interpreted independently per media type.

* There's obviously no way to do a=sendonly/recvonly independently for audio and video; you'd need to do it on the source level, with (if you're doing it in SDP) something like my source-selection draft.

* There's an obvious syntax to send an offer that means "support BUNDLE, or fail" -- just send the m=bundle line, without the grouped independent lines.  Whether we'd want to allow such an offer is a separate question.

Jonathan Lennox