Here at VoIP.co.uk, we're in a fairly unique position in that our entire SIP platform short of our PSTN gateways is written in-house. Our SIP stack that has been developed over the last 3 years is deployed in in all of our signalling elements throughout the network, from our B2BUA's used for credit control, core proxies for routing, application servers for network features, registrars used for (funnily enough) registration, and our SBCs used on the edge of the network all contain our SIP stack.
Given that's the case, i'm often asked exactly why we don't implement feature X or feature Y that, on the outside looks like a relatively simple feature to implement, and considering all those other ITSPs that run asterisk can support, yet us with our fancy SIP stack and well designed network can't support. Well, the answer lies in our philosophy behind SIP as a protocol, our vision of the future for SIP, and how we feel ITSPs such as ourselves fit in to what is probably best described as the future of communications itself.
One of the big “things” about SIP from a technical point of view is that it is a well defined protocol that is made up of (what looks like) a fairly simple core protocol designed to be extensible. I say “looks like” because actually even the core standard defined in RFC 3261 is broken in a few places “out of the box”. Anyway, the core protocol specification provides support for being able to initiate and receive sessions (note that sessions doesn't even mean phone calls at this point), bind an endpoint to an AOR, and that's pretty much it. All of the features supported by RFC 3261 assume one thing that is very rare for end users: that there is no NAT and no firewalls between any of the elements involved. As soon as you introduce either, you break your ability to do even the simplest of things like initiate a session to another party (i.e, make a phone call).
Obviously it's fairly rare for users to have SIP devices that are not behind NAT or firewalls when connecting to other hosts on the net, and considering a SIP server couldn't even send a response to a request received from a device behind NAT a lot of the time, the rport extension was defined to allow a client to request that the responses to a request be sent to the source that the request was received from, rather than the contents of the top via header, which contained the devices internal port number.
Sadly, there are a good handful of mainstream SIP devices and soft phones don't specify the rport parameter in outgoing requests, even though they know they want to receive responses at the same place as they sent them (and thus will work through nat), so if we were to stick to the standards and send the response to the port number specified in the top Via header rather than where we received the response, we'd end up with a large number of users not able to make phone calls. Instead, we modify all requests that come in on our main platform to send responses to the same place as we received them, even if no rport parameter was specified.
While this fixes almost all SIP clients, it does break some really old ones, which genuinely expected to receive responses at a different port number and are not behind NAT (that behaviour would anyway not work behind NAT). So by fixing one set of clients, we've broken another set, and this is a very common theme throughout SIP deployments.
The only viable solution is to provide a number of different proxies (physical or virtual, which is irrelivant), some of which do the things they're not really “supposed” to so like always send responses to the source, and others do things “by the book”. In itself this seems like a viable solution, but when you consider the number of clients that are out there, and they're all broken in different ways, you end up with a huge number of different proxies (virtual or not) with slightly different handling for different types of clients. Combine that with wanting to have each and every element redundant, and you end up with .. .a complete mess.
In addition to the logistical nightmare on the ITSPs side, performing all of these "fixes" for NAT, broken devices, and feature emulations that SBCs and B2BUAs do are not good for customers in the long run; they break the end to end transparency that SIP brings us, which is the main benifit of this whole VoIP thing.
"What!", i hear you say, "it's cheap calls, that's what this VoIP stuff gives me, not end to end transparency, whatever the hell that is!". Well, no, not really - cheap calls are just a side effect of every man and his dog installing asterisk on a server hosted somewhere, buying minutes from a carrier, and reselling them. Most can't even tell you the reason there is both a tag and branch parameter, if they even knew what it was. scary. That's as bad as an ISP not having anyone know anyhting about routing. ohh, hang on ... Anyway, i digress ...
Sure, we offer PSTN termination at a reasonable charge, but that's besides the point (we're a business and need to make money, too); We're about the technology and the vision. About how it can change communications (and not telecommunications) as a whole.
Part of that vision involves end to end transparency - something that can't be done today with all the SBCs and B2BUAs that are sitting in VoIP networks. The SIP standard does, to ensure end-to-end features are not broken, limit the modifications that a proxy can make to a message. While that's great in a trusted environment without any complications like NAT or firewalls like at home or in an office, in the real world ITSPs currently need to be able to do more than the standards allow in order to be able to provide the features that users demand to broken devices. And, the next installment of this series will be on exactly that: The SIP Endpoint.
Labels: sip
