asterisk users - Nov 2016 - Dropped call after 900s: 481 call/transaction does not exist and another anomaly during re-invite in timer - full anonymized trace attached

Hello all!

I can see a strange problem during invite in dialog in the context of
timer handling.

Given is the following incoming call from provider at 8.195.88.234 (2 at 2)
to my asterisk at 28.19.57.152 (1 at 1):

After 900s suddenly *asterisk* starts the timer reinvite - I would have
expected the reinvite started by the provider as usual.

The expected reinvite by the provider is started during authentication
of the reinvite started by asterisk and is answered immediately by
asterisk with sip 481.

The answer of the provider after the resend of the reinvite came about
0.5s later and is sip 481, too.

=> The session obviously isn't known on both sides!

Asterisk therefore now drops the call (bye).


Does anybody has any idea about the reason why both members don't
recognize the existing session any more? I hope the attached sip trace
can shed some light on the problem.


Thanks,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip481.pcap.gz
Type: application/x-gzip
Size: 2336 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20161130/f8a074e9/attachment.bin>

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces
at lists.digium.com] On Behalf Of Michael Maier
Sent: Wednesday, November 30, 2016 12:43 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Subject: [asterisk-users] Dropped call after 900s: 481 call/transaction does not
exist and another anomaly during re-invite in timer - full anonymized trace
attached

Hello all!

I can see a strange problem during invite in dialog in the context of timer
handling.

Given is the following incoming call from provider at 8.195.88.234 (2 at 2) to
my asterisk at 28.19.57.152 (1 at 1):

After 900s suddenly *asterisk* starts the timer reinvite - I would have expected
the reinvite started by the provider as usual.

The expected reinvite by the provider is started during authentication of the
reinvite started by asterisk and is answered immediately by asterisk with sip
481.

The answer of the provider after the resend of the reinvite came about 0.5s
later and is sip 481, too.

=> The session obviously isn't known on both sides!

Asterisk therefore now drops the call (bye).


Does anybody has any idea about the reason why both members don't recognize
the existing session any more? I hope the attached sip trace can shed some light
on the problem.


Thanks,
Michael


HI Michael,
You can set this in sip.conf:
session-timers=refuse

Derek Bolichowski wrote:
>
> HI Michael,
> You can set this in sip.conf:
> session-timers=refuse
I know of this option - it doesn't help, because the provider ignores it 
(on some calls) and the call is dropped anyway.

Normally, there is no problem with the timers. And the problem which 
occurred here is not just the timer, but the session which seams to be 
lost on both sides. But why?


Thanks,
Michael