[Spce-user] actual device that initiated BYE?
Jon Bonilla (Manwe)
jbonilla at sipwise.com
Wed Aug 15 02:05:26 EDT 2012
El Wed, 15 Aug 2012 00:11:17 +0200
Matthew Ogden <matthew at tenacit.net> escribió:
> 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?
The issue was updated by me. Check this one:
I only got feedback from oej about missing headers that sems is filtering and I
need to test that but I don't think that's the problem. I will test when I have
the time. The truth is that asterisk does not honour the refresher once it has
You can test it if you have the time whitelisting the Require header.
I don't think here's the solution. But who knows.
> 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
The best solution here if you can talk to your customer, is to disable session
timers in the asterisk system
Another solution is to disable session timers in the spce entirely. In
The third solution is to wait until spce 2.6 (to be released 31st Aug) where
you'll be able to disable session-timers per subscriber.
More information about the Spce-user