[Jingle] Today's MUC on the future of Jingle!

Emil Ivov emcho at jitsi.org
Thu Jul 25 00:17:10 UTC 2013

Hey folks,

Couldn't make it for the chat today and a few comments / questions 
popped up while reading through it:

> [15:40:45] <Kev> If a client is implementing SoX, which is SIP in XMPP, so that they can interoperate with other SIP clients...
> [15:40:49] <Kev> (and you can see where I'm going with this)
> [15:40:56] <Kev> what is the advantage of doing that over implementing SIP?
> [15:41:20] <fippo> kev: strong authentication, tcp links, nat traversal

Strong authentication, tcp links and NAT traversal are all available 
with pure SIP as well, so I am not sure if this argument holds. (And I 
am not quite sure how XMPP's NAT traversal even applies to SoX).

> [15:41:22] <stpeter> another premise behind SoX was that Jingle hasn't taken off and we might as well admit the reality of that and recognize that SIP/SDP is how voice and video endpoints get things done (or, in WebRTC, SDP only)

There were a couple of related mails on public-webrtc earlier today (or 
yesterday, depending on where you are):


Both of the above refer to a 2.0 version of the WebRTC API that would be 
lower-level and would not have a dependency on SDP.

I believe this significantly changes the game for Jingle, so I don't 
think we should be in a hurry to recognise that it has failed.

> [15:43:55] <stpeter> as I see it, SoX was not designed to replace Jingle, it was designed for a specific niche of clients and deployment scenarios

Completely agreed! I think it makes a lot of sense for SoX to exist in 
that context and it would be helpful to have such a XEP

> [15:48:37] <paulwitty> having to implement all the SIP state machines in an XMPP client is a right drag - there's a huge amount needed to cope with the fact that SIP messages can be sent over lossy channels

I don't believe SoX would require such a think. It will be about reusing 
an existing SIP stack and plugging a different transport underneath.

snip series:

> [15:50:00] <Kev> I note that I was once in a room where a SIP advocate was asked the question "So, as this is all open standards SIP, we could grab another SIP client and have it interoperate?" and the answer was basically "No. Not unless it's from the same vendor". I don't know how representative that is.
> [15:51:44] <paulwitty> the interop problem is why I'd rather put SIP on the edge of the XMPP world in a gateway, so there's only one place to test interop

In our experience SIP has usually given us satisfactory interop results 
with a number of clients, devices and servers. Quite sadly, the same has 
not been the case of standard Jingle ... We should probably keep this in 
mind (although it could also be construed as the very reason for our 
demonstration of schadenfreude ;) )

> [15:53:42] <Kev> I'm uneasy with the idea of going towards having two mutually incompatible VOIP^h^h^h^hsending voice and video over IP network standards for XMPP without understanding that it's necessary. I'm hearing competing opinions on whether it would be viable to pick one and stick with it (either one).

Can't we just agree that

a) Jingle (and Jingle 2) is our official way of doing RTC and that
b) SoX is just a specific solution for a specific problem. It is not a 
default or even a recommended way of handling RTC with XMPP.

In other words one specification says that if you need to open a bottle, 
you use a bottle opener and you doing "this way". The other tells you 
that if you ever need to open a bottle with a fork then you can do it 
"here's how".

> [15:59:06] <paulwitty> client - client jingle without TURN is fairly useless, to be honest

I suppose you meant "relay" instead of TURN. Let's not forget we have 
Jingle Nodes.

> [16:00:32] <fippo> ralphm: apparently this is getting worse. I hear about 10-15% of calls going trough turn compared to 5-10 some years ago

Thiago once mentioned that this was highly dependent on geographic 
regions, likely because of device manufacturer market share. In some 
regions the amount of relayed calls went as high as 50%.

> [16:02:12] <paulwitty> Jingle Nodes is the best idea I've heard

OK, so you did have that in mind too. Unfortunately Jingle Nodes needs a 
bit more work to make it more like TURN. It currently relies on latching 
for discovering remote addresses which can lead to failures in cases 
involving two relays (and potentially devices with multiple interfaces).

> [16:02:19] <paulwitty> it's the same model as Skype, and that works

If you are referring to "using other users as relays" I think that

a) Jingle Nodes is not really there because it hardly discusses issues 
such as churn or DoS attacks
b) apparently it didn't really work that well:

> [16:03:09] <paulwitty> ralphm: SDP isn't going to go away any time soon

Maybe not, but I bet that it's not going to remain a de facto standard 
for much longer either.

> [16:04:56] <Kev> dwd: We are, finally, getting interoperable Jingle F/T. Yay.

Nice! Who are you interoperating with? What transports?

> [16:11:02] <stpeter> it seems to me that Jingle has been perceived as this interesting little thing off to the side of the RTC mainstream -- and that if we wanted XMPP-based technologies (not necessarily but probably Jingle) to be more central, we'd need to do a lot of work

I suppose I kind of agree with the first part. I don't think I do with 
the second.

> [16:11:57] <dwd> Who here has an actual Jingle voice and/or video implementation?

We do! :)

> [16:16:23] <Kev> paulwitty: Although, saying that, we're comparing with SIP, and my understanding is that one doesn't just SIP to other clients on the Internet?
> [16:16:35] <paulwitty> Kev: no, no-one does that, because it just doesn't work

Hmm ... what? Where did that come from? Of course it works!

> [16:21:30] <Neil Stratford> For everyone - jingle as it stands today is much cleaner and there seems to be a real desire to move SDP in this direction

+1 !



More information about the Jingle mailing list