Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups.

Philipp Hancke <> Mon, 22 July 2013 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E9B211E80EF for <>; Mon, 22 Jul 2013 10:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cZ7Da4G7yp7m for <>; Mon, 22 Jul 2013 10:16:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4DCC311E8180 for <>; Mon, 22 Jul 2013 10:00:20 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MH0HIb013182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 19:00:18 +0200
Message-ID: <>
Date: Mon, 22 Jul 2013 19:00:11 +0200
From: Philipp Hancke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To:,, XMPP Jingle <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jul 2013 17:16:23 -0000

(removed stox)

Am 22.07.2013 17:14, schrieb Iñaki Baz Castillo:
> Great. First thing you should complain about is the fact that current
> WebRTC specification makes unfeasible for a browser to use SDP-XML as
> defined by XEP-0167.

I said this before, but since you insist on repeating your argument i'll 
repeat mine: I have running code doing exactly that.

It's hard work and there are some points where this is PITA, I have 
discovered numerous bugs in chrome (and the jingle spec) along the way, 
but it's certainly not unfeasible.

So far, this mapping works using the elements already defined in XEPs 
0167, 0293, 0294 and 0320 even. has a 
quite concrete list of features of what functionality the mapping 
between SDP and the xmlish SD has to define.

I'd note that I consider jingle a better way to talk about the session 
description because it has a very clear separation between codec 
negotation and transport which has led to concepts like trickle-ice. 
Also, it defined actions like content-add which seem to have influenced 
unified plan.

I have yet to see the current API fail completly and have been using it 
in ways that were certainly not imagined, e.g. early transport warmup 
using PRANSWER (and I still owe feedback on that to the JSEP authors; 
ironically, the solution is more SDP in the API).