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
_______________________________________________
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
