Re: [rtcweb] path forward on bundle

Harald Alvestrand <harald@alvestrand.no> Fri, 05 October 2012 12:55 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DAF21F86DF; Fri, 5 Oct 2012 05:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.324
X-Spam-Level:
X-Spam-Status: No, score=-109.324 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpGAktS2lfL3; Fri, 5 Oct 2012 05:55:40 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BE06A21F86DC; Fri, 5 Oct 2012 05:55:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFC4539E1D0; Fri, 5 Oct 2012 14:55:34 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVh3vnGAf-8X; Fri, 5 Oct 2012 14:55:33 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4589A39E1BD; Fri, 5 Oct 2012 14:55:33 +0200 (CEST)
Message-ID: <506ED8C4.6080409@alvestrand.no>
Date: Fri, 05 Oct 2012 14:55:32 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB111869DCB@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB111869DCB@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic WG <mmusic@ietf.org>, Randell Jesup <rjesup@mozilla.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] path forward on bundle
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2012 12:55:41 -0000

On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote:
> I'm trying to figure out how to move forward on bundle stuff. Let me start by summarizing what I think the three proposals are then we can try and sort out pros/cons of each. I think we agree that the goals here is to have something that gets the SDP so that we can negotiate using less ports.
>
> I see it as we have three proposed solutions that I will call "a=bundle same port", "a=bundle different port", and  "m=bundle". I'll try and describe these below to make sure we are on same page of what the three are then we can try and figurer out pros/cons of each and what to do. I'll give examples of the SDP offer for each but I tried and make everything simple, I'm going to ignore the RTCP mux and such but I think you can see how that would get added to all the examples.
>
>
> First lets set the baseline of an offer that does not want to multiplex the audio and video on same port
>           v=0
>           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>           s=
>           c=IN IP4 host.atlanta.example.com
>           t=0 0
>           m=audio 49170 RTP/AVP 0
>           a=mid:foo
>           a=rtpmap:0 PCMU/8000
>           m=video 49172 RTP/AVP 31
>           a=mid:bar
>           a=rtpmap:31 H261/90000
>
>
>
> Proposal "a=bundle same port"
>           v=0
>           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>           s=
>           c=IN IP4 host.atlanta.example.com
>           t=0 0
>           a=group:BUNDLE foo bar
>           m=audio 49170 RTP/AVP 0
>           a=mid:foo
>           a=rtpmap:0 PCMU/8000
>           m=video 49170 RTP/AVP 31
>           a=mid:bar
>           a=rtpmap:31 H261/90000
>
> In the above example, note that all the m lines for a mid identified in the group:BUNLDE have the same port (49170)
No issue so far.
>
>
>
> Proposal "a=bundle different port"
>           v=0
>           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>           s=
>           c=IN IP4 host.atlanta.example.com
>           t=0 0
>           a=group:BUNDLE foo bar
>           m=audio 49170 RTP/AVP 0
>           a=mid:foo
>           a=rtpmap:0 PCMU/8000
>           m=video 49172 RTP/AVP 31
>           a=mid:bar
>           a=rtpmap:31 H261/90000
>
> In the above example, note that the port numbers are the same as baseline - if you device receiving this offer does not support group:BUNLDE, then this is identical to the baseline. So one m line has a port of 49170 and the other has a different port. Other than that, it is the same as the "a=bundle same port". The semantics of group:BUNLDE would be defined to be that if the SDP receiver supports BUNDLE and wants to use it, then it places a group:BUNDLE line in the answer and it send all the media to the mids in the in BUNDLE group to the port number identified for the m-line corresponding to the first mid in the BUNDLE group. In this example, the first mid on the a=group:BUNDLE lines is foo, which has a m line with a port of 49170, so both the H261 and PCMU (mids foo and bar) would go to port 49170 if the device creating the answer wanted to use BUNDLE. We don't have a draft yet that says exactly this thought it is very close to the one-rtp draft ( and for that matter  close to bundle draft )
I believe this is the mechanism described in 
draft-alvestrand-one-rtp-02, or at least what it was intended to say. So 
we can use the name "a=group:together" for this without risk of confusion.
>
>
>
> Proposal "m=bundle"
>           v=0
>           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>           s=
>           c=IN IP4 host.atlanta.example.com
>           t=0 0
>           a=group:BUNDLE foo bar baz
>           m=audio 49170 RTP/AVP 0
>           a=mid:foo
>           a=rtpmap:0 PCMU/8000
>           m=video 49172 RTP/AVP 31
>           a=mid:bar
>           a=rtpmap:31 H261/90000
>           m=bundle 10000 RTP/AVP 0 8 97 31 32
>           a=mid:baz
>           a=full-rtpmap:0 audio/PCMU/8000
>           a=full-rtpmap:31 video/H261/90000
>
>
> Note in the above example the SDP above the m=bundle line is pretty much the same as the baseline + the group:BUNDLE line. The m=bundle is new media type that indicates many things are bundled together on port 10000. A device that understood bundle would know to ignore the m lines corresponding to foo and bar mids and would just use the stuff from the bas mid.
Yep. I've suggested calling it "m=anytype", but Christer hasn't adopted 
that so far :-)
>
>
> So before we start discussing the pros / cons of theses three approaches, let's spend a few days and make sure that I have correctly characterized the three approaches under discussion.
>
> Did I get it right? Do we need more explanation of any of these to see how they work?
>
> Lets keep clarifications only on this thread and I'll start a separate thread for pro/cons once we get this a bit clearer.
Remember to change the subject line to a descriptive one for the next 
thread :-)
>
>
>
>
>
>
>
>
>