Example of forking a call using lateroute

Revision as of 17:32, 6 December 2012

Basic forking / lateroute example

regexroute.conf holds:

[default]
^100$=fork lateroute/201 | lateroute/202 | sip/sip:\0@my.gateway

The call will first attempt to reach the 201 number through whatever routing possible - usually some form of registration. Then it will repeat for number 202 and only finally it will be directed to 100 at the gateway. Exact route and parameters for 201 and 202 don't have to be known in advance

Routing to a different context with lateroute

Again, regexroute.conf will contain:

[context-one]
^157$=;context=context-two
^157$=fork lateroute/1001 lateroute/1002

[context-two]
^1001$=return;called=123456
^1002$=return;called=654321

Explanation

• In our example, the call to number 157 ends up in the context-one - maybe through a previous jump out of a different context. context-one could also be default instead - it does not matter.
• In the first rule, the parameter context is set to context-two.
  • Please note, that this does NOT change the current context in regexroute - the call will continue to be routed in context-one
• In the second rule, we create a fork (= two or more call legs from one call leg), both via lateroute
  • it is not mandatory to have lateroute for both of them (see example above)
  • also, you could try numbers one by one with timeouts, ... see the Call Forker documentation
• both lateroute call legs inherit the parameters from the initial call leg, including our modified context
• each lateroute starts the routing process at the very beginning - coming to routing via regexroute.conf at some point
  • as there already is a context (context-two) in the route message, regexroute automatically goes to that context, skipping pre-routing.
• The calls end up being routed in context-two in regexroute, independent of each other
  • in my example the call routing control is returned from regexroute, for example to be routed via the register module / the database or other modules.