====== Out-of-Box Configuration File ====== This guide is work in progress. The guide was originally conceived as the administrator's guide for SER 2.0 and it is currently being transformed into the Administrator's Guide for the SIP Router. ===== General Overview ===== 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|Registrar]] functionality * [[#authentication|authenticates]] initial requests * supports [[#nat_traversal|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|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 ===== Authentication ===== 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|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. ===== Registrar ===== 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. ===== NAT Traversal ===== 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.