Common Configuration (SIP)

Overview

Some Application instances contain SIP functionality based on the SipApp base class. In addition to the common Application configuration parameters and their application-specific attributes, these SIP Applications typically require SIP configuration as indicated below.

<?xml version="1.0" encoding="utf-8"?>
<n2svcd>
  ...
  <applications>
    ...
    <application name="(name)" module="(module)">
      <include><lib>/path/to/library</lib></include>
      <parameters>
        <!-- application-specific parameters -->
        ...
        <!-- SIP application parameters -->
        <parameter name="sip_bind_host" value="0.0.0.0"/>
        <parameter name="sip_bind_port" value="5060"/>
        ...
        <!-- SDP and RTP integration -->
        <parameter name="early_media_policy" value="never"/>

        <!-- SIP extended configuration -->
        <config>
          <!-- INVITE headers -->
          <invite_headers>
            <invite_header name="Diversion"                         request_edr="DVT"     response_edr="DVT2"   relay_request="yes"/>
            <invite_header name="Remote-Party-ID"                                                               relay_request="yes"/>
            <invite_header name="Ring-Timer"                                                                    relay_response="yes"/>
          </invite_headers>

          <!-- Outbound -->
          <sip_peers>
            <sip_peer id="LOCAL-IVR" sip_host="192.168.1.5" sip_port="5060"/>
          </sip_peers>
          <trunks>
            <trunk leading="999" sip_peer_id="LOCAL-IVR"/>
          </trunks>

          <!-- Inbound -->
          <sip_accounts>
            <sip_account id="LP1" username="665566" password="ABC" from_user_prefix="+9111421451"/>
            <sip_account id="IVR" username="+911142145100@192.168.1.5" password="Aclmob#1" from_user="665566"/>
          </sip_accounts>
        </config>
      </parameters>
    </application>
    ...
  </application>
  ...
</n2svcd>

These SIP parameters include both server-relevant (inbound) and client-relevant (outbound) configuration parameters.

Not all parameters are relevant to all SIP applications.

Configuration Details

The application element attributes for all SIP Application instances are as below.

SIP INVITE Headers

Each SIP INVITE Header definition in this section defines an additional “known” SIP INVITE Header which will be given additional handling for inbound/outbound SIP INVITE requests and responses.

The base SIP App provides base support for the mandatory, base headers such as From, To, Via, Requires, CSeq etc. as documented in this technical guide and the Protocol Conformance Statement documentation. Those base headers already have special treatment built into the system, and hence do not need to be (and must not be) configured in this section. The complete list of special headers which may not be configured here is:

• Via
• From
• To
• Call-ID
• CSeq
• Contact
• Authorization
• WWW-Authenticate
• Content-Type
• Content-Length
• Allow
• User-Agent
• Require
• Supported
• RSeq
• Privacy
• P-Asserted-Identity
• P-Preferred-Identity
• P-Charging-Vector
• Route
• Record-Route

Specifically, when handling inbound SIP INVITE, for headers whose name (case-insensitive) matches a header from the SIP INVITE Header configuration.

• The Header will (if configured) be logged to the IN-ALEG-INVITE EDR.
• The Header will (if configured) be automatically confirmed back in any 2XX Response.
• The Header will (if configured) be automatically confirmed back in any 300-699 Response.
• The Header will (if configured) be automatically relayed in any outbound B-Leg INVITE for this call and will (if configured) be logged to the OUT-BLEG-INVITE EDR.
• The Header will (if configured) be automatically relayed in any outbound A-Leg/B-Leg re-INVITE for this call and will (if configured) be logged to the OUT-ALEG-INVITE/OUT-BLEG-INVITE EDR.

Specifically, when the service logic expressly adds one of these additional known SIP INVITE Headers to an outbound SIP A-Leg INVITE:

• The Header will (if configured) be logged to the OUT-ALEG-INVITE EDR.
• The Header will (if configured) be automatically relayed in any outbound B-Leg INVITE for this call and will (if configured) be logged to the OUT-BLEG-INVITE EDR.
• The Header will (if configured) be automatically relayed in any outbound A-Leg/B-Leg re-INVITE for this call and will (if configured) be logged to the OUT-ALEG-INVITE/OUT-BLEG-INVITE EDR.

Specifically, when the service logic expressly adds one of these additional known SIP INVITE Headers to an outbound SIP B-Leg INVITE:

• The Header will (if configured) be logged to the OUT-BLEG-INVITE EDR.

Each invite_header Object in the config.invite_headers Array is configured as follows.

Note: Any inbound INVITE header listed here will be silently ignored when received on the initial A-Leg INVITE. It will not be passed to the service logic and will not be logged to any EDR

Note: The service logic (when generating an outbound SIP INVITE for the A-Leg or B-Leg) may add headers over and above the headers expressly defined here. However, those additional headers will not be logged to the base SIP EDRs, and will not automatically be relayed as headers in any other A-Leg or B-Leg set-up such as re-INVITE.

Note: All automatic relay/confirmation/provision of the headers configured here will treat the header value as opaque, and will never attempt to parse or modify it.

SIP Peers

Each SIP Peer definition defines an endpoint which is “known” for the purposes of initiating a new outbound (client) SIP Transaction. Specifically:

• A peer may contain one or more endpoints. We send REGISTER and INVITE.
• A peer may terminate one or more trunks. We send INVITE without registration.
• A peer has credentials which we may use if our Request receives a 401 Unauthorized Response.

Each sip_peer Object in the config.sip_peers Array is configured as follows.

SIP Trunks

Each Trunk specifies a number block which is statically configured for sending the outbound INVITE transaction which attempts to create a new dialog for a call leg.

These addresses do not use REGISTER. They are assumed to be always available for INVITE.

Each trunk Object in the config.trunks Array is configured as follows.

Note that in-Dialog client transactions (for re-INVITE, BYE, or 2XX ACK) do not use this SIP Trunks configuration. They will instead search directly for an available entry in the SIP Peers configuration where the SIP Peer host, port, and protocol match the dialog target as defined by the Contact headers supplied to us within the dialog.

SIP Endpoints

Each Endpoint specifies a called party number which this application “dynamically manages”, meaning that we will send REGISTER events to the nominated SIP Peer informing it that we are available to receive inbound requests related to that endpoint.

Each endpoint Object in the config.endpoints Array is configured as follows.

SIP Accounts

Each SIP Account definition defines an account identity which we recognise for inbound request processing. Account membership is determined by simple exact or prefix match of the offered “From” address URI.

Specifically when authorization is enabled:

• An account has credentials which we verify by sending 401 Unauthorized Response.
• If no account is matched, the response will be 404 Not Found Response.

Note that if sip_auth_schema is configured to be open then SIP Account checking is completely bypassed for all inbound requests, and the sip_accounts configuration is irrelevant.

Otherwise this access challenge is applied to all inbound SIP Requests, excepting that:

• SIP CANCEL is never challenged.
• SIP BYE is challenged by default, but this may be disabled with sip_open_bye.
• SIP OPTIONS is challenged by default, but this may be disabled with sip_open_options.
• Challenges may be bypassed for message on TCP connection associated with a known SIP Peer.

Each sip_account Object in the config.sip_accounts Array is configured as follows.

Note:

• At most one of from_user or from_user_prefix must be specified.
• If neither from_user nor from_user_prefix is specified, then username must be present (and is used as from_user).

Trace Trap Entry

Each Trace Trap defines a rule for potentially enabling tracing for an inbound or outbound call.

Each trace_trap Object is configured as follows: