Browse code

-fixed t_on_failure docs - added t_on_reply, t_on_branch

Andrei Pelinescu-Onciul authored on 09/12/2005 22:38:25
Showing 1 changed files
... ...
@@ -71,23 +71,23 @@ if (!t_relay())
71 71
 	</example>
72 72
     </section>
73 73
     
74
-    <section id="t_on_negative">
74
+    <section id="t_on_failure">
75 75
 	<title>
76
-	    <function>t_on_negative(reply_route)</function>
76
+	    <function>t_on_failure(failure_route)</function>
77 77
 	</title>
78 78
 	<para>
79
-	    Sets reply routing block, to which control is passed after a
79
+	    Sets failure routing block, to which control is passed after a
80 80
 	    transaction completed with a negative result but before sending a
81 81
 	    final reply. In the referred block, you can either start a new
82 82
 	    branch (good for services such as forward_on_no_reply) or send a
83 83
 	    final reply on your own (good for example for message silo, which
84 84
 	    received a negative reply from upstream and wants to tell upstream
85 85
 	    "202 I will take care of it"). Note that the set of
86
-	    command which are usable within reply_routes is strictly limited to
86
+	    commands which are usable within failure_routes is strictly limited to
87 87
 	    rewriting URI, initiating new branches, logging, and sending
88 88
 	    stateful replies (<function>t_reply</function>). Any other commands
89 89
 	    may result in unpredictable behavior and possible server
90
-	    failure. Note that whenever reply_route is entered, uri is reset to
90
+	    failure. Note that whenever failure_route is entered, uri is reset to
91 91
 	    value which it had on relaying. If it temporarily changed during a
92 92
 	    reply_route processing, subsequent reply_route will ignore the
93 93
 	    changed value and use again the original one.
... ...
@@ -95,20 +95,20 @@ if (!t_relay())
95 95
 	<para>Meaning of the parameters is as follows:</para>
96 96
 	<itemizedlist>
97 97
 	    <listitem>
98
-		<para><emphasis>reply_route</emphasis> - Reply route block to be called.
98
+		<para><emphasis>failure_route</emphasis> - Failure route block to be called.
99 99
 		</para>
100 100
 	    </listitem>
101 101
 	</itemizedlist>
102 102
 	<example>
103
-	    <title><function>t_on_negative</function> usage</title>
103
+	    <title><function>t_on_failure</function> usage</title>
104 104
 	    <programlisting>
105 105
 ...
106 106
 route { 
107
-    t_on_negative("1"); 
107
+    t_on_failure("1"); 
108 108
     t_relay(); 
109 109
 } 
110 110
 
111
-reply_route[1] {
111
+failure_route[1] {
112 112
     revert_uri(); 
113 113
     setuser("voicemail"); 
114 114
     append_branch(); 
... ...
@@ -121,7 +121,88 @@ reply_route[1] {
121 121
 	    combination of serial with parallel forking.
122 122
 	</para>
123 123
     </section>
124
-    
124
+ 
125
+	 <section id="t_on_reply">
126
+	<title>
127
+	    <function>t_on_reply(onreply_route)</function>
128
+	</title>
129
+	<para>
130
+	    Sets the reply routing block, to which control is passed when a
131
+	    reply for the current transaction is received.
132
+	    Note that the set of commands which are usable within onreply_routes is
133
+	     limited.
134
+	</para>
135
+	<para>Meaning of the parameters is as follows:</para>
136
+	<itemizedlist>
137
+	    <listitem>
138
+		<para><emphasis>onreply_route</emphasis> - Onreply route block to be
139
+			called.
140
+		</para>
141
+	    </listitem>
142
+	</itemizedlist>
143
+	<example>
144
+	    <title><function>t_on_reply</function> usage</title>
145
+	    <programlisting>
146
+...
147
+loadmodule "/usr/local/lib/ser/modules/nathelper.so"
148
+...
149
+route { 
150
+	/* if natted */
151
+	t_on_reply("1"); 
152
+	t_relay(); 
153
+} 
154
+
155
+onreply_route[1] {
156
+	if (status=~ "(183)|2[0-9][0-9]"){
157
+		force_rtp_proxy();
158
+		search_append('^(Contact|m)[ \t]*:.*sip:[^>[:cntrl:]]*', ';nat=yes');
159
+	}
160
+	if (nat_uac_test("1")){
161
+		fix_nated_contact();
162
+	}
163
+}
164
+	    </programlisting>
165
+	</example>
166
+	</section>
167
+
168
+	<section id="t_on_branch">
169
+	<title>
170
+	    <function>t_on_branch(branch_route)</function>
171
+	</title>
172
+	<para>
173
+	    Sets the branch routing block, to which control is passed after
174
+	    forking (when a new branch is created). For now branch routes
175
+	    are intended only for last minute changes of the SIP messages
176
+	    (like adding new headers).
177
+	    Note that the set of commands which are usable within branch_routes is
178
+	    very limited. It is not possible to drop a message or generate a reply.
179
+	</para>
180
+	<para>Meaning of the parameters is as follows:</para>
181
+	<itemizedlist>
182
+	    <listitem>
183
+		<para><emphasis>branch_route</emphasis> - branch route block to be
184
+			called.
185
+		</para>
186
+	    </listitem>
187
+	</itemizedlist>
188
+	<example>
189
+	    <title><function>t_on_branch</function> usage</title>
190
+	    <programlisting>
191
+...
192
+route { 
193
+	t_on_branch("1"); 
194
+	t_relay(); 
195
+} 
196
+
197
+branch_route[1] {
198
+	if (uri=~"sip:[0-9]+"){
199
+		append_hf("P-Warn: numeric uri\r\n");
200
+	}
201
+}
202
+	    </programlisting>
203
+	</example>
204
+	</section>
205
+
125 206
     <section id="append_branch">
126 207
 	<title>
127 208
 	    <function>append_branch()</function>