This is an old revision of the document!


Out-of-Box Configuration File

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:

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 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.


Navigation

Wiki

Other

QR Code
QR Code admin_guide:oob (generated for current page)