Example of forking a call using lateroute
Basic forking / lateroute example
[default] ^100$=fork lateroute/201 | lateroute/202 | sip/sip:\email@example.com
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
- 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.