Name

callhandler - sipstone call handler

Synopsis

callhandler config_file

Overview

The call handler program is a part of the sipstone tool. It performs the role of a UAS, albeit limited in its functionality (does not perform retransmissions for example). It receives certain SIP requests (namely, INVITE, ACK, and BYE) from a proxy server and sends responses.  It also maintains request-response statistics.

Upon startup, the call handler registers itself with a SIP proxy server (the "System Under Test").  The username to be registered is specified in the configuration file of the call handler or defaults to "callhandler@hostname:port".  If a registration fails, the program terminates.

Next, the call handler registers a specified number of SIP users (specified in the configuration file) with the proxy server.  These are the users that will be used by the sipstone loader uses to place a SIP call.  Without these users, all calls generated by the loader are bound to fail due to the proxy server not knowing where they can be contacted.  The registrations are sent iteratively, i.e., sending one register request and waiting for a response, one at a time.  If any of these registrations fail,  the program terminates. 

If an INVITE request is received from the proxy server, the call handler first responds with a 180 Ringing, followed by a 200 OK response.  The Contact header used in the response will be the call handler's contact that was sent in the registration request at startup time (e.g., 'callhandler@ip:port').

If an ACK is received, no response is sent.

If a BYE is received, the call handler responds with a 200 OK.

All responses to a received request are sent to the IP:port extracted from the topmost Via header.

The call handler can be operated in a stand alone mode or with the controller. When it is used in conjuction with the controller, the controller needs to know when the callhandler has finished its initial set of registrations, so that it can then start sending SIP requests. Hence, after successful completion of all initial registrations, the call handler sends a UDP message to the controller indicating that all registrations were successful.

Configuration File

Configuration parameter (required) Description
port The UDP/TCP port to listen for requests.  Default is 5060.
serverAddress host (or IP address) of the proxy server where all preliminary register requests are sent to.
serverPort proxy server port.  Default is 5060.
controllerAddress host (or IP address) of the sipstone controller where the UDP ("Registrations finished") message is sent.
controllerPort sipstone controller port("Registrations finished") message is sent.
domain domain of the call handler (e.g., cs.columbia.edu)
protocol TCP|UDP transport protocol used for both listening for requests and sending responses.  Default is UDP.
clientNamePrefix The prefix of all the SIP users to be registered. See Name conventions
clientNameSuffix The starting suffix of all the SIP users to be registered.  Usually a starting number that will be incremented by 1 for each new user to be registered. See Name conventions
clientRange The number of SIP users to register.  Defaults to 100. See Name conventions
callHandlerName The SIP username of the call handler used when registering the call handler.  Default is callhandler.
digestPassword The password to be used for digest authentication for the initial register messages that the callhandler sends to the SUT. It is assumed that all users have the same password. The realm for authentication will be same as the domain parameter. In addition, all user names will be concatenated with the domain parameter (e.g., callhandler@cs.columbia.edu) while sending request.
useAuthentication true|false If this option is present the callhandler will retry with (Proxy) Authorization header when challenged with a 401 or 407. Only Digest authentication is supported.
isDebug true|false whether to print debug information.

Dependencies

The Callhandler requires the presence of the template file register.template. More information on template files can be found here.
Last updated by Sankaran Narayanan@ Internet Real-Time Laboratory