[Spce-user] actual device that initiated BYE?

[Matthew Ogden]

Hi Jon,

The Customer side is asterisk based - embedded linux- its a Yeastar MyPBX -
:S

The Customer side invite contains:
Supported: replaces, timer

SPCE replies once the call connects with
Supported: timer
Session-Expires: 300;refresher=uas

2.5 minutes (150 seconds) into the conversation, the SPCE sends the customer
a second invite, with
Supported: timer
Session-Expires: 300

5 minutes later after that, the call is cut by SPCE.

Let me know what other information you might require. After your reply I did
some reading, and understand the SPCE used 'uas' to make itself responsible
for the refresh, which it send after 2.5 minutes (perhaps this is a good
thing do to long before the expire time, but it later, should the SPCE have
sent another refresh, but after 5 minutes it sends the BYE?

I then read this, believe this might be the issue then?
https://issues.asterisk.org/view.php?id=18127

I am gawking at the workaround, and it might be better for SIP switches to
ignore the oversight of Asterisk? (Not allow timer role reversal once
established)

Kind Regards



-----Original Message-----
From: spce-user-bounces at lists.sipwise.com
[mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of Jon Bonilla
(Manwe)
Sent: 14 August 2012 09:11 PM
To: spce-user at lists.sipwise.com
Subject: Re: [Spce-user] actual device that initiated BYE?

El Tue, 14 Aug 2012 20:19:12 +0200
Matthew Ogden <matthew at tenacit.net> escribió:

> Hi Guys,
>
>
>
> I hope these graphics show adequately, and that I’ve given all
> releveant information.
>
>
>
> Attached is my kamialio proxy and lb log for the call.
>
>
>
> The graphics are from wireshark analysis of the call
>
>
>
> What I can’t figure out is, it seems like SPCE (from the wireshark
> output) was the reason the call was terminated.
>
>
>
> This customer experienced this several times today, and I can’t
> understand why it would appear SPCE would be the terminator of the
> call, and not the peer or CPE side?
>
>
>
> Perhaps you can point me to something I am missing?
>
>

I see that the BYE is sent exactly 5 minutes after the call has been
stablished.

Acording to the logs, sems (the b2bua) sends the BYE.

I'm not 100% sure without all the logs and the traces but I will guess what
happened:

The call was stablished and in the session timer negotiation the client (not
sure if caller or callee but I'd say caller) is responsible of session timer
refresh. 5 minutes after (300 seconds in the negotiation) sems has not
received any UPDATE or REINVITE for refreshing the session timer and
declares the client as dead and sends the BYE


I'd ask you even more: Is the caller or the callee an Asterisk server? We
have detected serious session timer problems with Asterisk lately. It has
been reported to Digium but we had no response so far.

You can try different setups depending on the failing device. You can
disable session timers in the SPCE (not recommended), or in the user device
if possible (if it's a broken implementation).

Enabling and disabling session timers per subscriber is available in version
2.6. For now, it's global and you have to change it in config.yml


please, let me know

Jon


_______________________________________________
Spce-user mailing list
Spce-user at lists.sipwise.com
http://lists.sipwise.com/listinfo/spce-user