[Spce-user] actual device that initiated BYE?

Matthew Ogden matthew at tenacit.net
Tue Aug 14 18:11:17 EDT 2012

Hi Jon,

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

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?

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

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
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

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

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


Spce-user mailing list
Spce-user at lists.sipwise.com

More information about the Spce-user mailing list