Problem Solving On Mac

Support from Developers

If you need support for a particular problem you can mail us directly to support@ag-projects.com. Please try this as a last resort as the answer may already be available on the discussion forum or other users may have encountered your problem while the developers may not.

Sending A Crash Report

If the software crashes or fails to handle incoming or place outgoing calls you can send the logs for analysis as follows:

• Make sure you run the last version available in the Mac App Store

• Go to menu Window -> Logs. Enable SIP (check box Everything and select all applications), Notifications and Engine logs

• Go to Preferences -> Advanced -> File Logging

• Check boxes Log SIP Signaling, Log Notifications and Log Core Engine

• Click on the Purge Logs button

• Repeat the action that causes the problem

• Make an archive with:

  • All files in the folder ~/Library/Containers/com.agprojects.Blink/Data/Library/Application\ Support/Blink\ Pro/logs/

  • /var/log/system.log If the file is too big, you can filter the log lines by using in Terminal application the command:

    grep Blink /var/log/system.log > activity.txt

    or by using the Console application, you can filter by 'Blink' and save the output to file.

  • In case of complete software crash, the Blink crash report, you can find it using Console application

• Send the archive to support@ag-projects.com

Don't forget to disable the logging once you are done with their collection.

Non-critical Errors

Blink errors are logged in the OSX system log file /var/log/system.log. You can find them by opening Applications -> Utilities -> Console, selecting LOG FILES -> system.log and typing Blink in the search bar. Please provide us with this information when you report the problem you encountered.

Software Crashes

If you experience a software crash, please send the complete crash report available in the crash reporter window (just copy and paste from it).

Crash reports are saved in ~/Library/Logs/DiagnosticReports/.

Configuration File

Blink accounts and settings are stored in a flat-text configuration file.

Pro version:

~/Library/Containers/com.agprojects.Blink/Data/Library/Application Support/Blink Pro/config

Lite version:

~/Library/Containers/com.agprojects.BlinkLite/Data/Library/Application Support/Blink Lite/config

SIP2SIP version:

~/Library/Application Support/SIP2SIP/config

Do not edit this file manually. If you did and Blink does not start you must delete the file and start all over again.

Please report your OS name and version and Blink version. You can find Blink version in menu Blink -> About.

Passwords are not stored in the configuration file but in the system keychain.

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.

Missing columns in history tables

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

Solution - Add the missing column

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

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

SQlite prompt appears:

Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>

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

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

Interoperability Issues

It is possible that other software works while Blink does not. Possible causes are:

• 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.

• 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

• The requirement of SIP service provider to wrongly use STUN for NAT traversal purposes, see STUN section below.

SIP Provider requires STUN

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.

Contact header issues

Some SIP providers require that the contact header send by Blink contain certain values:

• Only public IP addresses in the domain part

• Only numbers in the username part

• Username the same as the authentication username

• Username the same as the From Header username

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.

Even by applying such arbitrary rules (which are nowhere specified) a SIP device will also fail to achieve some basic functions:

• NAT traversal can be incorrectly handled (see wrong usage of STUN protocol in this page)

• Will reveal the identity of the login credentials in the Contact header, information that is present end-to end in the signalling

• 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.

This is what the standard mandates about the SIP Contact header:

8.1.1.8 Contact

    The Contact header field provides a SIP or SIPS URI that can be used
    to contact that specific instance of the UA for subsequent requests.
    The Contact header field MUST be present and contain exactly one SIP
    or SIPS URI in any request that can result in the establishment of a
    dialog.  For the methods defined in this specification, that includes
    only the INVITE request.  For these requests, the scope of the
    Contact is global.  That is, the Contact header field value contains
    the URI at which the UA would like to receive requests, and this URI
    MUST be valid even if used in subsequent requests outside of any
    dialogs.

    If the Request-URI or top Route header field value contains a SIPS
    URI, the Contact header field MUST contain a SIPS URI as well.

    For further information on the Contact header field, see Section
    20.10.

20.10 Contact

    A Contact header field value provides a URI whose meaning depends on
    the type of request or response it is in.

    A Contact header field value can contain a display name, a URI with
    URI parameters, and header parameters.

    This document defines the Contact parameters “q” and “expires”.
    These parameters are only used when the Contact is present in a
    REGISTER request or response, or in a 3xx response.  Additional
    parameters may be defined in other specifications.

    When the header field value contains a display name, the URI
    including all URI parameters is enclosed in “<” and “>”.  If no “<”
    and “>” are present, all parameters after the URI are header
    parameters, not URI parameters.  The display name can be tokens, or a
    quoted string, if a larger character set is desired.

    Even if the “display-name” is empty, the “name-addr” form MUST be
    used if the “addr-spec” contains a comma, semicolon, or question
    mark.  There may or may not be LWS between the display-name and the
    “<”.

    These rules for parsing a display name, URI and URI parameters, and
    header parameters also apply for the header fields To and From.

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

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:

• Disable OPUS codec in RTP Media section

• Disable sRTP encryption in RTP Media section

• Disable ICE in Nat Traversal section

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

Beach balling

Blink is not responsive and a beach ball appears after the call ends. Here are some possible reasons: