[Jingle] Today's MUC on the future of Jingle!
emcho at jitsi.org
Thu Jul 25 00:17:10 UTC 2013
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.
> [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
> [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
> [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
> [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
More information about the Jingle