linphone-developers
[Top][All Lists]
Advanced

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

Re: [Linphone-developers] Linphone-developers Digest, Vol 195, Issue 9


From: Anthony
Subject: Re: [Linphone-developers] Linphone-developers Digest, Vol 195, Issue 9
Date: Tue, 21 May 2019 11:21:04 -0500

I haven't updated my resume in a while.  You can see my employment/education history at 
linkedin.com/in/anthony-angrimson
I'm modifiying the linphone app for our purposes at Viking.

On Mon, May 13, 2019 at 8:34 PM <address@hidden> wrote:
Send Linphone-developers mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/linphone-developers
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linphone-developers digest..."


Today's Topics:

   1. Linphone Android only makes STUN binding request on certain
      devices (Anthony)
   2. Re: Linphone Android only makes STUN binding request on
      certain devices (Shovon Datta Rony)


----------------------------------------------------------------------

Message: 1
Date: Mon, 13 May 2019 11:27:15 -0500
From: Anthony <address@hidden>
To: address@hidden
Subject: [Linphone-developers] Linphone Android only makes STUN
        binding request on certain devices
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/linphone-developers/attachments/20190513/f76261bb/attachment.html>

------------------------------

Message: 2
Date: Tue, 14 May 2019 09:31:58 +0800
From: Shovon Datta Rony <address@hidden>
To: address@hidden
Subject: Re: [Linphone-developers] Linphone Android only makes STUN
        binding request on certain devices
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/linphone-developers/attachments/20190514/0c6916cb/attachment.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of Linphone-developers Digest, Vol 195, Issue 9
***************************************************

reply via email to

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