Resources.DocsCoreRoutes History

Hide minor edits - Show changes to output

April 24, 2013, at 10:27 PM by 92.80.24.181 -
Changed lines 1-301 from:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsCookbooks | CookBooks]] -> Routing Blocks
----
(:toc-float Table of Content:)

This Documentation is for '''OpenSIPS 1.10.x/devel'''

'''OpenSIPS''' routing logic uses several types of routes. Each type of route is triggered by a certain event and allows you to process a certain type of message (request or reply).


-----
!!!!route

Request routing block. It contains a set of actions to be taken for SIP requests.

'''Triggered by''' : receiving an external request from the network.

'''Processing''' : the triggering SIP request.

'''Type''' : initially stateless, may be forced to stateful by using TM functions.

'''Default action''' : if the request is not either forwarded nor replied, the route will simply discard the request at the end.

The main 'route' block identified by 'route{...}' or 'route[0]{...}' is executed for each SIP request.

The implicit action after execution of the main route block is to drop the SIP request. To send a reply or forward the request, explicit actions must be called inside the route block.

Example of usage:
[@
route {
if(is_method("OPTIONS")) {
# send reply for each options request
sl_send_reply("200", "ok");
exit();
}
route(1);
}
route[1] {
# forward according to uri
forward();
}
@]

Note that if a 'route(X)' is called from a 'branch_route[Y]' then in 'route[X]' is just processed each separate branch instead of all branches together as occurs in main route.


----
!!!!branch_route

Request's branch routing block. It contains a set of actions to be taken for each branch of a SIP request.

'''Triggered by''' : preparation a new branch (of a request); the branch is well formed, but not yet sent out.

'''Processing''' : the SIP request (with the branch particularities, like RURI, branch flags)

'''Type''' : stateful

'''Default action''' : if the branch is not dropped (via "drop" statement), the branch will be automatically sent out.

It is executed only by TM module after it was armed via t_on_branch("branch_route_index").

