Sunday, May 08, 2005

SkypeOut and SkypeIn Gateways

I've been thinking about SkypeOut and SkypeIn.

For Skype-to-Skype calls, Skype, as has been
documented, uses a proprietary call signaling protocol and the GIPS iSAC and iLBC codecs. It is also reported that Skype uses G.729a for SkypeOut calls. I'm assuming the same holds for SkypeIn calls

Skype shows
Colt, Level3, iBasis, Teleglobe, Cable & Wireless, and B3G as "Carrier Partners", implying that these are the companies that provide the interfaces to the PSTN.

Somewhere, SkypeOut traffic has to be converted from G.729a packets to G.711 A-law or mu-law TDM (and the reverse for SkypeIn). And somewhere, call control signaling has to be converted to some standard PSTN signaling for network interconnection.

A couple of questions come to mind:

1. What are the media gateways that convert G.729a VoIP to G.711 TDM, and who owns and runs them?


2. How do the Skype clients communicate with the media gateways?


Now, I have no real information on this topic and have done no experimentation to try to figure this out (it'd be interesting to see Salman Baset and Henning Schulzrinne revisit their Skype Analysis cited above for SkypeIn/SkypeOut). However, some detective work and reasoning can lead to some interesting conjectures. Bear in mind that these are just that - conjectures. Differing views are welcomed...

First conjecture: Skype uses direct IP handoff to their carrier partners; the carrier partners do the TDM conversion.

Reasoning: first, several of Skype's Carrier Partners offer VoIP services with direct IP handoff to the carrier network (e.g., iBasis DirectVoIP, Teleglobe VoIPLink, Level3 (3)Voice Termination). Second, Skype's architecture has an almost congenital avoidance of centralized servers under Skype's control. "Apart from the login server, there is no central server inthe Skype network." [Baset and Schulzrinne] And given Skype's model, I'd find it surprising if they invested in any hardware when they could avoid it.

Second conjecture: SkypeOut call control signaling is SIP from the Skype Client through a supernode serving as a SIP proxy and then to the carrier partner's media gateway.

Reasoning: The carriers cited above provide IP handoff using either H.323 or SIP. SIP is a text-based protocol that would be relatively easy to work with for developers familiar with internet methods; H.323 is a binary protocol defined using ASN.1 that wouldn't. SkypeOut error codes (10403, 10404, 10408, 10484, 10487, 10500, 10503) map directly to and have the same meaning as corresponding SIP Response Codes. Skype uses supernodes to assist with functions like firewall traversal and dealing with NAT, so it seems logical they'd use it for SIP proxying as well - and it seems to me counter to the peer-to-peer model to have supernodes translating from Skype's proprietary protocol to SIP. Though the SIP proxy has to be smart enough to know not to encrypt the messages going to the carrier partner's media gateway.

Alternately, Skype could be using dedicated SIP proxy servers instead of supernodes. That would, however, cause them to incur more capital cost for SkypeOut. Which also seems unlikely.

Not conjectured upon at this time: How does the Skype supernode "find" the appropriate partner's media gateway for a given PSTN number?