Subject: [Stox] 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: Ralph Meijer <[email-masked]>
Date: Mon, 22 Jul 2013 17:46:46 +0200

On 2013-07-22 17:14, Iñaki Baz Castillo wrote:
> 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.

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:14:36 +0200

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: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Jul 2013 17:44:54 +0200

2013/7/22 Daniel-Constantin Mierla <[email-masked]>:
> On 7/22/13 5:14 PM, Iñaki Baz Castillo wrote:
>>
> 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.

I was talking about a SIP device also implementing WebRTC in the media
plane. Current WebRTC spec mandates plain-SDP usage in the wire to
signal your media description and transport/ICE information to the
peer. So if you want to communicate with a XEP-0167 compliant
server/endpoint, then you need a gateway to convert the plain-SDP
generated by the browser into the SDP-XML version defined by XEP-0167.

> 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).

Reusing existing JavaScript SIP stacks is something good, don't you agree?

Please, let's focus:

Today from a browser you can speak SIP over WebSocket and connect to a
SIP media server/gateway understanding the SDP of WebRTC. So yes, you
can talk SIP fom a browser.

Today fom a browser you cannot speak XMPP/Jingle (XEP-0167) over
WebSocket (or over AJAX) because the browser produces a plain SDP
blob, while you need a XML based SDP as XEP-1067 states. You can parse
such a SDP blob string in JavaScript and map it into a XML body,
but... good luck with that...

Hope it is clear now.

Regards.

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

---

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: 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: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 22 Jul 2013 18:21:59 +0200

On 7/22/13 5:44 PM, Iñaki Baz Castillo wrote:
> plane.
You wrote a SIP server, just read above.

And producing a xml blob instead of text plain blob does not make much 
difference from the architecture point of view, if that was your 
concern, nor simplifies things.

Cheers,
Daniel

>   Current WebRTC spec mandates plain-SDP usage in the wire to

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Jul 2013 18:26:06 +0200

On 22.07.13, 17:44, Iñaki Baz Castillo wrote:
> peer.

I don't think this is true. You can very well translate the SDP to 
Jingle in the browser and then only send XML on the wire.

I completely agree that this would be a pain, but there is nothing that 
"mandates" against it.

Emil

-- 
https://jitsi.org

---

From: tim panton <[email-masked]>
Date: Mon, 22 Jul 2013 17:29:34 +0100

On 22 Jul 2013, at 17:26, Emil Ivov <[email-masked]> wrote:

> I don't think this is true. You can very well translate the SDP to Jingle in the browser and then only send XML on the wire.
> 
> I completely agree that this would be a pain, but there is nothing that "mandates" against it.

It is a pain - but it is do-able - take a look at PhonoSDK on github.

T.

---

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

> were reasons for the XMPP Council to decide to concentrate efforts

The point where this is interesting for STOX is mostly the -media draft. 
For example we can fix some of the bugs (like a=fmtp) in XSF territory.

Potentially, the -media draft is even the place where to define the 
mapping between jingles xmlish session description and SDP. Even though 
I would attempt to clearly separate that from jingle signalling 
conceptually and in the document.