linphone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linphone-users] "cannot start transport on port 5060" on Rasberry Pi


From: Csaba Peterfalvi
Subject: [Linphone-users] "cannot start transport on port 5060" on Rasberry Pi
Date: Sun, 31 Mar 2019 15:50:58 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0

Hi,

I am running Linphone 3.6.1 on my Raspberry Pi 2b with the most recent Raspbian Stretch (Release date:2018-11-13, Kernel version:4.14). I have exactly the same issue as the gentleman who have already posted the bug at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906057 in August last year so I will just copy here his description. Note that the same bug is also affecting several other users, many hits come up when you google for [ linphone "could not start tls transport on port 5060" ].

At start-up Linphone complains as follows:

Could not start tls transport on port 5060, maybe this port is already used.

It is impossible to establish a call, or register to a SIP server.

The following approaches were attempted:

a) Changing from TLS to UDP or TCP

        Result: exactly the same problem remains.

b) Modifying the port number

Result: no matter what port number is put, exactly the same issue occurs.

        Checking with lsof -i -n -P, it appears that none of the ports
introduced are actually used. Linphone believes a port is in use while it is not.

d) Relying upon IPv6 instead of IPv4.

        Result:
        c.1) Linphone no longer complains about an occupied port.
        c.2) Linphone starts correctly listening to the port in question.
     lsof -i -n -P | egrep -i 5060 shows (for instance)

     linphone  9737     casaise   25u  IPv6 281289      0t0  UDP  *:5060

c.3) However, it remains impossible to register the accounts to SIP servers. c.4) Calling test accounts results in Linphone attempting to establish the call but never managing to do it (timing out).

e) Some in the Internet suggest that the reason is a lack of privileges for the user and that adding the user to the group plugdev or netdev could resolve the situation.

        Result: the problem remains as it is.

f) The SIP utility Ekiga was also installed (but not started). Using Synaptic, it was removed from the installation.

        Result: the problem remains as it is.


Thank you for your help in advance.

Best regards,
Csaba



reply via email to

[Prev in Thread] Current Thread [Next in Thread]