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 ? - What about a CANCEL ?
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)
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 ?
loadmodule "htable.so" modparam("htable", "htable", "nexthop=>size=4;autoexpire=120;")
Aurelien
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
-
Aurelien Grimaud -
Daniel-Constantin Mierla