View source for Example of forking a call using lateroute

Lateroute is used to make a late route decision in Yate's message flow and fork is used to route the call to multiple targets.

This helps you route the calls to one or several numbers whose addresses are unknown.

This are some examples of routing calls to multiple alternative targets using lateroute:
:1.Basic forking / lateroute example
:2.Routing to a different context with lateroute

===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

* 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.


'''See also'''

* [[Late routing Module]]
* [[Call Forker]]
* [[Routing]]