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

Niklas Enbom <niklase@google.com> Fri, 08 July 2011 07:58 UTC

Return-Path: <niklase@google.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 791FB21F8747 for <rtcweb@ietfa.amsl.com>; Fri, 8 Jul 2011 00:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level:
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 qLcma7QoSW4k for <rtcweb@ietfa.amsl.com>; Fri, 8 Jul 2011 00:58:56 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD121F8741 for <rtcweb@ietf.org>; Fri, 8 Jul 2011 00:58:53 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p687wq4T018911 for <rtcweb@ietf.org>; Fri, 8 Jul 2011 00:58:52 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310111932; bh=XfNCoOcTORPxGwiXLE2x1tvFLjE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Yn+hJ427sj/ke1ggzeMWUGh206CJSwB9uaBKWVjlaL/tNcFykw/Y7K6bBjUfO0kXz n3J2pL3SyQUbBEVnnk4RA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=WoRq2/0xSekd+SklrstpUv3mLXzlZfaH7ftr/hKhNULdx9VCxEmInKJ8wD4DoGYet emYt2rTSEQony8mM5gLqA==
Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by kpbe19.cbf.corp.google.com with ESMTP id p687wo7b015452 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Fri, 8 Jul 2011 00:58:51 -0700
Received: by yxl31 with SMTP id 31so868656yxl.41 for <rtcweb@ietf.org>; Fri, 08 Jul 2011 00:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TPWQT9is79qUKzDg5Wgs3Yyyqz7fu5/oD2DsfGTVckM=; b=pi/q/NiiOZl4raRULgMqtoK5wrv/5zhVqlHNdqqpy+ACAq4/Be9Lp/oJ5SUh7R9fYZ JJ9sVYMX77mBFBuO47fQ==
MIME-Version: 1.0
Received: by 10.100.233.21 with SMTP id f21mr1422846anh.83.1310111930152; Fri, 08 Jul 2011 00:58:50 -0700 (PDT)
Received: by 10.100.165.11 with HTTP; Fri, 8 Jul 2011 00:58:50 -0700 (PDT)
In-Reply-To: <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com>
References: <BLU152-w2EFC2C55649AF1665D96A935E0@phx.gbl> <DFCE8D1D-AC5F-455A-B45D-C09DB6F7D5F8@cisco.com> <87FBDAC1-C440-49E1-B7F1-3CA2E96BC637@cisco.com>
Date: Fri, 08 Jul 2011 09:58:50 +0200
Message-ID: <CAHzHjDNc=ZkAV5U=TqQe7uHXp9vgrRb9Q-R5gtGk_7QSQ80JLg@mail.gmail.com>
From: Niklas Enbom <niklase@google.com>
To: Cullen Jennings <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="0016367658843677bb04a78a34c8"
X-System-Of-Record: true
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 07:58:57 -0000

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
>