[Spce-user] SPCE terminate calls after few minutes ....

[Jonathan Scott]

On 8/17/2011 6:32 PM, Jonathan Scott wrote:
>
>>
>> Would be good to see what happens with the session timer invites in your
>> setup. Disabling session timers is not the best solution.
>>
>> You should investigate further and fix the asterisk implementation if 
>> it's
>> dropping the calls for that reason.
>>
>> Depending on the asterisk version you use the behaviour can change. 
>> Take a look
>> to this document which explains moreor less the configuration options of
>> asterisk for session timer usage:
>>
>>
>> http://goo.gl/kmCxh
>>
>> In asterisk trunk doxygen documentation you'll find also sample 
>> configuration
>> options
>>
>> https://www.asterisk.org/doxygen/trunk/Config_sip.html
>>
>>
> Sorry about the other e-mail Jon, I've been remoting in from home and 
> the machine tends to spaz out sometimes...
>
>
> I've resolved the session timer issue, and I'm sticking with sending 
> it via INVITE in sems config.
> The problem was the A leg of the call, being FreeSwitch, not 
> responding to the INVITE requests from ngcp's domain. Essentially a 
> bug in freeswitch, probably fixed in current SVN trunk.
>
OK... I thought this was resolved, until we deployed some ATA's that we 
hadn't used before... behavior was different, calls were not dropped, 
but after the timeout period the audio was one way only, resolved by 
disabling the session timer.

I have a question... the idea behind session timer is essentially to 
tear down calls that did not send the proper sip signalling... ie: a 
user's device lost power during a call.

Our NGCP server is peered with one of our FreeSwitch servers, that has a 
4 port PRI card and gets PSTN access via PRI's from our Class 5 Switch 
(CopperCom CSX)... ALL calls are routed to the Switch first for CDR 
collecting as well as local cnam lookups....
I decided to test a few calls, cut power to the ATA's and wait to see if 
the calls were torn down. Our FreeSwitch, or perhaps even the CopperCom 
itself is tearing these calls down after 5 minutes of the ATA's being 
unavailable...

My question, is this method appropriate enough to rely on? Or should I 
be more concerned with finding ways for all ATA's to play nice with 
updates/invites?

-- 
Jonathan Scott Knox
Systems Administrator
XATel Communication
7 Green Street, Biddeford ME. 04005
(207)391.1000 (Mon - Thur, 9AM - 6PM. Friday - 9AM - 5PM.)