In my most recent post, I mentioned that RFC 4474 is promising for end-to-end identity, but that there have been some issues deploying it. Let’s explore some of these issues. 

First, some background. As I mentioned, SIP does not come, out of the box, with a clean way to tell the recipient of an offer who sent the offer in the first place. Then came the P-Asserted-Identity (P-AID) extension.

P-AID gave us a new header field for carrying the sender identity–sort of a Caller-ID for SIP. But P-AID offered no integrity protection of the identity. It was useful for carrying identity inside a private network, but was useless if you crossed a trust boundary. There was no way to detect if someone forged or tampered with the identity information before it got to the destination domain.

RFC 4474 gives us the Identity and Identity-Info header fields. An abstract “authentication service” is responsible for authenticating the sender, and checking that the From value contains an address-of-record (AoR) that the sender is allowed to use.  The authenticating service inserts a signed hash of the From value (among other things) into the Identity header field, therefore providing integrity protection of the sender’s identity. If anyone tampers with the From value in route, the recipient can find out by checking the signature.

Sounds great, right? So, what’s the problem?

The argument I hear the most is that RFC 4474 requires a Public Key Infrastructure (PKI). The argument goes that, for one reason or another, we’ve not had success deploying large scale PKIs in general, and it’s not feasible to issue a certificate to every user agent.

This argument neglects the fact that there is at least one very successful large-scale PKI deployment. That is, HTTPS. You probably use HTTPS every day to access your bank’s web page, make online purchases, etc. As it’s usually used, HTTPS doesn’t require your web browser to have a certificate–only the server has one. The various Certificate Authorities are quite happy to sell server certificates to be used with HTTPS.

The simplest way to deploy RFC 4474 is to make the same proxy/registrar that already authenticates user agents (typically using digest authentication) act as the authentication service. The only certificate needed is a server certificate for the proxy/registrar. Client certificates are completely unnecessary. This is exactly analogous to the certificate use in HTTPS.

In case you haven’t noticed, I don’t buy the PKI argument against RFC 4474. Not even a little bit.

In all fairness, there are other arguments against RFC 4474. Probably the biggest ones are the fact that it has problems working across session board controllers (SBCs), and it’s not clear what it means when the sender AoR is a PSTN number. But that’s enough for now–I will discuss the other issues in future posts.

SIP-I and SIP-T refer to two very similar approaches for interworking ISUP networks with SIP networks. In particular, they provide the means for conveying ISUP-specific parameters through a SIP network so that calls that originate and terminate on the ISUP network can transit a SIP network with no loss of information.

SIP-T was developed by the IETF — the same body that developed the SIP protocol itself — around the same time the most recent version of SIP was being developed (mid-2002). It is defined by RFC 3372, RFC 3398, RFC 3578, and RFC 3204.

SIP-I was developed by the ITU in 2004, and made use of most of the constructs defined in the IETF SIP-T effort. It is defined by ITU-T Q.1912.5.

SIP-I and SIP-T both define the mapping of messages, parameters, and error codes between SIP and ISUP. Both of them are fully interoperable with compliant SIP network components on the SIP network.

The key differences between SIP-I and SIP-T are:

1. SIP-I defines a mapping from SIP to BICC (in additional to ISUP), while SIP-T addresses only the ISUP case, and
2. SIP-T is inherently designed for interoperation with native SIP terminals, while SIP-I is restricted for use between PSTN gateways only.

SIP-I and SIP-T also define somewhat different mappings of information between the protocols, mostly in terms of converting from SIP error codes to ISUP cause codes.

The way SIP-I and SIP-T allow transparent transit of ISUP parameters through a SIP network is by attaching a literal copy of the original ISUP message to the SIP message at the ingress PSTN gateway; this ISUP message appears as another body on the SIP message (typically, a peer to an SDP body).

The SIP network ignores the extra ISUP body, processing the SIP message as it normally would. After the SIP service network performs any necessary modifications to the SIP message, it arrives at the PSTN egress gateway. This egress gateway uses the attached ISUP message as the basis for the ISUP message it will send; however, it first makes modifications necessary to match changes made to the SIP message during its traversal of the SIP network.

