Call drops after 32 seconds

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Call drops after 32 seconds

Thomaier, Simon
_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users

smime.p7m (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Christopher Woods
No diagnostic info or description of your testing? 

Regards
Chris


On Tue, 18 Jun 2019, 08:46 Thomaier, Simon, <[hidden email]> wrote:
_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users

_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Thomaier, Simon

Hello all,

sorry, the mail was signed with a certificate, maybe thats why.

Here the original text:
Hello all,

my setup is the Linphone App on Nokia 7.1 connecting to an Asterisk SIP Server.

Incoming calls get dropped after 32 seconds each time.
Outgoing calls work just fine.

Some researched showed it could be the 200 ACK packet that is not received.

I´m monitored all packages on the firewall, I see 200 ACK from Linphone to the Asterisk but not from Asterisk to Linphone.
After 32 seconds I get a TCP Retransmission from Asterisk to Linphone followed by a BYE  

As a Firewall we use Sonicwall. so I tried to turn off the SIP Transformation (SIP ALG) but it didn´t help unfortunately. Consistend NAT is enabled.

Do you guys have any hint to where to look further into? Running out of ideas (google results)
L

Thank you very much in advance.


Kind regards,
Simon

 

 

 

Von: Linphone-users <linphone-users-bounces+sthomaier=[hidden email]> Im Auftrag von Chris Woods
Gesendet: Dienstag, 18. Juni 2019 11:49
An: [hidden email]
Betreff: Re: [Linphone-users] Call drops after 32 seconds

 

No diagnostic info or description of your testing? 

 

Regards

Chris

 

On Tue, 18 Jun 2019, 08:46 Thomaier, Simon, <[hidden email]> wrote:

_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users


_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Robert Dixon
This 30 second timeout problem has plagued Linphone users for years, and it has been brought up on many lists, with no real solution.
I was able to partially solve it on a local network by eliminating the use of TCP in the Network options. Just use
UDP. 
I was ecstatic.  Then I went to use it on a larger network, and it failed again in the same way. I do not understand this.

Bob

On Jun 18, 2019, at 7:18 AM, Thomaier, Simon <[hidden email]> wrote:

Hello all,

sorry, the mail was signed with a certificate, maybe thats why.

Here the original text:
Hello all,

my setup is the Linphone App on Nokia 7.1 connecting to an Asterisk SIP Server.

Incoming calls get dropped after 32 seconds each time.
Outgoing calls work just fine.

Some researched showed it could be the 200 ACK packet that is not received.

I´m monitored all packages on the firewall, I see 200 ACK from Linphone to the Asterisk but not from Asterisk to Linphone.
After 32 seconds I get a TCP Retransmission from Asterisk to Linphone followed by a BYE  

As a Firewall we use Sonicwall. so I tried to turn off the SIP Transformation (SIP ALG) but it didn´t help unfortunately. Consistend NAT is enabled.

Do you guys have any hint to where to look further into? Running out of ideas (google results) 
L

Thank you very much in advance.

Kind regards,
Simon
 
 
 
Von: Linphone-users <[hidden email]> Im Auftrag von Chris Woods
Gesendet: Dienstag, 18. Juni 2019 11:49
An: [hidden email]
Betreff: Re: [Linphone-users] Call drops after 32 seconds
 
No diagnostic info or description of your testing? 
 
Regards
Chris

 

On Tue, 18 Jun 2019, 08:46 Thomaier, Simon, <[hidden email]> wrote:
_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users


_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Stuart D. Gathman
On Tue, 18 Jun 2019, Robert Dixon wrote:

> This 30 second timeout problem has plagued Linphone users for years, and it
> has been brought up on many lists, with no real solution.I was able to
> partially solve it on a local network by eliminating the use of TCP in the
> Network options. Just use
> UDP. 
> I was ecstatic.  Then I went to use it on a larger network, and it failed
> again in the same way. I do not understand this.

The issue is that the 200 ACK response is sent to the wrong ip.
Because linphone tells the peer (asterisk in this case) the wrong ip
in the SIP header.  The SIP library does not trust what you tell it in
the config, and silently tries to second guess you when making a
connection.  It will randomly choose some public IP on an
active interface to put in the SIP header for the peer to use.  It
may or may not be actually routable...

In my case, I am using IPv6 on a private VPN network, and the SIP library
"knows" that I *must* be mistaken when I configure the private IP, and
chooses an arbitrary public IP instead.  Even when this works, it
defeats the whole point of the VPN, and it usually doesn't work
because the peer has no public IP6 - only the IP6 VPN.
For me, the work around is to disable IP6 on all public interfaces,
leaving only the VPN interface during the call.  (On linux, this
is "echo 1 >/proc/sys/net/ipv6/conf/ethx/disable_ipv6".)  This
prevents the SIP library from finding any (bogus for this purpose)
public IPs to use instead of what I told it.  This is *highly*
inconvenient (all public IP6 traffic is stopped during the call),
but a reliable work around.

The good part, is that I learned a little about SIP protocol tracing
the calls.

I just had a thought.  Are you using raw IPs?  Maybe the SIP library
doesn't do this silly thing with DNS names.

--
       Stuart D. Gathman <[hidden email]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Robert Dixon
I am using addresses of the form:

<a href="sip:username@(ipaddress):5060" class="">sip:username@(ipaddress):5060

I have IPV6 turned off.

Bob

On Jun 18, 2019, at 9:46 AM, Stuart D. Gathman <[hidden email]> wrote:

On Tue, 18 Jun 2019, Robert Dixon wrote:

This 30 second timeout problem has plagued Linphone users for years, and it
has been brought up on many lists, with no real solution.I was able to
partially solve it on a local network by eliminating the use of TCP in the
Network options. Just use
UDP. 
I was ecstatic.  Then I went to use it on a larger network, and it failed
again in the same way. I do not understand this.

The issue is that the 200 ACK response is sent to the wrong ip.
Because linphone tells the peer (asterisk in this case) the wrong ip
in the SIP header.  The SIP library does not trust what you tell it in
the config, and silently tries to second guess you when making a
connection.  It will randomly choose some public IP on an
active interface to put in the SIP header for the peer to use.  It
may or may not be actually routable...

In my case, I am using IPv6 on a private VPN network, and the SIP library
"knows" that I *must* be mistaken when I configure the private IP, and
chooses an arbitrary public IP instead.  Even when this works, it
defeats the whole point of the VPN, and it usually doesn't work because the peer has no public IP6 - only the IP6 VPN.
For me, the work around is to disable IP6 on all public interfaces, leaving only the VPN interface during the call.  (On linux, this
is "echo 1 >/proc/sys/net/ipv6/conf/ethx/disable_ipv6".)  This
prevents the SIP library from finding any (bogus for this purpose)
public IPs to use instead of what I told it.  This is *highly*
inconvenient (all public IP6 traffic is stopped during the call),
but a reliable work around.

The good part, is that I learned a little about SIP protocol tracing
the calls.

I just had a thought.  Are you using raw IPs?  Maybe the SIP library
doesn't do this silly thing with DNS names.

--
     Stuart D. Gathman <[hidden email]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial._______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users


_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Stuart D. Gathman
In reply to this post by Stuart D. Gathman
On Tue, 18 Jun 2019, Stuart D. Gathman wrote:

> On Tue, 18 Jun 2019, Robert Dixon wrote:
>
>> This 30 second timeout problem has plagued Linphone users for years, and it
>> has been brought up on many lists, with no real solution.I was able to
>> partially solve it on a local network by eliminating the use of TCP in the
>> Network options. Just use
>> UDP. 
>> I was ecstatic.  Then I went to use it on a larger network, and it failed
>> again in the same way. I do not understand this.
>
> The issue is that the 200 ACK response is sent to the wrong ip.
Well for me.  In all cases, the 200 ACK doesn't get back one way or
another.  I might be because a NAT router times out the connection,
or many other ways the peer might have the right IP - but the ACK
response isn't routed or gets blocked.

--
       Stuart D. Gathman <[hidden email]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Robert Dixon
So is the problem with Linphone?  How can this be fixed?
(using the dial string I mentioned previously).

> On Jun 18, 2019, at 11:53 AM, Stuart D. Gathman <[hidden email]> wrote:
>
> On Tue, 18 Jun 2019, Stuart D. Gathman wrote:
>
>> On Tue, 18 Jun 2019, Robert Dixon wrote:
>>
>>> This 30 second timeout problem has plagued Linphone users for years, and it
>>> has been brought up on many lists, with no real solution.I was able to
>>> partially solve it on a local network by eliminating the use of TCP in the
>>> Network options. Just use
>>> UDP.
>>> I was ecstatic.  Then I went to use it on a larger network, and it failed
>>> again in the same way. I do not understand this.
>>
>> The issue is that the 200 ACK response is sent to the wrong ip.
>
> Well for me.  In all cases, the 200 ACK doesn't get back one way or
> another.  I might be because a NAT router times out the connection, or many other ways the peer might have the right IP - but the ACK
> response isn't routed or gets blocked.
>
> --
>      Stuart D. Gathman <[hidden email]>
> "Confutatis maledictis, flamis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial._______________________________________________
> Linphone-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/linphone-users


_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Stuart D. Gathman
In reply to this post by Robert Dixon
On Tue, 18 Jun 2019, Robert Dixon wrote:

> I am using addresses of the form:
> sip:username@(ipaddress):5060
>
> I have IPV6 turned off.

IPv6 or IPv4 is not relevant.  The issue is private IPs, regardless of
IP version.  Usually, your IPv4 is always private, and linphone uses
stun or something to discover the public IPv4.  When you want to
call other peers on your IPv4 VPN with private IPv4 IPs - there is a similar
problem.

You are supposed to use "Behind NAT / specify gateway IP" to tell
linphone what IP to advertise.  But when you put a private IP there - it
doesn't believe you.  :-)

This problem is not with linphone itself - it stopped working the
beginning of this year on Fedora with some underlying library change.
Linphone was still at the same version.

--
       Stuart D. Gathman <[hidden email]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users
Reply | Threaded
Open this post in threaded view
|

Re: Call drops after 32 seconds

Stuart D. Gathman
In reply to this post by Robert Dixon
On Tue, 18 Jun 2019, Robert Dixon wrote:

> So is the problem with Linphone?

We don't know yet.  Suspects are linphone proper, system libraries,
firewall, router, remote peer router, firewall, application.

If using a centralized broker (like sip.linphone.org or commercial SIP
service), then repeat for that.

> How can this be fixed? (using the dial string I mentioned previously).

Well, the first step is to capture the CALL REQUEST and see what IP
is actually advertised.  Wireshark will break down the packet for you.

I don't remember your dial string, if it is a phone number, then your
peer is the SIP<>POTS service.  Usually, that kind of service works
fine when you use STUN or supply the correct gateway IP.  Can you report
which NAT and Firewall option you are using?

--
       Stuart D. Gathman <[hidden email]>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
Linphone-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/linphone-users