5.
[ S N O M 4 S N A T F I L T E R ]
ter, the
Please note that requests may loop through several SBC. This will typically happen in data centres that use a SBC server farm. In this environment, the application server must be able to handle several call initiation requests for the same call as the SBC do not exchange informa- tion about web requests. A simple implementation just passes an empty response. The subsequent SBC will then just route that call without any other change of the request.
When the uri parameter is present, the SBC does not use the out- bound proxies to route the request. You must make sure in the application logic that an appropriate request URI is inserted.
5.5 Call Termination
When the SBC calls the destructor for the call object, it first sends out web request that informs the applications server that the call has fin- ished. In contrast to the other web requests the answer to that request does not matter — the call is finished anyway.
The SBC provides the following arguments to the request:
•The parameter “action” is set to “end”.
•If the id parameter was set in the response to the start request, the SBC will put that argument in the parameter “id”. The application server may use this information to match the call.
•The parameter “callid” is set to the
•The parameters “from_uri” and “to_uri” are set to the same values as they had during the action=start call.
•The parameter “reason” is set to the message that describes why the desructor was called (see below).
•There are several time values available. All these times are mea- sured in seconds since Jan 1st, 1970. The parameter “time_invite” indicates when the initial INVITE was received. The parameter “time_180” indicates when a 18x request was received (if there was such a response), the parameter “time_200” indicates when the first 2xx code was received. The “time_bye” parameter (if present) shows when a BYE request was received (this parameter is only present when a 2xx was received).