Version 40 (Adrian Georgescu, 08/15/2013 06:05 pm)

1 1 Adrian Georgescu
h1. Most Encountered Problems
2 1 Adrian Georgescu
3 12 Adrian Georgescu
h2. Interoperability Issues
4 12 Adrian Georgescu
5 12 Adrian Georgescu
It is possible that other software works while Blink does not. Possible causes are:
6 12 Adrian Georgescu
7 23 Adrian Georgescu
 * The SIP Server does not like the offer proposed by Blink (like a certain header or codec) and instead of refusing the call using a proper code as mandated by the SIP standard, it simply does not answer. You must send the SIP trace obtained from Blink to the SIP service provider and ask them for support. If they point to a problem in Blink implementation we will do our best to fix it. 
8 20 Adrian Georgescu
 * 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 "Blink Support Forum": 
9 1 Adrian Georgescu
 * The requirement of SIP service provider to wrongly use STUN for NAT traversal purposes, see STUN section below.
10 33 Adrian Georgescu
11 33 Adrian Georgescu
h3. Service Providers
12 33 Adrian Georgescu
13 33 Adrian Georgescu
For information about particular service providers or equipment type go [[ServiceProviderIssues|here]] 
14 14 Adrian Georgescu
15 18 Adrian Georgescu
h2. SIP Provider requires STUN
16 14 Adrian Georgescu
17 14 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:
18 14 Adrian Georgescu
19 14 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.*
20 14 Adrian Georgescu
21 14 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.
22 12 Adrian Georgescu
23 24 Adrian Georgescu
h2. Contact header issues
24 24 Adrian Georgescu
25 28 Adrian Georgescu
Some SIP providers require that the contact header send by Blink contain certain values:
26 24 Adrian Georgescu
27 24 Adrian Georgescu
 * Only public IP addresses in the domain part
28 24 Adrian Georgescu
 * Only numbers in the username part
29 31 Adrian Georgescu
 * Username the same as the authentication username
30 31 Adrian Georgescu
 * Username the same as the From Header username
31 24 Adrian Georgescu
32 26 Adrian Georgescu
*These requirements are completely arbitrary* and plain wrong as the SIP standard (RFC3261) does not impose any restrictions on the content of the Contact header besides being a valid SIP URI. This SIP URI is an  ephemeral address that conveys the attachment point to the Internet of the SIP device, it is not designed for authentication or conveying of identity. There is nothing to fix in Blink in this respect, those SIP service providers are simply out of touch with reality and restricted the use of their SIP service with other devices that are broken in the same way as their SIP server.
33 24 Adrian Georgescu
34 27 Adrian Georgescu
Even by applying such arbitrary rules (which are nowhere specified) a SIP device will also fail to achieve some basic functions:
35 27 Adrian Georgescu
36 30 Adrian Georgescu
 * NAT traversal can be incorrectly handled (see wrong usage of STUN protocol in this page)
37 27 Adrian Georgescu
 * Will reveal the identity of the login credentials in the Contact header, information that is present end-to end in the signalling
38 27 Adrian Georgescu
 * Would not be able to handle properly incoming calls when more than one account is configured in the device. Incoming calls match an account based on the Request URI that is the same as the Contact header used during Register phase. If multiple accounts have the same Contact header, it is impossible to know which account has been targeted.
39 27 Adrian Georgescu
40 24 Adrian Georgescu
This is what the standard mandates about the SIP Contact header:
41 24 Adrian Georgescu
42 24 Adrian Georgescu
43 24 Adrian Georgescu Contact
44 24 Adrian Georgescu
45 24 Adrian Georgescu
   The Contact header field provides a SIP or SIPS URI that can be used
46 24 Adrian Georgescu
   to contact that specific instance of the UA for subsequent requests.
47 24 Adrian Georgescu
   The Contact header field MUST be present and contain exactly one SIP
48 24 Adrian Georgescu
   or SIPS URI in any request that can result in the establishment of a
49 24 Adrian Georgescu
   dialog.  For the methods defined in this specification, that includes
50 24 Adrian Georgescu
   only the INVITE request.  For these requests, the scope of the
51 24 Adrian Georgescu
   Contact is global.  That is, the Contact header field value contains
52 24 Adrian Georgescu
   the URI at which the UA would like to receive requests, and this URI
53 24 Adrian Georgescu
   MUST be valid even if used in subsequent requests outside of any
54 24 Adrian Georgescu
55 24 Adrian Georgescu
56 24 Adrian Georgescu
   If the Request-URI or top Route header field value contains a SIPS
57 24 Adrian Georgescu
   URI, the Contact header field MUST contain a SIPS URI as well.
58 24 Adrian Georgescu
59 24 Adrian Georgescu
   For further information on the Contact header field, see Section
