[Top][All Lists]

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

Re: [Linphone-developers] STUN Fingerprint attribute missing from Linpho

From: Ghislain MARY
Subject: Re: [Linphone-developers] STUN Fingerprint attribute missing from Linphone Android's ICE implementation?
Date: Fri, 24 Oct 2014 09:17:56 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Hi there,

This is not a bug, this is a known limitation. The current implementation of ICE in Linphone does not implement TURN and therefore requires to use our own SIP server (the one used on to be functional. If you want to test the ICE feature, test it using accounts. If you need to use it with a particular SIP server setup, you can contact Belledonne Communications specifying your requirements for a proposal (see


Le 23/10/2014 19:34, Peter Villeneuve a écrit :
OK, here's further confirmation that ICE in Linphone (android) isn't working properly.

This time both UACs are freshly installed linphones on the same subnet. So the problem doesn't seem so much "just" an inter-operability issue with other UACs, but rather a buggy ICE implementation in linphone itself.

How can I help the Linphone developers debug this further?

My company was keen on acquiring a linphone commercial license for a big deployment, but buggy ICE is pretty much a deal breaker.
I don't want to "blame" Linphone just yet so I would appreciate it if someone could confirm my findings on a freshly installed Linphone on Android.



wake_lock_release(): Android wake lock released [ref=0x202005da]
Garbage collecting unowned object of type belle_sip_hop_t
Garbage collecting unowned object of type belle_sdp_session_description_t
ice: Send binding request for Waiting pair 0x6c754320: --> [01c3e44991e7f62bf9c92054]
ice: Recv binding request: <-- [014bd93dc81c855a8771d97a]
ice: Received binding request missing MESSAGE-INTEGRITY attribute
ice: Send error response: --> [014bd93dc81c855a8771d97a]

P.S. The call ends up going through OK except it is sending the RTP payloads to the gateway address ( instead of directly to the peer ( Very weird.

Audio session's route
RTP: 85.xx.xx.xx:7076 -->

On Thu, Oct 23, 2014 at 5:59 PM, Peter Villeneuve <address@hidden> wrote:
More info from my previous email.
I have been testing calls between linphone android and groundwire iOS with ICE enabled on both sides and both UACs using the same STUN server.

Looking at the logs from both UACs, I can confirm that indeed there is an ICE problem.

Even when both UAC are on the same subnet, ICE connectivity checks fail which makes no sense at all.

Groundwire logs:

Sending ICE packet.
 Local Address: ICE:; UDP: WiFi[
Remote Address: ICE:; UDP:
        Packet: Request Binding; Id: 3D243D50DE89AF81EE88B2C8

Sending ICE packet.
 Local Address: ICE:; UDP: WiFi[
Remote Address: ICE:; UDP:
        Packet: Request Binding; Id: 4AA1D156DC8D9E36E74D5A4B

ICE request timed out.
 Local Address: ICE:; UDP: WiFi[
Remote Address: ICE:; UDP:
        Packet: Request Binding; Id: 3D243D50DE89AF81EE88B2C8

Connectivity check timed out.
  Local Address:
 Remote Address:
         Packet: Request Binding; Id: 3D243D50DE89AF81EE88B2C8

And then there's also this error which I believe maybe related to the missing STUN fingerprint error message I saw in the kamailio logs.

Ignoring received packet.
         Reason: Non-conforming user name.
  Local Address:
 Remote Address: 79.xx.xx.xx:11772
Received Packet: Request Binding; Id: 014FD6318B5AF06E6C45976D
  Received Data: 000100002112A442014FD6318B5AF06E6C45976D

In the Linphone logs:

Local candidates:
type=host ip= port=7076 componentID=1 priority=2130706431 foundation= base=0x69045d78
type=host ip= port=7077 componentID=2 priority=2130706430 foundation= base=0x68b62de0
type=srflx ip=85.xx.xx.xx port=7076 componentID=1 priority=1694498815 foundation= base=0x69045d78
type=srflx ip=85.xx.xx.xx port=7077 componentID=2 priority=1694498814 foundation= base=0x68b62de0

Remote candidates: (empty)

RtpSession [0x68b415a0] sending to rtp [79.xx.xx.xx:11792] rtcp [79.xx.xx.xx:11793]   This is the relay IP so the call's being relayed through the server instead of establishing a direct p2p connection between (linphone) and (groundwire) even though they're both in the same subnet.

And indeed the fact that media is being relayed through the server is confirmed in the call stats later on.

LocalAddr: IP=85.xx.xx.xx PORT=7076 SSRC=3085361497  (this is my server reflexive IP gathered through STUN)

RemoteAddr: IP=79.xx.xx.xx PORT=11792 SSRC=1352766754 (this is my server's IP)

So, in conclusion, it seems that there's something wrong with Linphone's ICE stack, or, at least, Linphone's implementation doesn't seem to be inter-operable with others.

Can someone from Linphone please confirm whether they have noticed similar problems with ICE? Has anyone gotten ICE to work with Linphone when calling other UACs (groundwire, CSipSimple, etc)?
Also, where can I confirm that Linphone supports RFC 5245 and RFC 5389?



On Thu, Oct 23, 2014 at 12:52 PM, Peter Villeneuve <address@hidden> wrote:

Using latest linphone for Android from the playstore I'm getting a lot of 1 way audio situations which is typical of NAT issues.

Looking further into the Kamailio proxy logs (v 4.2 stable with RTPengine module enabled), I see a bunch of STUN related errors coming from the Linphone UAC:

Not handling potential STUN packet from 89.xx.xx.xx:7076: FINGERPRINT attribute missing

This is likely the cause of the problems. Does Linphone's ICE stack not  have full support for RFC 5245 and RFC 5389, specifically the missing Fingerprint attribute which is causing major problems?


Linphone-developers mailing list

reply via email to

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