Jingle Adventures contd…

There was an announcement a while ago on the xmpp.org site about Google’s adoption of the official Jingle standard. The same announcement was posted by Peter Thatcher a Google engineer to the Jingle mailing list. The announcement got a bit of attention and I originally came across it on Hacker News. After spending a fair bit of time looking into what the upgrade means as far as integrating with Google’s XMPP service the conclusion I’ve come to is not much at least not yet.

The original reason I, a SIP person, started messing around with XMPP and Jingle was to see if there was a better way to integrate with Google Voice. I made a few blog posts at the time and ultimately the investigation didn’t end up yielding any fruit because of a peculiarity in the way the Google XMPP server deals with the RTP media streams which would preclude it working with standard SIP devices (very briefly it requires that STUN packets are exchanged on the RTP sockets before the RTP can flow).

So fast forward 8 months and I finally found some time to delve into the Google XMPP service again to see if there’s any chance of getting SIP interop, or more correctly RTP interop for SIP devices, working. The other thing that spurred me on a bit was Google + and specifically the integration of the Google Talk Gadget into the Google + application. The Google Talk Gadget is not new it’s been in Gmail for quite a while but the integration looks a lot more interesting with Google +, specifically being able to call from a SIP phone into a Google + Hangout (a web based voice/video conference call) would be cool.

As alluded to above the results of my latest little adventure into Google XMPP land haven’t been very fruitful. Yes Google now appear to be sort of using Jingle for their call set up but the media side of things doesn’t appear to have changed at all and in fact the original email from Peter Thatcher did state the work on XEP-0176: Jingle ICE-UDP Transport Method, which is more down to the nuts and bolts of the RTP side of things, is ongoing. In the meantime the XMPP call set up mechanisms used by Google are a combination of Jingle and Gingle (Google’s original implementation of a Jingle like protocol) and crucially the media layer is still Gingle.

My hope is that when Google get the Jingle ICE-UDP transport implemented they will also implement the XEP-0177: Jingle Raw UDP Transport Method which should allow RTP level interop with SIP devices which will in turn allow SIP Proxy services like SIP Sorcery to make and receive calls with Google’s XMPP network. Some SIP servers that proxy media such as Asterisk and FreeSWITCH are already integrating with Google’s XMPP network by implementing the Gingle/XEP-0176 STUN connectivity check mechanisms on the RTP sockets. In SIP Sorcery’s case and also for other non-media proxying servers such as Kamailio the integration is not possible because it then needs the end SIP devices to do the STUN connectivity checks and until ICE support becomes widespread they wont be able to.

Unfortunately this is another example of the really painful issues caused by NAT. If NAT had never been invented and the World had been forced to upgrade to IPv6 the internet would be a much better place :). In the meantime communications protocols like SIP and XMPP end up with as many addendums and extensions to deal with NAT as they do to deal with their core functions!

  1. Rob’s avatar

    From a networking standpoint, I can share your disdain for NAT, but I have to disagree when you say the internet would be a much better place without NAT. I think many of the advancements in technology over the last decade owe a lot to the development of NAT. If it hadn’t been for NAT, customers would need to obtain (typically pay for) a unique IP address for each device they wanted to connect to the internet.

    Many technologies that are now considered staples, probably never would have taken off. Home/public wireless [router]? The device itself would require an IP address. So, in addition to the upfront cost, consumers would have to cough up a monthly fee for each additional device. Streaming TV/movie boxes? Why pay for an additional IP address so that you can receive it via the web when cable/sat/ota can offer similar quality? Internet connected game-consoles? You might as well game on your (at the time at least) more powerful PC that you have connected to the internet*. And of course, VoIP- why would someone pay for an additional IP address just receive a phone service over the internet when they already have a dedicate line to their house?

    Additionally, how might e-commerce have been affected? The most popular OS has come a long way in the last decade in regards to security. But, by today’s standards, it did little to protect itself/others in regards to the internet. For many, NAT, more by consequence of design, provided a level of protection to your average consumer. Without the ‘protection’ of NAT, how much worse would worms such as Blaster and Welchia have been? Would consumer confidence in e-commerce and on-line banking have matured to the point it is today?

    I see where you are coming from, that if we used up our IP space, we would have been force to embrace IPv6. But, in my opinion, it was the end cost to the user that drove them to NAT. And when IPv6 does eventually dominate, it will only be possible because ISPs will be more or less forced to change their way of billing per IP address.

    Rob

    *Actually, I’m not so sure that this would have been a bad thing

    Reply

    1. sipsorcery’s avatar

      I imagine NAT seemed like a really clever idea when it was first conceived as a quick and dirty means of solving an immediate problem of sharing a single IPv4 address. However over time as it became the de facto way of operating for ISP’s and hardware manufactures more and more complications crept in for various internet protocols such as FTP, RTP, SIP etc. etc. Those protocols then required addendums to cope with not just NAT but the different flavours of NATs. All in all the effort and cost that’s gone into not just incorporating NAT but also the mechanisms to fix all the protocols it breaks will far far outweigh the cost of switching to IPv6.

      I’m a big believer that the simplest solution is almost always the right one. The problem in this case is the shortage of IPv4 address space. The simplest solution is to switch over to IPv6 to increase the address space. It has to happen eventually anyway so all the time and effort expended on NAT will ultimately be worthless.

      Reply

Reply

Your email address will not be published. Required fields are marked *