Example of forking a call using lateroute
From Yate Documentation
(Difference between revisions)
(→Explanation) |
(→Routing to a different context with lateroute example) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | 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. | ||
| + | |||
| + | An alternative to forking using lateroute was introduced from Yate 3.3.3, fork with distributive parameters. But in some cases, when routing to more than one user registered in regfile or for reducing the complexity of the algorithm you should use forking with lateroute. | ||
| + | |||
| + | 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 example | ||
===Basic forking / lateroute example=== | ===Basic forking / lateroute example=== | ||
| Line 8: | Line 16: | ||
^100$=fork lateroute/201 | lateroute/202 | sip/sip:\0@my.gateway | ^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 example=== | |
| − | + | ||
| − | + | ||
| − | ===Routing to a different context with lateroute=== | + | |
Again, ''regexroute.conf'' will contain: | Again, ''regexroute.conf'' will contain: | ||
| Line 24: | Line 31: | ||
^1001$=return;called=123456 | ^1001$=return;called=123456 | ||
^1002$=return;called=654321 | ^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 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. | ||
| Line 45: | Line 50: | ||
* [[Call Forker]] | * [[Call Forker]] | ||
* [[Routing]] | * [[Routing]] | ||
| + | |||
| + | [[Category:Routing]] [[Category:Call fork]] [[Category:Lateroute]] | ||
Latest revision as of 16:03, 31 October 2013
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.
An alternative to forking using lateroute was introduced from Yate 3.3.3, fork with distributive parameters. But in some cases, when routing to more than one user registered in regfile or for reducing the complexity of the algorithm you should use forking with lateroute.
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 example
[edit] 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.
[edit] Routing to a different context with lateroute example
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
