[Kamailio-Users] [Kamailio-Devel] serial forking : is hash table autoexpire working ?

[Daniel-Constantin Mierla]

Hello,

On 12/15/08 11:24, Aurelien Grimaud wrote:
> Hi,
>
> I am using openser to route requests towards differents Interactive 
> Voice Response (IVR).
> For this, and to manage failures, maintenance a flexible way, I use 
> serial forking.
>
> For each requests (after loose routing process), all possible 
> destinations are retrieved from 'location' with a modified lookup.
> The first one is pushed to DURI, the other ones are stored in AVP.
> An on_failure_route is set to get next destination if any.
> fr_timer is 5 secs
> fr_inv_timer is 120 secs.
> Therefore, if an IVR does not response at all within 5 secs, the serial 
> forking mechanism is triggered.
>
> Any subsequent message *MUST* go to same IVR, this is the 
> record_route/loose_route processing, and everything is ok for ACK or BYE.
>
> My problem is for requests that does not match loose_routing.
> - What about the initial INVITE being retransmitted ?
>   
this is absorbed by TM.

> - What about a CANCEL ?
>   
TM modules will route the CANCEL to same destination where the INVITE 
was sent to.

> In those cases, the request goes to another IVR which handles it genuinely.
> For INVITE retransmission, the calling uac will get two different 
> answers. If lucky, one will be canceled.
> For CANCEL, the message will be rejected by all destinations but the one 
> which expects it (if lucky).
>
> To avoid this, I used dynamic avp to set nexthop for a specific callid, 
> as soon as nexthop was chosen.
> These avp were stored in database and reloaded from ...
> This is really slowing down the system for a little annoyance ...
>
> With kamailio 1.5.0 I use new module hash table to store next hop.
> nexthop is cleaned on BYE, CANCEL and failures.
>
> To handle runaway calls, the autoexpire parameter of hash table is a 
> great thing. Unfortunately It does not seem to do the job.
> All entries stays indefinitely in table (as shown in sht_print)
>   
That feature is not implemented yet. Should be there by 1.5.0.

> Do you think these serial forking issues (re-INVITE, CANCEL) and all the 
> work around (nexthop hash table) it need is useful ?
> Anyone want to share its serial forking management ?
> What about the autoexpire parameter for hash table ?
> Is it ok or did I miss something ?
>   
Serial forking should be implemented with AVPs, because they are bound 
to SIP messages. You keep the destination set in avps attached to invite 
and consume one by one.

Have a look at lcr or carrierroute modules, maybe you can use them to do 
what you need.

Cheers,
Daniel

> loadmodule "htable.so"
> modparam("htable", "htable", "nexthop=>size=4;autoexpire=120;")
>
> Aurelien
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com