Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture

Cullen Jennings <fluffy@cisco.com> Fri, 08 July 2011 14:11 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 EA2E521F8A7C for <rtcweb@ietfa.amsl.com>; Fri, 8 Jul 2011 07:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.831
X-Spam-Level:
X-Spam-Status: No, score=-104.831 tagged_above=-999 required=5 tests=[AWL=-2.232, BAYES_00=-2.599, 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 62f3O1NrM3lz for <rtcweb@ietfa.amsl.com>; Fri, 8 Jul 2011 07:11:35 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8621F8A77 for <rtcweb@ietf.org>; Fri, 8 Jul 2011 07:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5678; q=dns/txt; s=iport; t=1310134295; x=1311343895; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+XjkCzNXjuRNVMouugRUm1KX/bFzDYISznxcHQSUrS0=; b=EYQsr0via+itTsIaun2ppH+RXTMcIZ5efD6zgENpoU4QOrjXUwmaqSLn NwDV7wLvS4yuvreWvq7BEpwb4szcSNfKT3RJ3yC5J6j3CgrLSPyyVIUzo B/ZNzPPp59xqszYRzhWgP8SDqfzNprjhToBjRKHhcehD5UgohSNQ4sYPl c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANYPF06rRDoI/2dsb2JhbABQA6dFd4h7pG6df4NCgnYEh0yIdoIKhH2LZg
X-IronPort-AV: E=Sophos;i="4.65,499,1304294400"; d="scan'208";a="1052838"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2011 14:11:25 +0000
Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p68EBNaY019690; Fri, 8 Jul 2011 14:11:24 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <CAHzHjDNc=ZkAV5U=TqQe7uHXp9vgrRb9Q-R5gtGk_7QSQ80JLg@mail.gmail.com>
Date: Fri, 08 Jul 2011 08:11:23 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFC2EA65-904F-4849-AF37-D1980C4229FB@cisco.com>
References: <BLU152-w2EFC2C55649AF1665D96A935E0@phx.gbl> <DFCE8D1D-AC5F-455A-B45D-C09DB6F7D5F8@cisco.com> <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com> <CAHzHjDNc=ZkAV5U=TqQe7uHXp9vgrRb9Q-R5gtGk_7QSQ80JLg@mail.gmail.com>
To: Niklas Enbom <niklase@google.com>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture
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, 08 Jul 2011 14:11:36 -0000

Makes sense - thanks. I'm trying to interpret the spec by looking at the code. I'll stop doing that :-)

On Jul 8, 2011, at 1:58 AM, Niklas Enbom wrote:

> Not sure in which thread I should answer... In Chrome we're trying to implement the whatwg proposal with one intentional discrepancy, and that's the string format pointed out by Cullen. See details in this thread: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg26163.html. There's also non-intentional discrepancies that we know of, which we're trying to remove.
> 
> Just be careful when looking at Chrome code to interpret the whatwg spec. We're trying to interpret that spec in the same way as anyone else, and the whatwg author is not involved in the Chrome implementation.
> 
> Niklas
> 
> On Thu, Jul 7, 2011 at 7:52 PM, Cullen Jennings <fluffy@cisco.com> wrote:
> 
> I went and looked at some call flows to try and sort out what is going on in the current released chrome code and as far as I can tell, Bernard you are right, it is passing the data over the HTTP channel. An example of what I see is below
> 
> As far as I can tell this is the JSON encoding of XEP-180 used in jingle and a separate JSON encoding of some of SDP. Not sure this matters much one way or the other but wanted to pass on what I had found and I will correct the slides at some point - my apologies for getting them wrong.
> 
> Cullen
> 
> 
> 
> {
>   "media" : [
>      {
>         "attributes" : {
>            "candidate" : [
>               {
>                  "component" : 1,
>                  "foundation" : 1,
>                  "generation" : 0,
>                  "ip" : "144.254.150.241",
>                  "name" : "rtp",
>                  "network_name" : "Intel(R) WiFi Link 1000 BGN",
>                  "password" : "OpawIyXLYcJkwxFa",
>                  "port" : "61880",
>                  "priority" : 1.0,
>                  "proto" : "udp",
>                  "type" : "local",
>                  "username" : "90B0CPvC8p8XPMFt"
>               }
>            ]
>         },
>         "label" : 1,
>         "rtpmap" : [
>            {
>               "103" : {
>                  "codec" : "audio/ISAC"
>               }
>            },
>            {
>               "104" : {
>                  "codec" : "audio/ISAC"
>               }
>            },
>            {
>               "9" : {
>                  "codec" : "audio/G722"
>               }
>            },
>            {
>               "102" : {
>                  "codec" : "audio/iLBC"
>               }
>            },
>            {
>               "0" : {
>                  "codec" : "audio/PCMU"
>               }
>            },
>            {
>               "8" : {
>                  "codec" : "audio/PCMA"
>               }
>            },
>            {
>               "99" : {
>                  "codec" : "audio/CN"
>               }
>            },
>            {
>               "98" : {
>                  "codec" : "audio/CN"
>               }
>            },
>            {
>               "13" : {
>                  "codec" : "audio/CN"
>               }
>            },
>            {
>               "127" : {
>                  "codec" : "audio/red"
>               }
>            },
>            {
>               "106" : {
>                  "codec" : "audio/telephone-event"
>               }
>            }
>         ]
>      },
>      {
>         "attributes" : {
>            "candidate" : [
>               {
>                  "component" : 1,
>                  "foundation" : 1,
>                  "generation" : 0,
>                  "ip" : "144.254.150.241",
>                  "name" : "video_rtp",
>                  "network_name" : "Intel(R) WiFi Link 1000 BGN",
>                  "password" : "G4dq4e3f/G7FDJ5h",
>                  "port" : "61879",
>                  "priority" : 1.0,
>                  "proto" : "udp",
>                  "type" : "local",
>                  "username" : "CBkZYp6/DTTMEFeM"
>               }
>            ]
>         },
>         "label" : 2,
>         "rtpmap" : [
>            {
>               "120" : {
>                  "codec" : "video/VP8"
>               }
>            }
>         ]
>      }
>   ]
> }
> 
> 
> On Jul 6, 2011, at 9:43 PM, Cullen Jennings wrote:
> 
> >
> > On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote:
> >
> >>
> >>
> >> * The last slide now says that WhatWG proposal is low path; this is not true. The WhatWG proposal as I read it is mute on how the SDPs are exchanged, it just hands those SDPs over to the
> >>
> >> application (though high path is indicated: "Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.")
> >
> > Hmm - my understanding was only the ICE related information was communicated that way and the SDP related information when across the channel set up by ICE but I could be totally wrong. It's pretty vague in the spec - I got that idea by talking to some of the people involved. Anyways, glad to retract that WhatWG is doing low path and just change it to not clear.
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>