[ S N O M 4 S N A T F I L T E R ]
•The parameter “to_ua” is set to “true” if the SBC believes that the call will go to a client endpoint. Note that this may change during the processing of the request.
The SBC expects responses with the following parameters (line- encoded like register responses):
•The parameter “from” contains the value of the
•Similar, you can return a “to” parameter.
•If you return the “uri” parameter, the SBC will route the call to the provided SIP URI. A typical value looks like “sip:123@proxy. com;parm=1234”. You may include any number of parameters. This is useful for passing additional information to the next ele- ment in the routing process. For example, you can pass parameters to a proxy that describes to which destinations it should fork the call and after which time. Also note that according to RFC3261 you may include headers in the URI which will be expanded into pack- et headers. For example, if you return the line “uri: sip:123@test. com?MyHeader=Hello”, the request URI will become “sip:123@test. com” and the header with the name “MyHeader” will be inserted into the packet with the content “Hello”.
•The parameter with the name “id” will carry a token that will be re- turned on the termination web request. With this variable, you can match the start and end transactions.
•If you set the parameter “expires” to a number, you limit the maxi- mum duration of that call. The value contains the number of sec- onds.
•If you return a number if the parameter “error_code”, the request will be rejected with that code. The parameter “error_message” will contain the text that is used as error explanation (for example “Not Allowed”). Please don’t use error codes below 300 (see the SIP RFC if you are not sure which error code to take).
•If the parameter “anonymous” is present, the SBC will insert a Pri- vacy header into the request. When the request leaves the data cen-
5.