Example of usage:
[@
route {
lookup("location");
t_on_branch("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
branch_route[1] {
if(uri=~"10\.10\.10].10") {
# discard branches that go to 10.10.10.10
drop();
}
}
@]


----
!!!!failure_route

Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches.


'''Triggered by''' : receiving or generation(internal) of a negative reply that completes the transaction (all branches are terminated with negative replies)

'''Processing''' : the original SIP request (that was sent out)

'''Type''' : stateful

'''Default action''' : if no new branch is generated or no reply is forced over, by default, the winning reply will be sent back to UAC.

The 'failure_route' is executed only by TM module after it was armed via t_on_failure("failure_route_index").

Note that in 'failure_route' is processed the request that initiated the transaction, not the reply .


Example of usage:
[@
route {
lookup("location");
t_on_failure("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
failure_route[1] {
if(is_method("INVITE")) {
# call failed - relay to voice mail
t_relay("udp:voicemail.server.com:5060");
}
}
@]


----
!!!!onreply_route


Reply routing block. It contains a set of actions to be taken for SIP replies.

'''Triggered by''' : receiving of a reply from the network

'''Processing''' : the received reply

'''Type''' : stateful (if bound to a transaction) or stateless (if global reply route).

'''Default action''' : if the reply is not dropped (only provisional replies can be), it will be injected and processed by the transaction engine.

There are three types of onreply routes:

* '''global''' - it catches all replies received by OpenSIPS and does not need any special arming (simple definition is enough) - named 'onreply_route {...}' or 'onreply_route[0] {...}'.

* '''per request/transaction''' - it catches all received replies belonging to a certain transaction and need to be armed (via "t_on_reply()" ) at request time, in REQUEST ROUTE - named 'onreply_route[N] {...}'.

* '''per branch''' - it catches only the replies that belong to a certain branch from a transaction. It needs to be armed (also via "t_on_reply()" ) at request time, but in BRANCH ROUTE, when a certain outgoing branch is processed - named 'onreply_route[N] {...}'.

Certain 'onreply_route' blocks can be executed by TM module for special replies. For this, the 'onreply_route' must be armed for the SIP requests whose replies should be processed within it, via t_on_reply("onreply_route_index").

[@
route {
seturi("sip:bob@opensips.org"); # first branch
append_branch("sip:alice@opensips.org"); # second branch

t_on_reply("global"); # the "global" reply route
# is set the whole transaction
t_on_branch("1");

t_relay();
}

branch_route[1] {
if ($rU=="alice")
t_on_reply("alice"); # the "alice" reply route
# is set only for second branch
}

onreply_route {
xlog("OpenSIPS received a reply from $si\n");
}


onreply_route[alice] {
xlog("received reply on the branch from alice\n");
}

onreply_route[global] {
if (t_check_status("1[0-9][0-9]")) {
setflag(1);
log("provisional reply received\n");
if (t_check_status("183"))
drop;
}
}

@]


----
!!!!error_route

The error route is executed automatically when a parsing error occurred during SIP request processing. This allow the administrator to decide what to do in case of error.

'''Triggered by''' : parsing error in "route"

'''Processing''' : failed request

'''Type''' : stateless (recommended)

'''Default action''' : discard request.


In error_route, the following pseudo-variables are available to get access to error details:
* $(err.class) - the class of error (now is '1' for parsing errors)
* $(err.level) - severity level for the error
* $(err.info) - text describing the error
* $(err.rcode) - recommended reply code
* $(err.rreason) - recommended reply reason phrase

[@
error_route {
xlog("--- error route class=$(err.class) level=$(err.level)
info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
sl_send_reply("$err.rcode", "$err.rreason");
exit;
}
@]


----
!!!!local_route

The local route is executed automatically when a new SIP request is generated by TM, internally (no UAC side). This is a route intended to be used for message inspection, accounting and for applying last changes on the message headers. Routing and signaling functions are not allowed.

'''Triggered by''' : TM generating a brand new request

'''Processing''' : the new request

'''Type''' : stateful

'''Default action''' : send the request out



[@
local_route {
if (is_method("INVITE") && $ru=~"@foreign.com") {
append_hf("P-hint: foreign request\r\n");
exit;
}
if (is_method("BYE") ) {
acc_log_request("internally generated BYE");
}
}
@]

----
!!!!startup_route

The '''startup_route''' is executed only once when OpenSIPS is started and before the processing of SIP messages begins. This is useful if some initiation actions are needed, like loading some data in the cache, to ease up the future processing. Notice that this route, compared to the others is not triggered at the receipt of a message, so the functions that can be called here must not do processing on the message.

'''Triggered''' : At startup, before the listener processes are started.

'''Processing''' : Initializing functions.


[@
startup_route {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
cache_store("local", "rule1", "$avp(i:100)");
}
@]

----
!!!!timer_route

The '''timer_route''' is as the name suggests, a route executed periodically at a configured interval of time specified next to the name(in seconds). The same as the startup_route, this route does not process a message. You can defined more timer routes.


'''Triggered by''' : The time keeper.

'''Processing''' : Functions that do refresh actions.


[@
timer_route[gw_update, 300] {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
$shv(i:100) =$avp(i:100);
}
@]

----

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Stomaz]] &mdash; [-22 November 2012, 19:13-]
>>messageitem<<
Very good!!
Is very util for me! Im starting in OpenSipS.
Tanks!!
>><<

----
!!!! event_route
The '''event_route''' is used by the OpenSIPS Event Interface to execute script code when an event is triggered. The name of the route is the event that has to be handled by that route.

'''Triggered by''' : the [[http://www.opensips.org/html/docs/modules/devel/event_route | event_route ]] module when an event raised by the OpenSIPS Event Interface

'''Processing''' : the event triggered

'''Type''' : stateless (recommended)

'''Default action''' : no script code is executed when the event is raised.

[@
event_route[E_PIKE_BLOCKED] {
xlog("The E_PIKE_BLOCKED event was raised\n");
}
@]

(:commentboxchrono:)
to:
(:redirect Documentation/Script-Routes quiet=1:)
January 29, 2013, at 06:36 PM by vlad_paiu -
Changed line 5 from:
This Documentation is for '''OpenSIPS 1.9.x/devel'''
to:
This Documentation is for '''OpenSIPS 1.10.x/devel'''
January 11, 2013, at 01:06 PM by razvancrainea -
Changed line 285 from:
The '''event_route''' is used by the OpenSIPS Event Interface to execute script code when an event is triggered.
to:
The '''event_route''' is used by the OpenSIPS Event Interface to execute script code when an event is triggered. The name of the route is the event that has to be handled by that route.
January 11, 2013, at 12:52 PM by razvancrainea -
Deleted lines 272-273:

Changed lines 283-301 from:
(:commentboxchrono:)
to:
----
!!!! event_route
The '''event_route''' is used by the OpenSIPS Event Interface to execute script code when an event is triggered.

'''Triggered by''' : the [[http://www.opensips.org/html/docs/modules/devel/event_route | event_route ]] module when an event raised by the OpenSIPS Event Interface

'''Processing''' : the event triggered

'''Type''' : stateless (recommended)

'''Default action''' : no script code is executed when the event is raised.

[@
event_route[E_PIKE_BLOCKED] {
xlog("The E_PIKE_BLOCKED event was raised\n");
}
@]

(:commentboxchrono:)
November 22, 2012, at 08:13 PM by Stomaz - Comment added
Added lines 276-283:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Stomaz]] &mdash; [-22 November 2012, 19:13-]
>>messageitem<<
Very good!!
Is very util for me! Im starting in OpenSipS.
Tanks!!
>><<
August 22, 2012, at 12:33 PM by bogdan -
Deleted lines 275-281:


[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Socheat]] &mdash; [-22 August 2012, 07:30-]
>>messageitem<<
At last some rtaioanlity in our little debate.
>><<
August 22, 2012, at 08:30 AM by Socheat - Comment added
Added lines 277-282:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Socheat]] &mdash; [-22 August 2012, 07:30-]
>>messageitem<<
At last some rtaioanlity in our little debate.
>><<
August 21, 2012, at 11:08 AM by bogdan -
Deleted lines 276-286:
[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Alexus]] &mdash; [-20 August 2012, 07:53-]
>>messageitem<<
Hi Fred,I think you mean this: You can achieve this by using 2 caerndles, 1 with background the same and 1 with different background for selected. With the use of a history component on the first calender, you can set a dynamic visabilty on the first with an empty history cell and the second with a filled history cell. Just let the default date for the second calender be the destination date of the first.
>><<

[[#comment2]](:nl:)>>messagehead<<
!!!!![[~Ramesh]] &mdash; [-20 August 2012, 09:17-]
>>messageitem<<
STU_JDWHEELE&gt;%SYS-PHONE-REQ 15:35:27 23-OCT-1988: GOD is phoning you on VAX:VAX1[repeat...]meanwhile, on aohentr terminal:one ringy-dingy.two ringy-dingys.three ringy-dingys.[etc...]basil: *evil laugh*, then "Oh this is artwork!"I still have the printout of that hack. If I had it with me, I'd have gotten the vms message syntax right.
>><<
August 20, 2012, at 10:17 AM by Ramesh - Comment added
Added lines 281-286:
>><<

[[#comment2]](:nl:)>>messagehead<<
!!!!![[~Ramesh]] &mdash; [-20 August 2012, 09:17-]
>>messageitem<<
STU_JDWHEELE&gt;%SYS-PHONE-REQ 15:35:27 23-OCT-1988: GOD is phoning you on VAX:VAX1[repeat...]meanwhile, on aohentr terminal:one ringy-dingy.two ringy-dingys.three ringy-dingys.[etc...]basil: *evil laugh*, then "Oh this is artwork!"I still have the printout of that hack. If I had it with me, I'd have gotten the vms message syntax right.
August 20, 2012, at 08:53 AM by Alexus - Comment added
Added lines 276-281:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Alexus]] &mdash; [-20 August 2012, 07:53-]
>>messageitem<<
Hi Fred,I think you mean this: You can achieve this by using 2 caerndles, 1 with background the same and 1 with different background for selected. With the use of a history component on the first calender, you can set a dynamic visabilty on the first with an empty history cell and the second with a filled history cell. Just let the default date for the second calender be the destination date of the first.
>><<
March 22, 2012, at 01:59 PM by vlad_paiu -
Changed line 5 from:
This Documentation is for '''OpenSIPS 1.8.x/devel'''
to:
This Documentation is for '''OpenSIPS 1.9.x/devel'''
July 12, 2011, at 07:57 PM by bogdan -
Changed line 1 from:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsCookbooks | CookBooks]] -> Routing Blocks - devel
to:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsCookbooks | CookBooks]] -> Routing Blocks
Changed line 5 from:
This Documentation is for '''OpenSIPS 1.7.x/devel'''
to:
This Documentation is for '''OpenSIPS 1.8.x/devel'''
May 13, 2011, at 12:39 PM by 109.99.2.142 -
Deleted lines 275-279:
[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Marge]] &mdash; [-12 May 2011, 19:54-]
>>messageitem<<
Very true! Makes a change to see soemnoe spell it out like that. :)
>><<
May 12, 2011, at 08:54 PM by Marge - Comment added
Added lines 276-281:
[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Marge]] &mdash; [-12 May 2011, 19:54-]
>>messageitem<<
Very true! Makes a change to see soemnoe spell it out like that. :)
>><<
May 12, 2011, at 12:27 PM by bogdan - Comments Cleanup
Deleted lines 275-281:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Nelda]] &mdash; [-11 May 2011, 21:59-]
>>messageitem<<
That's 2 celver by half and 2x2 clever 4 me. Thanks!
>><<
May 11, 2011, at 10:59 PM by Nelda - Comment added
Added lines 276-281:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Nelda]] &mdash; [-11 May 2011, 21:59-]
>>messageitem<<
That's 2 celver by half and 2x2 clever 4 me. Thanks!
>><<
May 11, 2011, at 10:13 AM by bogdan - Cleanup
Deleted lines 275-280:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Reggie]] &mdash; [-11 May 2011, 02:55-]
>>messageitem<<
That's not just the best answer. It's the bsetest answer!
>><<
May 11, 2011, at 03:55 AM by Reggie - Comment added
Added lines 276-281:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Reggie]] &mdash; [-11 May 2011, 02:55-]
>>messageitem<<
That's not just the best answer. It's the bsetest answer!
>><<
October 14, 2009, at 12:42 AM by bogdan -
Changed line 5 from:
This Documentation is for '''OpenSIPS 1.6.x/devel'''
to:
This Documentation is for '''OpenSIPS 1.7.x/devel'''
September 10, 2009, at 03:07 PM by bogdan -
Changed lines 130-131 from:
The main 'onreply_route' identified by 'onreply_route {...}' or 'onreply_route[0] {...}' is executed for all replies received.
to:
There are three types of onreply routes:

