Re: [Linphone-developers] Linphone Android only makes STUN binding request on certain devices

[Shovon Datta Rony]

Hi all,

I having the same issue. In the same scenario works fine but only issue with the android version.

Please let me know if you have found the solution.

Thanks.

On Tue, May 14, 2019 at 12:28 AM Anthony <address@hidden> wrote:

Hello Linphone team,

I've been having issues with NAT traversal using the android Linphone app.  After doing some network capture, I have figured out that the Linphone application is only making STUN binding requests on 1 of my 3 devices.

I'm using the STUN server stun.linphone.org:3478 with ice enabled.  The Linphone version is 4.1 (4124).

On the app that is functioning properly, my STUN messages look like this:

48 2.933910382 10.181.0.4 37.59.51.72 STUN 64 Binding Request
49 2.933910382 10.181.0.4 37.59.51.72 STUN 64 Binding Request
50 2.933910382 10.181.0.4 37.59.51.72 STUN 64 Binding Request
51 2.933910382 10.181.0.4 37.59.51.72 STUN 64 Binding Request
52 2.939675922 37.59.51.72 10.181.0.4 STUN 128 Binding Success Response MAPPED-ADDRESS: {MY PUBLIC IP}:9078 XOR-MAPPED-ADDRESS: {MY PUBLIC IP}:9078
54 2.941472508 37.59.51.72 10.181.0.4 STUN 128 Binding Success Response MAPPED-ADDRESS: {MY PUBLIC IP}:7077 XOR-MAPPED-ADDRESS: {MY PUBLIC IP}:7077
56 2.997116502 37.59.51.72 10.181.0.4 STUN 128 Binding Success Response MAPPED-ADDRESS: {MY PUBLIC IP}:9079 XOR-MAPPED-ADDRESS: {MY PUBLIC IP}:9079
58 3.051588851 37.59.51.72 10.181.0.4 STUN 128 Binding Success Response MAPPED-ADDRESS: {MY PUBLIC IP}:7076 XOR-MAPPED-ADDRESS: {MY PUBLIC IP}:7076

and the SIP SDP looks like this:

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): 102 1646 715 IN IP4 10.42.0.232
    Session Name (s): Talk
    Connection Information (c): IN IP4 10.42.0.232
    Time Description, active time (t): 0 0
    Session Attribute (a): ice-pwd:e75b34b478df0e5b378da60f
    Session Attribute (a): ice-ufrag:0791373e
    Session Attribute (a): rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
    Media Description, name and address (m): audio 7076 RTP/AVP 96 97 98 0 8 18 101 99 100
    Connection Information (c): IN IP4 {MY PUBLIC IP}
    Media Attribute (a): rtpmap:96 opus/48000/2
    Media Attribute (a): fmtp:96 useinbandfec=1
    Media Attribute (a): rtpmap:97 speex/16000
    Media Attribute (a): fmtp:97 vbr=on
    Media Attribute (a): rtpmap:98 speex/8000
    Media Attribute (a): fmtp:98 vbr=on
    Media Attribute (a): fmtp:18 annexb=yes
    Media Attribute (a): rtpmap:101 telephone-event/48000
    Media Attribute (a): rtpmap:99 telephone-event/16000
    Media Attribute (a): rtpmap:100 telephone-event/8000
    Media Attribute (a): candidate:1 1 UDP 2130706303 10.42.0.232 7076 typ host
    Media Attribute (a): candidate:1 2 UDP 2130706302 10.42.0.232 7077 typ host
    Media Attribute (a): candidate:2 2 UDP 1694498686 {MY PUBLIC IP} 7077 typ srflx raddr 10.42.0.232 rport 7077
    Media Attribute (a): candidate:2 1 UDP 1694498687 {MY PUBLIC IP} 7076 typ srflx raddr 10.42.0.232 rport 7076
    Media Attribute (a): rtcp-fb:* ccm tmmbr
    Media Description, name and address (m): video 9078 RTP/AVP 96 97 98
    Connection Information (c): IN IP4 {MY PUBLIC IP}
    Media Attribute (a): rtpmap:96 VP8/90000
    Media Attribute (a): rtpmap:97 H264/90000
    Media Attribute (a): fmtp:97 profile-level-id=42801F
    Media Attribute (a): rtpmap:98 H265/90000
    Media Attribute (a): candidate:1 1 UDP 2130706303 10.42.0.232 9078 typ host
    Media Attribute (a): candidate:1 2 UDP 2130706302 10.42.0.232 9079 typ host
    Media Attribute (a): candidate:2 1 UDP 1694498687 {MY PUBLIC IP} 9078 typ srflx raddr 10.42.0.232 rport 9078
    Media Attribute (a): candidate:2 2 UDP 1694498686 {MY PUBLIC IP} 9079 typ srflx raddr 10.42.0.232 rport 9079
    Media Attribute (a): rtcp-fb:* ccm tmmbr
    Media Attribute (a): rtcp-fb:96 nack pli
    Media Attribute (a): rtcp-fb:96 nack sli
    Media Attribute (a): rtcp-fb:96 ack rpsi
    Media Attribute (a): rtcp-fb:96 ccm fir
    Media Attribute (a): rtcp-fb:97 nack pli
    Media Attribute (a): rtcp-fb:97 ccm fir
    Media Attribute (a): rtcp-fb:98 nack pli
    Media Attribute (a): rtcp-fb:98 ccm fir

The non-functioning app does not make STUN binding requests before sending or accepting an invite, and thus does not have the server reflexive addresses in the SDP.

Is this a bug?  I've checked the settings, and they seem to be identical.  The only other difference would be one caused by being on a different phone architecture/Firmware.

Any help on this matter would be greatly appreciated.

Thank you

_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers