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

From: Ralph Meijer <[email-masked]>
Date: Mon, 22 Jul 2013 17:05:41 +0200

Hi all,

I would like to inform the group of the recent formation [1] of the 
Jingle Special Interest Group (SIG) at the XMPP Standards Foundation 
(XSF). The recent increase of activity in the WebRTC and rtcweb working 
groups and related high-profile product developments and announcements 
were reasons for the XMPP Council to decide to concentrate efforts 
around Jingle in a SIG.

Jingle [2] is a general framework for managing media sessions between 
XMPP Sessions, including, but not limited to, audio/video streams, file 
transfer and application sharing. There are several documents describing 
applications of Jingle and the used transports, most linked from the 
overall framework specification [3].

The specification of Jingle RTP Sessions [4], most relevant to these 
working groups, defines a Jingle application type for negotiating RTP 
sessions. It has been designed such that interoperability with SIP-based 
systems is possible. This includes mapping negotiation parameters to and 
from SDP, while remaining a signaling protocol in its own right (not 
merely SDP in angle brackets).

The following work items were defined in the kick-off meeting last 
Wednesday, July 17 [5, raw log 6]:

  * Re-examining the state of the various Jingle proposals.
  * Polishing Jingle File Transfer.
  * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE
    improvements.
  * Documenting and communicating the value proposition of Jingle/XMPP.

This SIG already includes a number of people participating in 
discussions on the WebRTC and rtcweb mailing lists and is lead by Dave 
Cridland (chair), Philipp Hancke, Lance Stout and myself. It is open to 
anyone, and we are looking forward to cooperate with the WebRTC and 
rtcweb working groups to improve both WebRTC and Jingle.

The discussion venues are the Jingle mailing list [7] and the Jingle 
XMPP multi-user chat room [8]. Our next meeting in the MUC room is 
Wednesday July 24 at 15:30 UTC. This group's experience and input would 
be highly appreciated, and your participation in both the meeting and 
the on-going discussion would be most welcome.

Thanks,

Ralph Meijer

[1] <http://mail.jabber.org/pipermail/jingle/2013-June/001933.html>
[2] <http://xmpp.org/about-xmpp/technology-overview/jingle/>
[3] <http://xmpp.org/extensions/xep-0166.html>
[4] <http://xmpp.org/extensions/xep-0167.html>
[5] <http://mail.jabber.org/pipermail/jingle/2013-July/001956.html>
[6] <http://logs.xmpp.org/jingle/130717/>
[7] <http://mail.jabber.org/mailman/listinfo/jingle>
[8] <xmpp:[email-masked]?join>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Jul 2013 17:14:36 +0200

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. So if you have a SIP server you will be able to
directly connect from the browser, but if you have a Jingle server you
will need a gateway.

2013/7/22 Ralph Meijer <[email-masked]>:
> Hi all,
>
> I would like to inform the group of the recent formation [1] of the Jingle
> Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The
> recent increase of activity in the WebRTC and rtcweb working groups and
> related high-profile product developments and announcements were reasons for
> the XMPP Council to decide to concentrate efforts around Jingle in a SIG.
>
> Jingle [2] is a general framework for managing media sessions between XMPP
> Sessions, including, but not limited to, audio/video streams, file transfer
> and application sharing. There are several documents describing applications
> of Jingle and the used transports, most linked from the overall framework
> specification [3].
>
> The specification of Jingle RTP Sessions [4], most relevant to these working
> groups, defines a Jingle application type for negotiating RTP sessions. It
> has been designed such that interoperability with SIP-based systems is
> possible. This includes mapping negotiation parameters to and from SDP,
> while remaining a signaling protocol in its own right (not merely SDP in
> angle brackets).
>
> This SIG already includes a number of people participating in discussions on
> the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair),
> Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are
> looking forward to cooperate with the WebRTC and rtcweb working groups to
> improve both WebRTC and Jingle.
>
> The discussion venues are the Jingle mailing list [7] and the Jingle XMPP
> multi-user chat room [8]. Our next meeting in the MUC room is Wednesday July
> 24 at 15:30 UTC. This group's experience and input would be highly
> appreciated, and your participation in both the meeting and the on-going
> discussion would be most welcome.
>
> Thanks,
>
> Ralph Meijer
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 22 Jul 2013 17:28:34 +0200

> directly connect from the browser, but if you have a Jingle server you
You are obviously misinforming here. SIP is the signaling protocol and a 
SIP server has really little to deal with SDP -- I'm sure you know that. 
And one cannot call directly a SIP endpoint from the browser, as SIP is 
not a mandatory signaling protocol, so there is extensive need of coding 
a javascript SIP stack (or reusing an existing one).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: Ralph Meijer <[email-masked]>
Date: Mon, 22 Jul 2013 17:46:46 +0200

> directly connect from the browser, but if you have a Jingle server you

Hi Iñaki,

I have been following the recent discussions for a while now, and think 
I understand the various stand points, including yours.

As I mentioned in my announcement, mapping SDP to Jingle's negotiation 
parameters is indeed one of the concerns we are going to look into. 
Philipp's work on his WebRTC plugin for Strophe.js [1], which uses 
Jingle signalling, has shown that it indeed takes quite some effort to 
map and mangle SDP to get things going. The spreadsheet questionnaire 
that Peter Thatcher asked people to fill in (thanks!) also has several 
comments to that effect. During our discussions on the Jingle mailing 
list and the meeting last week, more of such comments were made.