60 24 Adrian Georgescu
61 24 Adrian Georgescu
62 24 Adrian Georgescu
20.10 Contact
63 24 Adrian Georgescu
64 24 Adrian Georgescu
   A Contact header field value provides a URI whose meaning depends on
65 24 Adrian Georgescu
   the type of request or response it is in.
66 24 Adrian Georgescu
67 24 Adrian Georgescu
   A Contact header field value can contain a display name, a URI with
68 24 Adrian Georgescu
   URI parameters, and header parameters.
69 24 Adrian Georgescu
70 24 Adrian Georgescu
   This document defines the Contact parameters "q" and "expires".
71 24 Adrian Georgescu
   These parameters are only used when the Contact is present in a
72 24 Adrian Georgescu
   REGISTER request or response, or in a 3xx response.  Additional
73 24 Adrian Georgescu
   parameters may be defined in other specifications.
74 24 Adrian Georgescu
75 24 Adrian Georgescu
   When the header field value contains a display name, the URI
76 24 Adrian Georgescu
   including all URI parameters is enclosed in "<" and ">".  If no "<"
77 24 Adrian Georgescu
   and ">" are present, all parameters after the URI are header
78 24 Adrian Georgescu
   parameters, not URI parameters.  The display name can be tokens, or a
79 24 Adrian Georgescu
   quoted string, if a larger character set is desired.
80 24 Adrian Georgescu
81 24 Adrian Georgescu
   Even if the "display-name" is empty, the "name-addr" form MUST be
82 24 Adrian Georgescu
   used if the "addr-spec" contains a comma, semicolon, or question
83 24 Adrian Georgescu
   mark.  There may or may not be LWS between the display-name and the
84 24 Adrian Georgescu
85 24 Adrian Georgescu
86 24 Adrian Georgescu
   These rules for parsing a display name, URI and URI parameters, and
87 24 Adrian Georgescu
   header parameters also apply for the header fields To and From.
88 24 Adrian Georgescu
89 24 Adrian Georgescu
90 1 Adrian Georgescu
h2. Request Timeout (408)
91 1 Adrian Georgescu
92 3 Adrian Georgescu
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:
93 4 Adrian Georgescu
94 8 Adrian Georgescu
 * Incorrect account configuration (wrong SIP Proxy address) - you can fix this yourself by changing the account information
95 7 Adrian Georgescu
 * Software firewall installed on computer blocking the software - you can check or fix this by asking the system administrator
96 7 Adrian Georgescu
 * Network firewall blocking traffic - you can check or fix this by asking the network administrator
97 7 Adrian Georgescu
 * SIP Server does not answer - you must ask for support the SIP service provider and provide them the SIP trace
98 7 Adrian Georgescu
99 40 Adrian Georgescu
Some servers seem to break when SIP requests contain data they don't understand. Instead of responding with a negative code, there is no reply. Try the following, in the SIP account advanced section:
100 40 Adrian Georgescu
101 40 Adrian Georgescu
 * Disable OPUS codec
102 40 Adrian Georgescu
 * Disable sRTP encryption in RTP media section
103 40 Adrian Georgescu
 * Disable ICE in Nat Traversal section
104 40 Adrian Georgescu
105 5 Adrian Georgescu
h3. How to troubleshoot this?
106 4 Adrian Georgescu
107 21 Adrian Georgescu
 * 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. Then make test calls to 3333 and 4444.
108 1 Adrian Georgescu
 * Check the Logs from menu Windows -> Logs -> SIP. Make a call and provide the logs to your service provider.
109 9 Adrian Georgescu
110 9 Adrian Georgescu
h2. Time Machine Backups
111 9 Adrian Georgescu
112 10 Adrian Georgescu
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:
113 9 Adrian Georgescu
114 9 Adrian Georgescu
 * /Applications/Blink Pro
115 9 Adrian Georgescu
 * ~/Library/Containers/com.agprojects.Blink/
116 9 Adrian Georgescu
 * ~/Library/Preferences/com.agprojects.Blink.plist
117 34 Adrian Georgescu
118 35 Adrian Georgescu
h2. Beach balling
119 1 Adrian Georgescu
120 37 Adrian Georgescu
Blink is not responsive and a beach ball appears after the call ends. Here are some possible reasons:
121 1 Adrian Georgescu
122 37 Adrian Georgescu
h3. Logging is enabled
123 1 Adrian Georgescu
124 39 Adrian Georgescu
 * Go to Blink Preferences -> Advanced ->File Logging, all checkboxes but be unchecked
125 39 Adrian Georgescu
 * Open Logs Window. Disable logging in every tab.
126 39 Adrian Georgescu
127 39 Adrian Georgescu
h3. Address Book integration
128 39 Adrian Georgescu
129 39 Adrian Georgescu
Some people with large amount of contacts in Address Book (several thousands) reported similar issue. Try disable Address Book integration in  Blink Preferences -> Contacts and use the Address Book plugin to dial directly from address book