Snom 4S NAT Filter, Руководство администратора

Страница: 41 / 56

snom technology AG • 41
[
S N O M
4 S N A T F
I L T E R
]
Changing the request-URI makes it possible to do simple routing
decisions in a very convenient way on a web server (e.g. using PHP
scripting). This can be used for least cost routing, but it can also be used
for load balancing and redirecting calls to announcements for example if
the prepaid card has expired already. The filter almost becomes a proxy
with this feature.
The filter talks asynchronously to the web server. That means,
the processing of other requests is not blocked by the request. Also the
processing of other web requests is also not blocked by another web
request. The request is only made at the beginning of a call; further
messages inside the call will not cause additional web requests.
The request is only made on INVITE-initiated dialogs.
The address of the web server must be entered into the
Consult
http URL before starting call field. Please use the complete form,
including the http:// in front of the host name. The filter supports only
DNS A resolution for locating the web server; no http proxy is allowed.
Before the filter sends out the web request to the URI it auto-
matically appends some parameters to the URI:
• The parameter “action” is always set to the value “start”. This will
make sure that future extensions are possible.
• The parameter from_uri is set to the URI in the from header. The
display-name and parameters outside of the URI are not available.
Parameters inside the URI are available.
• The parameter to_uri is set to the URI in the to header.
• The parameter uri is set to the value of the request-URI.
All parameters are URL-encoded according to the rules of the
http protocol. A possible request might look like this: http://snom.com/
post.htm?action=start&from_uri=sip:abc@snom.com&to_uri=sip:
def@snom.com&uri=sip:abc@proxy.snom.com (possible escape
characters are not shown here for simplicity).
While the web request is pending, all subsequent requests will
go into a wait queue (including CANCEL). This will make sure that all
requests are processed in the right sequence.
The filter will evaluate the body of the response to the request.
If the response has an error code higher than or equal to 300, it will
not evaluate the result and just continue processing. You will see a log
4.