Re: [rtcweb] path forward on bundle

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Fri, 05 October 2012 18:49 UTC

Return-Path: <fluffy@cisco.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 8B71F21F8528; Fri, 5 Oct 2012 11:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.319
X-Spam-Level:
X-Spam-Status: No, score=-109.319 tagged_above=-999 required=5 tests=[AWL=-1.120, 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 IZlPNSBCkrBp; Fri, 5 Oct 2012 11:49:00 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3EE21F842B; Fri, 5 Oct 2012 11:49:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6668; q=dns/txt; s=iport; t=1349462940; x=1350672540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=REi2TERZC8kt9jiJM/IvIFuXEiIajqTLrvsHr5Y+kl0=; b=hhxtdlFSrxdIGsLcpILzlt+PyziHIhluhytS7uPi5FLuDOVW5QyYqIxL s9jDngLXEBBfORr/jZx3dzG8i/TkCptuOQmtxdT2zkaGZ7WgQqynFbbTG XOaF0h0dr1JZOVXodpuhau904IuZN9IxsdjAwd92uyzYJtXPn8WrlYcJl 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGUqb1CtJXG9/2dsb2JhbABFvyCBCIIgAQEBBAEBAQ8BWwsQAgEIGAokIQYLJQIEDgUIEweHUQMPC5heljANiVSKWGaFKWADiCOLc4Jqig6DIoFpgm2CFw
X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128819004"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Oct 2012 18:49:00 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95ImxYs027533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 18:48:59 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 13:48:59 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Kaiduan Xie <kaiduanx@gmail.com>
Thread-Topic: [rtcweb] path forward on bundle
Thread-Index: AQHNoyaEp4nhhdwyxEuzOdZlbOlWD5erYa2A
Date: Fri, 5 Oct 2012 18:48:59 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11186B820@xmb-aln-x02.cisco.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB111869DCB@xmb-aln-x02.cisco.com> <506ED8C4.6080409@alvestrand.no> <CACKRbQejJDt0nd4OuZHrHcC48PZzOJRvKbiQUR1=ee4CxmcOZQ@mail.gmail.com>
In-Reply-To: <CACKRbQejJDt0nd4OuZHrHcC48PZzOJRvKbiQUR1=ee4CxmcOZQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001
x-tm-as-result: No--58.071700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <483558E4CF5F74448414E1D3F1C4175E@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Randell Jesup <rjesup@mozilla.com>, mmusic WG <mmusic@ietf.org>, Jonathan Lennox <jonathan@vidyo.com>
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:49:01 -0000

On Oct 5, 2012, at 12:23 PM, Kaiduan Xie <kaiduanx@gmail.com> wrote:

> "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?

oops - yes - that should be baz , sorry



> 
> /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