Version 31 (Adrian Georgescu, 04/16/2013 12:27 pm)

1 1 Adrian Georgescu
h1. Known Issues
2 1 Adrian Georgescu
3 29 Adrian Georgescu
4 27 Adrian Georgescu
h2. STUN is not supported
5 27 Adrian Georgescu
6 28 Adrian Georgescu
Blink does not interoperate with SIP service providers that require STUN for REGISTER. STUN is an obsolete broken standard that claimed  that it solved NAT traversal problem. More concrete, these providers require the use of public IP addresses in the Contact header by the end-points when they REGISTER or make outgoing SIP sessions. As most of the end-points are located behind a NAT-ted router and using a private IP address, the way to obtain a public IP address was by using a protocol named STUN, which was wrongly described in 2003 as a NAT traversal solution (this is IETF standard RFC3489). Years later in 2008, this standard has been rectified (in RFC5389) to explicitly say that it does not provide a reliable solution for the original purpose and it should not be used the way it was originally thought. Using STUN is unreliable because it depends on the way the NAT routers are implemented, which is not standardized nor can be probed and guessing the IP address and port used for outbound connections was not working deterministically. Also, it is unsecure behaviour for a server to trust an IP address expressed in a header by a client. The new version of the STUN protocol defined in RFC 5389 explains in which context STUN may be used and advises against the use of STUN as a standalone NAT traversal utility, quote from the standard:
7 27 Adrian Georgescu
8 28 Adrian Georgescu
*Experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution.*
9 27 Adrian Georgescu
10 28 Adrian Georgescu
Unfortunately, some SIP service providers have not updated their implementations to fix this issue, which implies using a simple technique that is using for replies the actual IP and port where the packets originate from rather than using the ones presented in the Contact header. Blink was developed in 2009. Implementing a broken standard from 2003 which was deprecated in 2008 was not considered and is not on the roadmap.
11 31 Adrian Georgescu
12 31 Adrian Georgescu
h2. Session Requests with no Media
13 31 Adrian Georgescu
14 31 Adrian Georgescu
Blink rejects incoming session request with no media (no SDP body present in INVITE message). Some phones simply assume somehow that audio is the only possible media type. Blink does not interoperate with these devices.