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