[Spce-user] actual device that initiated BYE?

[Matthew Ogden]

Unfortunately this embedded asterisk overwrites the sip.conf everytime the
webgui "apply" is clicked, so if I set it, it will be overwritten.

What are the unexpected side affects of this? sems.sbc.session_timer.enable:
no
Does this affect our peers too?

So my best options would be to use the global timer (but know its side
affects).



-----Original Message-----
From: Jon Bonilla (Manwe) [mailto:jbonilla at sipwise.com]
Sent: 15 August 2012 08:05 AM
To: spce-user at lists.sipwise.com
Cc: Matthew Ogden
Subject: Re: [Spce-user] actual device that initiated BYE?

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

The issue was updated by me. Check this one:

https://issues.asterisk.org/jira/browse/ASTERISK-19942

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 negotiated it.

You can test it if you have the time whitelisting the Require header.
In /etc/ngcp-config/templates/etc/sems/etc/ngcp.sbcprofile.customtt.tt2

-header_list=P-D-Uri,P-Asserted-Identity,Privacy
+header_list=P-D-Uri,P-Asserted-Identity,Privacy,Required,Allow,Supporte
+d

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

The best solution here if you can talk to your customer, is to disable
session timers in the asterisk system

in sip.conf:

session-timers=refuse

Another solution is to disable session timers in the spce entirely. In
config.yml:

sems.sbc.session_timer.enable: no


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.


cheers,


Jon