[SR-Users] How to deal with diversion loops.

Uri Shacked ushacked at gmail.com
Mon Feb 20 20:41:30 CET 2012


Hi,
the maxfwd will not help me prevent the loop on the first round, it would
only stop it a little sooner the X times. no?
the dlg_var is interesting, but i didn't understand how to use it exactly.
how do i match two dialogs? is the spiral detection on dialog module helps?
thanks,
Uri

>Hi Uri,
>for that you can easily count the forwards by using the maxfwd module
>(mf_process_maxfwd_deader <your max>) or you can store all your spiraled
>calls into a dialog-variable like
>$dlg_var(forward-chain)=<B>;<C>|<C>;<B> and check whether the next
>number is already stored or not.


Bye Sven


Am 20.02.2012 13:20, schrieb Uri Shacked:
>*
*>* Hi,
*>*
*>* The service i built in kamailio is simple - a caller dials an Access
*>* number, my gateway send it to kamailio.
*>*
*>* kamailio finds the shadow number for this Access number and send an
*>* invite to the same gateway with the shadow number as destination
*>* (state full proxy).
*>*
*>* In kamailio i change only the RURI and the “To” and “From” stays
*>* untouched.
*>*
*>* Now, when a client performs “diversion”, I can see that I can find
*>* myself in an unwanted long loop….
*>*
*>* Example :
*>*
*>* A calls B
*>*
*>* B diverted the call unconditionally to C.
*>*
*>* C is an Access Number that its shadow number is D.
*>*
*>* D diverted the call to B…….
*>*
*>* Well, that is a bad loop to have!
*>*
*>* It can be longer or shorter, but the idea I understood (I think).
*>*
*>* I thought about diversion check, counters, dialog “To” and “From”
*>* check, etc….
*>*
*>* Anyone here dealt with it?
*>*
*>* What will be the best way to check and see if the situation accrues?
*>*
*>* Thanks,
*>*
*>* Uri
*>*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120220/4b6f7142/attachment.htm>


More information about the sr-users mailing list