Re: [rtcweb] path forward on bundle

Kaiduan Xie <kaiduanx@gmail.com> Fri, 05 October 2012 18:23 UTC

Return-Path: <kaiduanx@gmail.com>
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 C2CCB21F87EC; Fri, 5 Oct 2012 11:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-1.200, 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_LOW=-1]
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 X4VcNX7Mv41T; Fri, 5 Oct 2012 11:23:18 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC0B021F87EA; Fri, 5 Oct 2012 11:23:17 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so2440685obq.31 for <multiple recipients>; Fri, 05 Oct 2012 11:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppVEmYa6z+UkNXOn8bFkyY/dOAhNjPCtLAdNuLs1Iok=; b=hIq+Jmgscdi2/30uBCsR0Zf2XUwX2/12Upun6zADu2B/uP76BjJGZN7nyMCkDbyXPb JdUsnbAykWNotMaNzCtdAO6iQs/xqbAmdsOuwwj9x85qXp5VC6UKnnEvp+9io/mK58xl KGxxkqFB4XviTLNEa0XsGJ1MqJVQakDpn9R6f8f2Dqsnr0aDFT8NcxcsVLobKpJb0Tpv oUPZJH43pHm0ttB9FA9623pon/NN5V7nBDNpv7C+bAeW7MM3EO43fohDish/1ym74LO2 G2ToX51WXjLOwELC9XpKyCgjA45YY2txVNpCFQruOfyK8u6VKf5iDRC9oXfjvwC454OP 7Tyw==
MIME-Version: 1.0
Received: by 10.60.0.169 with SMTP id 9mr7847606oef.94.1349461397572; Fri, 05 Oct 2012 11:23:17 -0700 (PDT)
Received: by 10.76.23.129 with HTTP; Fri, 5 Oct 2012 11:23:17 -0700 (PDT)
In-Reply-To: <506ED8C4.6080409@alvestrand.no>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB111869DCB@xmb-aln-x02.cisco.com> <506ED8C4.6080409@alvestrand.no>
Date: Fri, 5 Oct 2012 14:23:17 -0400
Message-ID: <CACKRbQejJDt0nd4OuZHrHcC48PZzOJRvKbiQUR1=ee4CxmcOZQ@mail.gmail.com>
From: Kaiduan Xie <kaiduanx@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, Jonathan Lennox <jonathan@vidyo.com>, Randell Jesup <rjesup@mozilla.com>, mmusic WG <mmusic@ietf.org>, "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 18:23:18 -0000

"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."
^^^

Should it be baz mid?

/Kaiduan

On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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  clo
>
> se 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
> :-)
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb