Out-of-Box Configuration File

The Out-of-Box configuration file contains several feature which are normally needed by a SIP Proxy/Registrar. So this configuration should give you a good starting point for your own full featured SIP server. It:

• takes care of initial sanity checks
• takes care of Record-Routing and Route headers
• replies to OPTIONS requests
• contains Registrar functionality
• authenticates initial requests
• supports NAT traversal] (via the RTP proxy) * offers Session Timer support (as long one UA supports it) * provides speeddial for users * provides optional PSTN conectivity The drawback compared to the simple default configuration is that this configuration has a lot more requirements: * a running database * a running RTP proxy for NAT traversal * one public IP address ===== Proxying ===== The proxying of all requests (except REGISTER - see below at [#registrar|Registrar) follows the following steps:
• At first the route block DOMAIN looks up the From domain and the domain of RURI. If both domains are not known by the proxy (which means these domains do not exist in the database), the request is rejected. This should prevent that the proxy becomes an open relay for all SIP messages.
• After the domain check the request is authenticated in the route block AUTHENTICATION if the From header contains a local domain (see Authentication for more details).
• Next the route block OUTBOUND forwards requests which have non-local domain as target and a local domain in the From header.
• The route block SPEEDDIAL now checks for a local From and a two digit RURI user name. If that matches a 302 response with the real target is send back to the UA.
• Now the route block INBOUND verifies if the target user is known by the system. If that is true a check for call forwarding is performed and finally the registrar is queried for the location(s) of the user.
• Finally the route block PSTN checks if the user name could be a number in the PSTN and then forwards it to the PSTN gateway.

In other words, requests with:

• local From
  • are first authenticated and
  • foreign target are proxied to the target domain
  • local target (user or PSTN) are directly relayed
• foreign From and
  • local target (user) are directly relayed
  • foreign target are rejected

The authentication is done with the data from the database. Therefore you need a database which stores the user informations and the credentials.

The actual authentication is handled in two places in the script. First the route block REGISTRAR contains a call to www_authenticate(). As this whole route block cares only about the REGISTER requests, this means this configuration assumes all REGISTER requests are local and the forwarding of REGISTER requests is not supported. As the www_authenticate() call is used all REGISTER requests are challenged with a 401 reply.

The second place for authentication is in the route block AUTHENTICATION. CANCEL and ACK requests, requests with a non-local From domain and requests from the IP address of the PSTN gateway are not authenticated. All other requests are challenged with a 407 reply by the proxy_authenticate() call in this route block. Beware that for dialog establishing requests like INVITE or SUBSCRIBE only the initial request will be challenged because the in-dialog requests never pass this route block.

The Registrar funtionality is completly implemented in the route block REGISTRAR. This route only processes REGISTER requests and ignores all other requests. The registrar in this configuration is designed to broadcast new registrations via multicast. Thus the first step is to check if the REGISTER request was received over multicast to bypass all the following sanity checks for replicated REGISTER requests. First the target domain is looked up and if unknown the request is rejected. This check is done at first, because it does not require any database lookups. Then the request is authenticated. At last the username in the To header is compare with the authentication user name to make sure only the user itself can register a binding. Finally the REGISTER request is being processed by the save_contacts() call from the registrar module. And if replication of registrations is requested via the FLAG_PEER_REPLICATE flag, the request is replicated via multicast to all neighbour registrars.

The route block NAT_DETECION is called from the initial route block and takes care about detecting UA's behind NATs and trying to fix the issues with that. This route block performs different tests on the request and if one of them returns true the AVP uac_nat is set with the value '1' and the flag FLAG_NAT is set. Additionally this route fixes already the Contact header if the UA is behind a NAT.

The flag FLAG_NAT is then considered in several places in the script:

• first of all the route RTPPROXY handles only requests which have this flag set. The body of INVITEs are re-written with the IP and port of the RTP proxy. And BYEs and CANCELs tear down a previously established session at the RTP proxy. The route RTPPROXY is called for all requests which are forwarded by the route FORWARD, so essetially for all requests which are forwarded to another hop by the proxy.
• in the route REGISTRAR the flag tells the registrar module to store the Contact URI together with the real source IP and port.
• finally the onreply route REPLY_ROUTE re-writtes the bodies of 180, 183 and 2XX responses with the IP and port of the\ RTP proxy if the FLAG_NAT was set before.

The AVP uac_nat is stored as a cookie into the Record-Route header of the proxy. When later in-dialog requests are processed by the route RR and the cookie from the Route is restored the presence of the 'uac_nat' AVP sets the FLAG_NAT again to make sure that also in-dialog requests from NATed UAs are handled properly.