asterisk users - Nov 2019 - Disable NO_USER_RESPONSE (Hangupcause = 18) for certain SIP peer

What would be the best way to solve this problem? Anyone else that have got the
same problem with Android’s native SIP client, especially on Samsung phones?

 

I do not know if the bug is in Android native SIP, or Samsung’s build of the SIP
client, or if the bug is even with the OpenVPN client, or where the bug actually
is.

The ACK might even be sent for real, but have the incorrect source IP so
asterisk ignores it.

 

Since audio works in both directions, it seems that the lack of ACK wouldn’t
hurt (other than asterisk forcefully disconnecting the call) so I need to just
tell Asterisk to not forcefully disconnect the callee.

 

Från: asterisk-users <asterisk-users-bounces at lists.digium.com> För
Joshua C. Colp
Skickat: den 17 november 2019 00:54
Till: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Ämne: Re: [asterisk-users] Disable NO_USER_RESPONSE (Hangupcause = 18) for
certain SIP peer

 

On Sat, Nov 16, 2019 at 7:45 PM Sebastian Nielsen <sebastian at sebbe.eu
<mailto:sebastian at sebbe.eu> > wrote:

Hello.

I have a problem with the native Android SIP client, not acknowledging the call.

 

Sent a message to the list for some weeks ago containing a sip debug log, but it
only got stuck in moderation queue due to too large size (and it said I would
get a message if moderators rejected it, but did not get message and I don’t
think it got posted to list either)

 

This ONLY happens when calling outgoing from the Android SIP client. Incoming
calls works flawlessly.

 

Everything works, audio in both directions, but the call is dropped after 30
sec.

I have debugged it very much, and it seems that either Android is sending the
acknowledge of the call to the incorrect IP (perhaps to the 3G network instead
of via the VPN), or not sending it at all.

 

BUT – Everything else is working flawlessly, including audio in both directions.

 

So this means, I need somehow to tell Asterisk to ignore the lack of
acknowledgement.

 

 

 

So now to the question, since the call is dropped automatically after 30 sec
with ”NO_USER_RESPONSE” (Hangupcause 18) on the far end (the callee’s end),
propably because the Android native Client is not acknowledging the connected
call , is it possible to tell Asterisk to just ignore the lack of
acknowledgement from Android somehow?

 

Basically, for Client sip09 (username), never hang up for the reason 18
(NO_USER_RESPONSE), threat like user response was received always.

 

There is no ability to ignore the lack of an ACK, as that violates the SIP
standard itself.

 

-- 

Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.sangoma.com <http://www.sangoma.com/>  &
www.asterisk.org <http://www.asterisk.org/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191117/13bb0248/attachment.html>

On Sat, Nov 16, 2019 at 7:59 PM Sebastian Nielsen <sebastian at sebbe.eu>
wrote:
> What would be the best way to solve this problem? Anyone else that have
> got the same problem with Android’s native SIP client, especially on
> Samsung phones?
>
>
>
> I do not know if the bug is in Android native SIP, or Samsung’s build of
> the SIP client, or if the bug is even with the OpenVPN client, or where the
> bug actually is.
>
> The ACK might even be sent for real, but have the incorrect source IP so
> asterisk ignores it.
>
The ACK is sent to the Contact header of the 200 OK sent to the phone.
Using the respective logging (sip set debug on or pjsip set logger on)
would tell you the IP address and port that Asterisk is telling the phone
to send to, and isolate the problem further. Asterisk also doesn't ignore
the ACK based on source IP address. If it shows up at Asterisk, it'll get
processed.

>
>
> Since audio works in both directions, it seems that the lack of ACK
> wouldn’t hurt (other than asterisk forcefully disconnecting the call) so I
> need to just tell Asterisk to not forcefully disconnect the callee.
>
Without modifying code there's no way. The 200 OK retransmits until it
gives up, and the call is disconnected.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.sangoma.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191116/ec758891/attachment.html>

FINALLY solved it… Googled around for the problem, and found this:

https://support.yeastar.com/hc/en-us/articles/360020908914-Call-Hangs-up-at-30-Seconds

 

Apparently, sendrpid=yes causes Android Native SIP client not to respond to the
packets, and this drops the call after 30 seconds.

 

Disabling sendrpid makes it work successfully.

 

 

Från: asterisk-users <asterisk-users-bounces at lists.digium.com> För
Joshua C. Colp
Skickat: den 17 november 2019 01:18
Till: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Ämne: Re: [asterisk-users] Disable NO_USER_RESPONSE (Hangupcause = 18) for
certain SIP peer

 

On Sat, Nov 16, 2019 at 7:59 PM Sebastian Nielsen <sebastian at sebbe.eu
<mailto:sebastian at sebbe.eu> > wrote:

What would be the best way to solve this problem? Anyone else that have got the
same problem with Android’s native SIP client, especially on Samsung phones?

 

I do not know if the bug is in Android native SIP, or Samsung’s build of the SIP
client, or if the bug is even with the OpenVPN client, or where the bug actually
is.

The ACK might even be sent for real, but have the incorrect source IP so
asterisk ignores it.

 

The ACK is sent to the Contact header of the 200 OK sent to the phone. Using the
respective logging (sip set debug on or pjsip set logger on) would tell you the
IP address and port that Asterisk is telling the phone to send to, and isolate
the problem further. Asterisk also doesn't ignore the ACK based on source IP
address. If it shows up at Asterisk, it'll get processed.

 

 

Since audio works in both directions, it seems that the lack of ACK wouldn’t
hurt (other than asterisk forcefully disconnecting the call) so I need to just
tell Asterisk to not forcefully disconnect the callee.

 

Without modifying code there's no way. The 200 OK retransmits until it gives
up, and the call is disconnected.

 

-- 

Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.sangoma.com <http://www.sangoma.com/>  &
www.asterisk.org <http://www.asterisk.org/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191117/175803c9/attachment.html>