[asterisk-dev] SIP session-timers: concept, discussion

[Grey Man]

> ---- Original Message ----

> From: John Todd <jtodd at loligo.com>

> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>

> Sent: Wednesday, 18 July, 2007 6:52:36 AM

> Subject: Re: [asterisk-dev] SIP session-timers: concept, discussion


>
> Any implementation of Session Timers into Asterisk, alas, will not 

> cure your problems according to the limited data you've provided.  It 

> sounds like the calls are being "answered" at the far end, and then 

> audio continues to flow between the endpoints (since you're already 

> using rtptimeout, I assume you're handling media.)


>
> I  expect your international carriers are not providing adequate 

> answer supervision or disconnect supervision.  This can't be solved 

> by any code in Asterisk - it requires clubbing your carriers with a 

> threat of moving to a better network.


>
> The Session Timers will resolve other, more subtle problems, like a 

> carrier network or a SIP UA that has lost it's mind or has lost it's 

> network.  We already keep state in Asterisk - this just forces the 

> state to be refreshed, and if that fails, hang up.  It won't cure 

> problems with calls that "look" normal, at least as far as Asterisk 

> can see.




Hi John,

I understand what you are syaing and the truth is I don't know why we get calls that don't hangup on our Asterisk servers. I only ever find up afterwards when a customer complains about being over charged so it's not something that can be easily diagnosed. The porblem has been occurring for the whole time I've been operating Asterisk over the last 3 years and across various versions. It's not a huge deal as at one or two calls a month it's an annoyance rather than a big issue.

I do have the media going through my servers but I don't believe that mechanism is foolproof hence the enthusiasm with the SIP session timers approach, conceptually it sounds a lot more robust. I actually put a time limit of 3 hours on all calls in order to catch instances where the rtptimeout does not hangup the call. I suspect in some cases the user is accidentally putting the calls on hold by pressing the on-hook button as a lot of queries come from simultaneous calls to the same destination. It could be that the UA is putting a call on hold re-dialing and then for whatever reason forgetting about the original call. The user then hangs up and one or both calls don't get BYEs. In theory there should be no RTP from the UA and the rtponholdtimeout should kick in but in some cases it's not. The SIP session timers would be a good belts and braces approach. If the UA has been hung up then it should generate an error response to the UPDATE or reINVITE and then Asterisk can
 hangup the call irrespective of any RTP timers.

As for international carriers since a lot of the calls we get disputed are to out of the way places where the telecoms infrastructure may not be the best I suspect that either the signalling is getting screwed up so calls do not get hungup from the callee end or the carrier may choose not to hangup incoming calls from their own end in order to maximise revenue. The latter opinion being more of a a conspiracy than scientific theory.

Irrespective I do have a problem with calls not getting hungup as reliably as I believe they should be and at the very least the SIP session timers can only improve that situation not make it worse.

Regards,

Greyman.








      ____________________________________________________________________________________ Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html