I want to stress, again, that Jingle's negotiation parameters should not 
be referred to as a flavor of SDP expressed in XML. This is misleading, 
as it is not managed by MMUSIC, and actually weakens your point of not 
wanting SDP as an API surface. I can understand that looking at the 
current specification could give that impression, though. The Jingle 
examples are currently interleaved by SDP examples to show the mapping, 
and we are looking into making the distinction clearer, maybe even as a 
document separate from this one.

[1] https://github.com/ESTOS/strophe.jingle

PS. Yes, I messed up the subject header of the original announcement.

-- 
ralphm

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Jul 2013 17:54:59 +0200

2013/7/22 Ralph Meijer <[email-masked]>:
> Hi Iñaki,
>
> I have been following the recent discussions for a while now, and think I
> understand the various stand points, including yours.
>
> Philipp's work on his WebRTC plugin for Strophe.js [1], which uses Jingle
> signalling, has shown that it indeed takes quite some effort to map and
> mangle SDP to get things going. The spreadsheet questionnaire that Peter
> Thatcher asked people to fill in (thanks!) also has several comments to that
> effect. During our discussions on the Jingle mailing list and the meeting
> last week, more of such comments were made.
>
> I want to stress, again, that Jingle's negotiation parameters should not be
> referred to as a flavor of SDP expressed in XML. This is misleading, as it
> is not managed by MMUSIC, and actually weakens your point of not wanting SDP
> as an API surface. I can understand that looking at the current
> specification could give that impression, though. The Jingle examples are
> currently interleaved by SDP examples to show the mapping, and we are
> looking into making the distinction clearer, maybe even as a document
> separate from this one.

Thanks for the clarification. So Jingle's session description is not
just a plain-to-XML mapping of a common SDP. Good to know.

However, wouldn't you prefer to have a pure JS Object with all the
media and transport information you require to build your Jingle
XML-SDP instead of having to parse a plain SDP string blob?

Thanks a lot.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 22 Jul 2013 19:00:11 +0200

(removed stox)

Am 22.07.2013 17:14, schrieb Iñaki Baz Castillo:
> 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. 
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.1 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).

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jul 2013 13:45:43 -0400

On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke
<[email-masked]>wrote:

> discovered numerous bugs in chrome (and the jingle spec) along the way, but
> it's certainly not unfeasible.
>
>
Out of curiosity, does the same code work with Firefox?
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Jul 2013 19:46:23 +0200

2013/7/22 Philipp Hancke <[email-masked]>:
> So far, this mapping works using the elements already defined in XEPs 0167,
> 0293, 0294 and 0320 even.
> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.1 has a quite
> concrete list of features of what functionality the mapping between SDP and
> the xmlish SD has to define.

Thanks for the information.

Just wondering if you would feel more comfortable with a WebRTC API
that provides you real JS Objects/Classes with all the media
parameters and transport information (instead of a SDP blob string) so
you don't need to parse a plain-SDP (which will be different in each
vendor's browser and browser's release and others WebRTC compatible
devices) but instead take the data from JS Object structures and use
it to construct your own signaling protocol.

Thanks a lot.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Jul 2013 19:50:17 +0200

2013/7/22 Roman Shpount <[email-masked]>:
> On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke <[email-masked]>
> wrote:
>>

And will it work with Opera, IE and any other browser without adapting
the code to the SDP those browsers will produce? and will it remain
working in future versions of Chrome and other browsers?

If it was a real JS API and the browsers properly implement it, then
the answer to all these questions would be "yes". But since this is
about dealing with a SDP blob string that can be represented in many
"compatible" ways by different browsers, I don't see it clear
(regardless I don't doubt at all about the quality of the JS code
which seems really good).

Regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 22 Jul 2013 20:27:33 +0200

> Out of curiosity, does the same code work with Firefox?

Yes, feel free to fork it at https://github.com/ESTOS/strophe.jingle and 
try the example. The core mapping has been relatively stable since I 
showed the first public version at the xmpp summit in Brussels six 
months ago.

Things like chrome suddenly (in canary) requiring a mapping of a=rtcp-fb 
weren't helpful and required extra work, but I do not expect this to 
happen too often once the SDP requirements are agreed upon.

It even sends to and receives rtp from Jitsi, even though no side is 
playing out anything yet; that can hopefully be resolved in Berlin.

---

From: tim panton <[email-masked]>
Date: Mon, 22 Jul 2013 19:19:50 +0100

On 22 Jul 2013, at 18:45, Roman Shpount <[email-masked]> wrote:

> On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke <[email-masked]> wrote:
> 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.
> 
> 

As far as Phono is concerned - yes - but we had to do some work to make that happen, more 
work in fact than adding DTLS on the server side, which is (frankly) absurd.

T.

---

From: Hrishikesh Kulkarni <[email-masked]>
Date: Tue, 23 Jul 2013 01:28:24 +0530

Yes. It took some effort on our server side for us to support Firefox with
DTLS (still incomplete) as compared to Chrome with vanilla signaling. I
believe we have long way to build interop in browsers: RTP, JS API and
maybe Signaling (with webserver). ScreenSharing policy is yet to be
resolved.

I see this discussion is stuck at JS API vs JS SDP API, while equally
important standards like screensharing policy are in queue.

regards,
Rishi

On Mon, Jul 22, 2013 at 11:49 PM, tim panton <[email-masked]> wrote:

> On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke <[email-masked]
> > wrote:
>