[Users] Detecting runaway calls

[Joachim Fabini]

Hi,

I'd also like to add my 2 cents to this topic, which
might be slightly off-topic on this mailing list.
Imho the problem discussed here is a major defficiency 
of the SIP protocol, which forces most vendors to 
implement proprietary extensions in their equipment. 
Call supervision is a feature that might not be 
important for best-effort services, but is of utmost
importance when deploying SIP within a commercial 
environment.

Have a look at, e.g. H.323. They do have several
redundant mechanisms to detect stale calls (e.g. 
at H.225 RAS level (IRQ/IRR/IACK/INAK), and at 
call signaling level (Status request/Status)). These 
messages offer detailed information on all ongoing
calls within a terminal/gateway - either on sending
an explicit request or by asking the endpoint to 
provide this information on a periodical base.
Beside this, RRQ/RCF also provides re-registration 
features similar to REGISTER timers in SIP.

Again imho the clean solution for SIP was to have 
an equivalent of these features defined in the 3261 core. 
It's too late for this now. What still can (and should) be 
done is an RFC that defines an extension to SIP which 
implements call supervision.

Concluding: It's obvious that _real_ call supervision 
that is capable to detect malicious, non-standard 
compliant terminals (which, e.g. signal voice but send 
video over the voice channel) requires some border 
gateways featuring RTP content sniffing. But this is 
imho no excuse for SIP not providing standardized 
means capable to supervise calls on standard-compliant
SIP devices.

regards
--Joachim


> -----Original Message-----
> From: users-bounces at openser.org 
> [mailto:users-bounces at openser.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Donnerstag, 27. Oktober 2005 21:02
> To: Daryl Sanders
> Cc: users at openser.org
> Subject: Re: [Serusers] Re: [Users] Detecting runaway calls
> 
> Daryl,
> 
> normally, a PSTN provider who offer quality service must 
> offer a way to detect hanged calls.
> There is also a detection mechanism based on media (on GW) - 
> at least CISCO GW have.
> 
> regards,
> bogdan
> 
> Daryl Sanders wrote:
> 
> >This is exactly what I am trying to overcome. Do third party PSTN 
> >providers typically employ any other means of monitoring a call? I 
> >would think the would automatically disconnect the call 
> after a certain 
> >amount of time if there was no media detected.
> >
> >On 10/27/05, Iqbal <iqbal at gigo.co.uk> wrote:
> >  
> >
> >>problem with session timers, is if you have several 
> different routes 
> >>and you dont control all the end gateways....then its a pain, so I 
> >>would think you would need a plan B, just in case to ensure 
> you double 
> >>checked, but agree with bogdan, b2bua i great but I think 
> the overhead 
> >>is not needed.
> >>
> >>Iqbal
> >>
> >>Bogdan-Andrei Iancu wrote:
> >>
> >>    
> >>
> >>>Hi Greg,
> >>>
> >>>that's the fortunate case of having already a B2BUA on the path :).
> >>>But only for this particular case, I find the usage of a B2BUA a 
> >>>little bit to  "heavy"....
> >>>
> >>>Session Timer is actually doing a great job ;)
> >>>
> >>>regards,
> >>>bogdan
> >>>
> >>>Greg Fausak wrote:
> >>>
> >>>      
> >>>
> >>>>The re-INVITEs definitely work.  I run some setups with Jasomi 
> >>>>inline (a commercial inline b2bua).  I configure them to 
> reINVITE, 
> >>>>works like a charm.  If the reINVITE isn't answered (in either
> >>>>direction) the Jasomi sends BYEs in both directions.  I believe 
> >>>>other commercial gear works that way.
> >>>>
> >>>>Also, I believe Session-Timers are supported by Cisco 
> gateways, but 
> >>>>I don't have experience with those.
> >>>>
> >>>>-g
> >>>>
> >>>>
> >>>>On 10/27/05, Daryl Sanders <daryl.sanders at gmail.com> wrote:
> >>>>
> >>>>
> >>>>        
> >>>>
> >>>>>Thanks for the info guys! It sounds like I need to do a little 
> >>>>>reading up on cseq to determine if this will even work, 
> or find a 
> >>>>>PSTN gateway provider that supports Session-Timers.
> >>>>>
> >>>>>- Daryl
> >>>>>
> >>>>>On 10/27/05, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>by sending re-INVITEs from the middle of the path you will 
> >>>>>>increase the cseq number differently on each side...so you will 
> >>>>>>need to synchronize the cseq value when some in-the-dialog 
> >>>>>>requests are passing through your proxy....and that's quite 
> >>>>>>complicated....
> >>>>>>
> >>>>>>regards,
> >>>>>>bogdan
> >>>>>>
> >>>>>>Daryl Sanders wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>Would it be possible to fake a REINVITE then check the 
> response 
> >>>>>>>to determine if a call is still in session? Just 
> brainstorming...
> >>>>>>>
> >>>>>>>- Daryl
> >>>>>>>              
> >>>>>>>
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>