[Spce-user] actual device that initiated BYE?

[Jon Bonilla (Manwe)]

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