sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
A week ago I got motivated to build a basic XMPP stack for sipsorcery in order to see how SIP-to-XMPP calls would go with Google Voice. In my last blog posts I’d been successful in getting my phone to ring using a quick and dirty application that sent a pseudo-XMPP request to Google Voice. The pseudo stems from the fact that the requests being sent were based on manual inspection of an Asterisk 1.8 to Google Voice communication rather than having any software that actually understood XMPP.
After a couple of days I had the XMPP stack pretty much complete, for client side operation at least, and was again able to get my phone to ring. I incorporated the stack into the sipsorcery application server and proceeded place a call through it from one of my IP Phones eagerly anticipating the RTP stream arriving from Google Voice. Silence. Hmm I must have wired things up incorrectly. After double checking it all looked good and I eventually determined there were some additional steps required to get the RTP started after the signalling had completed its work.
The XMPP from Google Voice supplies RTP endpoints as a series of candidates in an ICE type format. ICE is the replacement for STUN and is a standard that details a set of steps to try and deal with NAT. Confusingly ICE uses a new version of STUN which also goes by the name of STUN – seriously somebody should be tarred and feathered for that one; create a new standard that uses the same acronym as the one it replaces creating a never ending source of confusion about which STUN STUN stands for!
Back to XMPP. There is a standard that deals with setting up RTP via XMPP called Jingle ICE-UDP Transport Method. Unfortunately as with the other Jingle standards I’ve perused the Google Voice XMPP server does not support them or supports an earlier or custom version. I wasted some time trying to send a STUNv2 (that’s the STUN from RFC5389) request to the RTP candidate socket for a few days before going back to my Asterisk 1.8 server and looking at what it was doing. It was sending a STUNv1 (that’s the STUN from RFC3489) request with a username attribute. I’d been attempting a STUNv2 request with username, message integrity and fingerprint attributes. I’m now getting a STUNv1 response from the Google Voice end which means hopefully I’m not too far away now from getting the RTP flowing.
I’m still very curious as to where the FreeSWITCH/Asterisk 1.8 developers got the info on the mechanisms to integrate with Google Voice over XMPP. Everytime I get stuck and go and look at a standard I end up finding it’s not being used. I found that with Jingle and now with ICE even though the Google Voice XMPP is sort of using them both.