* '''global''' - it catches all replies received by OpenSIPS and does not need any special arming (simple definition is enough) - named 'onreply_route {...}' or 'onreply_route[0] {...}'.

* '''per request/transaction''' - it catches all received replies belonging to a certain transaction and need to be armed (via "t_on_reply()" ) at request time, in REQUEST ROUTE - named 'onreply_route[N] {...}'.

* '''per branch''' - it catches only the replies that belong to a certain branch from a transaction. It needs to be armed (also via "t_on_reply()" ) at request time, but in BRANCH ROUTE, when a certain outgoing branch is processed - named 'onreply_route[N] {...}'.
Changed lines 141-152 from:
route {
lookup("location");
t_on_reply("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
onreply_route[1] {
if(status=~"1[0-9][0-9]") {
log("provisional response\n");
}
}
to:
route {
seturi("sip:bob@opensips.org"); # first branch
append_branch("sip:alice@opensips.org"); # second branch

t_on_reply("global"); # the "global" reply route
# is set the whole transaction
t_on_branch("1");

t_relay();
}

branch_route[1] {
if ($rU=="alice")
t_on_reply("alice"); # the "alice" reply route
# is set only for second branch
}

onreply_route {
xlog("OpenSIPS received a reply from $si\n");
}


onreply_route[alice] {
xlog("received reply on the branch from alice\n");
}

onreply_route[global] {
if (t_check_status("1[0-9][0-9]")) {
setflag(1);
log("provisional reply received\n");
if (t_check_status("183"))
drop;
}
}
September 10, 2009, at 02:14 PM by anca_vamanu -
Changed lines 234-236 from:
'''Processing''' : Functions that do refresh or check actions.

to:
'''Processing''' : Functions that do refresh actions.

Changed lines 239-240 from:
to:
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
$shv(i:100) =$avp(i:100);
September 10, 2009, at 12:53 PM by anca_vamanu -
Changed lines 185-186 from:
The local route is executed automatically when a new SIP request is generated by TM, internally (no UAC side). This is a route intended to be used for message inspection, accouting and for applying last changes on the message headers. Routing and signalling functions are not allowed.
to:
The local route is executed automatically when a new SIP request is generated by TM, internally (no UAC side). This is a route intended to be used for message inspection, accounting and for applying last changes on the message headers. Routing and signaling functions are not allowed.
Deleted line 208:
Changed lines 210-214 from:
[[#comment1]](:nl:)>>messagehead<<
!!!!![[~sorry , I'm new.]] &mdash; [-12 August 2009, 23:30-]
>>messageitem<<
this is very good informations, thas's question how help me ?
>><<
to:
!!!!startup_route

The '''startup_route''' is executed only once when OpenSIPS is started and before the processing of SIP messages begins. This is useful if some initiation actions are needed, like loading some data in the cache, to ease up the future processing. Notice that this route, compared to the others is not triggered at the receipt of a message, so the functions that can be called here must not do processing on the message.

'''Triggered''' : At startup, before the listener processes are started.

'''Processing''' : Initializing functions.


[@
startup_route {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
cache_store("local", "rule1", "$avp(i:100)");
}
@]

----
!!!!timer_route

The '''timer_route''' is as the name suggests, a route executed periodically at a configured interval of time specified next to the name(in seconds). The same as the startup_route, this route does not process a message. You can defined more timer routes.


'''Triggered by''' : The time keeper.

'''Processing''' : Functions that do refresh or check actions.


[@
timer_route[gw_update, 300] {

}
@]



----
August 13, 2009, at 12:30 AM by sorry I'm new - Comment added
Added lines 211-216:
[[#comment1]](:nl:)>>messagehead<<
!!!!![[~sorry , I'm new.]] &mdash; [-12 August 2009, 23:30-]
>>messageitem<<
this is very good informations, thas's question how help me ?
>><<
April 23, 2009, at 11:35 AM by bogdan -
Changed lines 1-2 from:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsCookbooks | CookBooks]] -> Routing Blocks
to:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsCookbooks | CookBooks]] -> Routing Blocks - devel
----
Changed line 5 from:
This Documentation is for '''OpenSIPS 1.5.x'''
to:
This Documentation is for '''OpenSIPS 1.6.x/devel'''
March 03, 2009, at 11:57 AM by bogdan -
Changed lines 5-6 from:
This Documentation is for '''OpenSIPS 1.4.x'''
to:
This Documentation is for '''OpenSIPS 1.5.x'''
Added lines 9-10:

-----
Added lines 45-46:

----
Added lines 78-79:

----
Deleted line 109:
append_branch();
Added line 116:
----
Added line 150:
----
Added line 182:
----
March 03, 2009, at 11:54 AM by bogdan -
Added lines 4-5:

This Documentation is for '''OpenSIPS 1.4.x'''
March 03, 2009, at 11:52 AM by bogdan -
Changed lines 102-103 from:
t_relay_to_udp("voicemail.server.com","5060");
to:
append_branch();
t_relay("udp:voicemail.server.com:5060");
Changed line 190 from:
append_hf("P-hint: foreign request");
to:
append_hf("P-hint: foreign request\r\n");
Added lines 200-201:
----
(:commentboxchrono:)
October 08, 2008, at 09:45 AM by 81.180.102.217 -
Changed lines 1-2 from:
!!Resources -> [[Resources.Documentation | Documentation]] -> Routing Blocks
to:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsCookbooks | CookBooks]] -> Routing Blocks
October 03, 2008, at 01:52 PM by 81.180.102.217 -
Added lines 3-4:
(:toc-float Table of Content:)
July 21, 2008, at 06:54 PM by 81.180.102.217 -
Added lines 9-16:
'''Triggered by''' : receiving an external request from the network.

'''Processing''' : the triggering SIP request.

'''Type''' : initially stateless, may be forced to stateful by using TM functions.

'''Default action''' : if the request is not either forwarded nor replied, the route will simply discard the request at the end.
Changed lines 41-42 from:
Request's branch routing block. It contains a set of actions to be taken for each branch of a SIP request. It is executed only by TM module after it was armed via t_on_branch("branch_route_index").
to:
Request's branch routing block. It contains a set of actions to be taken for each branch of a SIP request.

'''Triggered by''' : preparation a new branch (of a request); the branch is well formed, but not yet sent out.

'''Processing''' : the SIP request (with the branch particularities, like RURI, branch flags)

'''Type''' : stateful

'''Default action''' : if the branch is not dropped (via "drop" statement), the branch will be automatically sent out.

It is executed only by TM module after it was armed via t_on_branch("branch_route_index").
Changed lines 72-73 from:
Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches. The 'failure_route' is executed only by TM module after it was armed via t_on_failure("failure_route_index").
to:
Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches.


'''Triggered by''' : receiving or generation(internal) of a negative reply that completes the transaction (all branches are terminated with negative replies)

'''Processing''' : the original SIP request (that was sent out)

'''Type''' : stateful

'''Default action''' : if no new branch is generated or no reply is forced over, by default, the winning reply will be sent back to UAC.

The 'failure_route' is executed only by TM module after it was armed via t_on_failure("failure_route_index").
Added lines 111-118:
'''Triggered by''' : receiving of a reply from the network

'''Processing''' : the received reply

'''Type''' : stateful (if bound to a transaction) or stateless (if global reply route).

'''Default action''' : if the reply is not dropped (only provisional replies can be), it will be injected and processed by the transaction engine.
Added lines 143-151:
'''Triggered by''' : parsing error in "route"

'''Processing''' : failed request

'''Type''' : stateless (recommended)

'''Default action''' : discard request.

Added lines 168-196:


!!!!local_route

The local route is executed automatically when a new SIP request is generated by TM, internally (no UAC side). This is a route intended to be used for message inspection, accouting and for applying last changes on the message headers. Routing and signalling functions are not allowed.

'''Triggered by''' : TM generating a brand new request

'''Processing''' : the new request

'''Type''' : stateful

'''Default action''' : send the request out



[@
local_route {
if (is_method("INVITE") && $ru=~"@foreign.com") {
append_hf("P-hint: foreign request");
exit;
}
if (is_method("BYE") ) {
acc_log_request("internally generated BYE");
}
}
@]

July 21, 2008, at 06:36 PM by 81.180.102.217 -
Changed lines 1-2 from:
!!!Routing Blocks
to:
!!Resources -> [[Resources.Documentation | Documentation]] -> Routing Blocks
July 19, 2008, at 09:18 PM by 81.180.102.217 -
Added lines 1-121:
!!!Routing Blocks

'''OpenSIPS''' routing logic uses several types of routes. Each type of route is triggered by a certain event and allows you to process a certain type of message (request or reply).

!!!!route

Request routing block. It contains a set of actions to be taken for SIP requests.

The main 'route' block identified by 'route{...}' or 'route[0]{...}' is executed for each SIP request.

The implicit action after execution of the main route block is to drop the SIP request. To send a reply or forward the request, explicit actions must be called inside the route block.

Example of usage:
[@
route {
if(is_method("OPTIONS")) {
# send reply for each options request
sl_send_reply("200", "ok");
exit();
}
route(1);
}
route[1] {
# forward according to uri
forward();
}
@]

Note that if a 'route(X)' is called from a 'branch_route[Y]' then in 'route[X]' is just processed each separate branch instead of all branches together as occurs in main route.

!!!!branch_route

Request's branch routing block. It contains a set of actions to be taken for each branch of a SIP request. It is executed only by TM module after it was armed via t_on_branch("branch_route_index").

Example of usage:
[@
route {
lookup("location");
t_on_branch("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
branch_route[1] {
if(uri=~"10\.10\.10].10") {
# discard branches that go to 10.10.10.10
drop();
}
}
@]

!!!!failure_route

Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches. The 'failure_route' is executed only by TM module after it was armed via t_on_failure("failure_route_index").

Note that in 'failure_route' is processed the request that initiated the transaction, not the reply .


Example of usage:
[@
route {
lookup("location");
t_on_failure("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
failure_route[1] {
if(is_method("INVITE")) {
# call failed - relay to voice mail
t_relay_to_udp("voicemail.server.com","5060");
}
}
@]


!!!!onreply_route


Reply routing block. It contains a set of actions to be taken for SIP replies.

The main 'onreply_route' identified by 'onreply_route {...}' or 'onreply_route[0] {...}' is executed for all replies received.

Certain 'onreply_route' blocks can be executed by TM module for special replies. For this, the 'onreply_route' must be armed for the SIP requests whose replies should be processed within it, via t_on_reply("onreply_route_index").

[@
route {
lookup("location");
t_on_reply("1");
if(!t_relay()) {
sl_send_reply("500", "relaying failed");
}
}
onreply_route[1] {
if(status=~"1[0-9][0-9]") {
log("provisional response\n");
}
}
@]


!!!!error_route

The error route is executed automatically when a parsing error occurred during SIP request processing. This allow the administrator to decide what to do in case of error.

In error_route, the following pseudo-variables are available to get access to error details:
* $(err.class) - the class of error (now is '1' for parsing errors)
* $(err.level) - severity level for the error
* $(err.info) - text describing the error
* $(err.rcode) - recommended reply code
* $(err.rreason) - recommended reply reason phrase

[@
error_route {
xlog("--- error route class=$(err.class) level=$(err.level)
info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
sl_send_reply("$err.rcode", "$err.rreason");
exit;
}
@]

Page last modified on April 24, 2013, at 10:27 PM