[Blink] Problem with 1&1
ag at ag-projects.com
Tue Mar 15 17:31:35 CET 2011
This is an unfortunate tell of the SIP industry. I will put it into my own words here. Feel free to comment or add your thoughts about it.
What 1 & 1 does is the following:
They are asking the SIP client to do some heuristic guess about their public IP address and port and present that combination into the all SIP requests made to their SIP server by putting it into the SIP Contact header. This is using STUN, a technique that was unfortunately labeled in the beginning as a NAT traversal solution. Later, this was rectified at IETF and STUN was finally coined as what it actually was, just another tool to try to help out NAT traversal. Try but not necessarily achieve. At the same time, some SIP operators took it literally and thought that by forcing clients to use STUN, they got the universal answer for NAT traversal without doing much effort in their infrastructure whereas it was not the case.
STUN checks are unreliable because they depend on the behavior of the NAT routers, which is not something you can control or guess. NAT router behavior, though attempts were made to standardize it, there is not way to determine it from a client or server. Even if the client does this un-deterministic guess, it may work or not depending on the type of NAT in between. STUN can only be used to guess an IP address and port after which you must actually check if the connectivity really works on the obtained IP address and port by exchanging packets with the final target. ICE protocol that implements NAT traversal for media does exactly this and in this context STUN makes sense to be used. Not for SIP signaling and Contact headers.
1 & 1 is a successful SIP provider in Germany, they claim that they have millions of 'active' users
1 & 1 passed the burden of solving their NAT traversal to their clients by using STUN or SP ALG enabled routers, both the most unreliable and undeterministic ways of solving NAT traversal
At the same time, 1 & 1 is using a SIP Express Router variant, that has full capability to perform NAT traversal for their customer. The software is there and can do it, is just not configured for it.
Now the consequence of this is:
Some SIP clients who try to do the heuristic check may work or not depending on type of NAT they are behind. Try is trial and error and no way to debug it when it does not work. Completely undeterministic behavior.
Blink does not work, but deterministically. At least you know where you stand and why. 1 & 1 built a scalable system by simply not doing anything related to helping their client traverse the NAT which many any other SIP operators do, as is good operational practice not to rely on external factors to provide a reliable service.
Another case of Two broken things can work well together. This time even worse because it works only sometime.
Now Blink customers are not amused by this story, no matter how they read it.
What shall be done about it? Should Blink build something that works 'sometime' or should 1 & 1 fix they service to work with any client in every case?
On Mar 15, 2011, at 4:46 PM, Dietmar Krick wrote:
> Hi, after buying Blink from Appstore I found in the mailing list that there is an issue with 1&1 and will not work at this time.
> So, here is another user who is hoping you will do a change to enable 1&1.
> Greetings, Dietmar
> Blink mailing list
> Blink at lists.ag-projects.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Blink