As mentioned before, with SIP-T, the messages may also terminate on the native SIP terminals in the network, which will ignore the extra ISUP body. Additionally, messages may originate from these SIP phones and terminate on the PSTN gateways, which will then generate a new ISUP message for the PSTN.

Putting this together in a call flow, a typical successful call setup from a PSTN terminal to another PSTN terminal through a SIP network can look something like this:

Yesterday I was reading yet another tech ticker about a possible IPO of Skype. The text went on arguing that with revenues of 600M USD, a couple of hundred million subscribers, a great service in terms of speech quality as well as the combination of text, presence, video and voice, Skype can develop into a really big company. The comments on the article varied between agreement and disagreement with one commentator ending his contributions with: “What I don’t understand is with Skype around, why would anyone use Vonage?”

Skype has surely been the most successful VoIP service provider. Instead of spending endless hours discussing whether NATs are evil things that should be ignored or a reality of any network installation, the guys behind Skype just went for a solution that enabled Skype users to make calls in all kinds of network environments – regardless of how paranoid the network administrator is. And instead of writing hundreds of pages about how presence could be provided or certain features of PSTN that hardly any of us has ever used can be re-implemented with SIP they just implemented what the users actually needed, i.e. a nice combination of presence, video and speech with a small number of useful services. Combined with a high quality voice codec and an easy to install application, Skype had a great advantage against the early SIP-based VoIP applications that had problems with NATs, firewalls and low quality speech codecs.

However, with SIP devices and applications now matching Skype with ease of use, quality of speech and NAT handling – is there much difference left between Skype and a SIP provider such as Vonage? The answer is basically “no.” Both enable users to make cheap phone calls and both are based on the same business model; namely that of any 100 year old PSTN provider, i.e., of “selling minutes.”

The major difference is in the technology behind the service. I do not want to go now into the nearly religious discussions about whether the more distributed peer-to-peer architecture of Skype is more Internet-like (or web 2.0 if you want) than the more centralized approach of SIP.  The end users do not really care whether their phones are using Skype or SIP or even PSTN as long as they can call their relatives at the other end of the world for free.

In my view, the major distinction is in the openness of the technology.  SIP is an open standard that can be used by any operator. This not only has led to the development of a wide range of high quality open source SIP implementations, but even more importantly, has established an open market in which operators compete with each other for new subscribers while still being able to establish cross operator calls. A similar situation is also present in the infrastructure and user device markets. The open standards have enabled and forced the manufacturers and developers to enter into a healthy competition that is resulting in ever more innovative and reliable equipment.  While Skype is based on a great technology -at least the studies that have tried to figure out how Skype works suggest this, it remains a closed technology that is controlled by only one company. In this, a walled garden type of operator is created that while being itself innovative does not encourage innovation and competition in the open market.

So in summary, it is not a question of whether one prefers this or that company or technology, but whether betting on an open or proprietary technology is more beneficial in the long run.  So I would like to rephrase the title question into: with open standards around why use proprietary ones!

There is no particular threshold for the number of NATs (Network Address Translators) between clients beyond which calls are more likely to fail. In fact, in most situations, the endpoints can’t tell the difference between having one or dozens of NATs between them. If the NATs all share the same kind of policies for allowing return traffic (referred to as port-restricted or full-cone policies for example), and are “pointed the same way” (meaning the translation is all in one direction) a series of NATs will appear exactly like one NAT. When NATs with different return traffic polices are mixed (again pointed the same way), the result is usually identical to a single NAT with the most restrictive of the policies.

The situation is different when each endpoint has its own NAT (or series of NATs), so that translation is happening in both directions. The combined effect of those two NATs is not the same as what any one NAT would produce. But, with a few caveats, to understand the potential effect of multiple NATs between endpoints, you really only need understand having one NAT between the endpoints or two nats facing in opposite directions. Having many layers of NATs usually won’t make matters worse.

Fortunately, the suite of standard NAT traversal technologies (including STUN, TURN, and ICE) developed for use with SIP will allow media to work in all of the NAT combinations described above.