MostEncounteredProblems » History » Revision 14
Revision 13 (Adrian Georgescu, 06/06/2013 12:20 PM) → Revision 14/41 (Adrian Georgescu, 06/06/2013 12:21 PM)
h1. Most Encountered Problems h2. Interoperability Issues It is possible that other software works while Blink does not. Possible causes are: * A configuration issue (e.g. the server does not accept a codec proposed by Blink and instead of refusing the call using a proper code, it simply does not answer) * This is bold statement but we have seen it so many times. Two broken devices can work well together until one gets fixes or a newer is brought in. We have seen many cases where both the client and server were old and buggy but worked well with each other. Blink is newer software that emerged after standards have been matured and we put lot of effort into making it work correctly according to the standards, while we may have not achieved 100% correctness, we still do better than many older implementations that implemented the standards before they were in a final shape. If this is the case or not, the SIP trace can indicate whether Blink or the other server or device is wrong. If Blink got it wrong we can fix it, just report the problem to the mailing list. * The requirement of SIP service provider to "wrongly use STUN for NAT traversal purposes", see STUN section below. purposes":http://projects.ag-projects.com/projects/blinkc/wiki/KnownIssues#STUN-is-not-supported h2. STUN is not supported 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: *Experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution.* 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. h2. Request Timeout (408) This means that Blink is not able to communicate with the SIP server, that is, it gets no reply for his requests. Several reasons can cause this: * Incorrect account configuration (wrong SIP Proxy address) - you can fix this yourself by changing the account information * Software firewall installed on computer blocking the software - you can check or fix this by asking the system administrator * Network firewall blocking traffic - you can check or fix this by asking the network administrator * SIP Server does not answer - you must ask for support the SIP service provider and provide them the SIP trace h3. How to troubleshoot this? * You can eliminate some of the possible causes by using a SIP account provided by Blink. For this add a new SIP account in Blink and select *Create a Free Account* option. * Check the Logs from menu Windows -> Logs -> SIP. Make a call and provide the logs to your service provider. h2. Time Machine Backups Some people reported issues with re-installing Blink from a Time Machine backup. This issue has nothing to with Blink but with Apple Store in general and Time Machine in particular. Nevertheless, you can solve it by purging completely Blink and re-installing it again from the App Store. Delete the following files: * /Applications/Blink Pro * ~/Library/Containers/com.agprojects.Blink/ * ~/Library/Preferences/com.agprojects.Blink.plist