Blink Cocoa

h1. Known Issues

h2. Blink Pro 3.5.0 

h3. Automatic contact backups fail

This version has introduced a bug that happens during period automatic backup of contacts. To fix this, replace this file: 

<pre>

/Applications/Blink\ Pro.app/Contents/Resources/ContactListModel.py

</pre>

with

http://download.ag-projects.com/Blink/ContactListModel.py

h3. Ringtone problem

For some call scenarios, outgoing ring tone fails to stop playing.

<pre>

/Applications/Blink\ Pro.app/Contents/Resources/AudioController.py

</pre>

with

http://download.ag-projects.com/Blink/AudioController.py

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. Session Requests with no Media

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.

h2. Missing columns in history tables

<pre>

Error: Error getting entries from sessions history table: no such column: sessions.am_filename

</pre>

Add the missing column:

Connect to history database by typing this command in the Terminal application:

<pre>

sqlite3 Library/Containers/com.agprojects.Blink/Data/Library/Application\ Support/Blink\ Pro/history/history.sqlite

</pre>

SQlite prompt appears:

<pre>

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> 

</pre>

Type the following command at the *sqlite>* prompt followed by Enter:

<pre>

ALTER TABLE sessions add column 'am_filename' LONGTEXT DEFAULT '';

</pre>