Contents
1 Introduction
This document describes how to configure the basic SIP Trunking Functionality provided by the SIP Trunking Application Server (ST AS) in MTAS. The basic SIP Trunking functionality in ST AS consists of managing of access and routing between the operators IMS Network and enterprises IP-Private Branch Exchange (IP-PBX), and to provide charging support.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the Operation and Maintenance (O&M) area, in general.
1.1.1 Licenses
To enable the functionality in ST AS, the Capacity license must be installed.
For more information about the ST AS license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any of the procedures in this document, the following documents must be available:
1.1.3 Conditions
The following condition must apply:
- An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
This document describes SIP Trunking Connection and Control services offered by ST AS.
ST AS provides interconnection between the IMS network and enterprises PBXs in static or in dynamic mode.
Static mode implies that the PBX does not need to register with IMS. Instead, the PBX has a peering connection with the IMS network and the routing paths are defined in provisioning data.
Dynamic mode connectivity implies that the IP-PBX registers each of its access routes with the IMS network using IMS registration procedure.
2.1 Subfunctions
This section describes the subfunctions provided by the basic SIP Trunking functions, that is, the connection and control services in the ST AS.
2.1.1 PBX Originating Call Handling
This section describes the handling of PBX originating calls.
2.1.1.1 Static Mode Connect
The PBX user can originate calls when the PBX is configured in the IMS network using the static mode PBX connect.
The HSS provisioning is used to select the two following alternatives for routing to the ST AS:
- Ma mode
The user is provisioned with the capabilities of the ST AS. The list of capabilities is then used by Interrogating Call Session Control Function (I-CSCF) to perform a distinct Public Service Identity (PSI) routing to the ST AS.
- ISC mode
The user is provisioned with the CSCF address serving the user. The address is used by the I-CSCF to route the request to the Serving CSCF (S-CSCF), where Initial Filter Criteria (iFC) is used to trigger the ST AS. This alternative allows the multiple ASs to be used, a so called AS chaining.
For PBX originating calls, the Interconnection Border Control Function (IBCF) authenticates the PBX, inserts the PBX identity and orig parameter into the added P-Served-User header field, and signals this to the I-CSCF. The I-CSCF performs a location request to HSS. Depending on the HSS provisioning, the HSS returns the S-CSCF address (ICS mode) or the ST AS capabilities (Ma mode).
If the Ma mode is returned, the I-CSCF uses the received list of capabilities to match to a ST AS name to be used for PSI direct routing.
If the ISC mode is returned, the I-CSCF sends the request to S-CSCF. The S-CSCF executes originating iFCs, and sends the request to the ST AS over ISC.
ST AS can (depending on configuration) validate the calling user identity. ST AS executes the originating services, and thereafter, the ST AS forwards the request to the Transit Function (Ma mode), see Section 3.2, or routes the call-back to the S-CSCF (ISC mode) that checks if additional ASs are to be started, and then routes the request to the terminating network.
ST AS performs feature tag processing as described in Section 2.1.6 Feature Tag Processing, and media policing of concurrent media lines as described in Section 2.1.5 Media Policing of Concurrent Media Lines.
ST AS uses preconfigured Transit Function Address to forward the call request, see Section 3.2.
2.1.1.2 Dynamic Mode Connect
The PBX user can originate calls when the PBX is configured in the IMS network using the dynamic mode PBX connect.
The call is originating from the PBX user using one of the previously registered PBX routes. The Proxy CSCF (P-CSCF) searches for a matching Wildcarded Public User Identity (wIMPU) for the served user, and adds the matched wIMPU into a P-Profile-Key header. The P-CSCF follows the service route stored at registration to Serving CSCF (S-CSCF). The S-CSCF executes originating Initial Filter Criteria (IFCs) sending the request to the ST AS over the IMS Service Control (ISC) interface.
ST AS performs the feature tag processing as described in Section 2.1.6 Feature Tag Processing, and media policing of concurrent media lines as described in Section 2.1.5 Media Policing of Concurrent Media Lines.
The ST AS follows the route inserted by S-CSCF back to the S-CSCF that routes the call towards the terminating network.
2.1.2 PBX Terminating Call
The PBX user can receive calls when the PBX is configured in the IMS network using the Static mode PBX connect.
For static mode, the call request is received in the terminating I-CSCF that makes a location query to HSS. All number series served by the PBX must be provisioned in the IMS Common Name (CN) as wildcarded PSIs.
After successful wildcard match, the HSS, depending on provisioning, returns the S-CSCF address (ISC mode), or a list of capabilities that I-CSCF match to a direct route (Ma mode) to the ST AS. I-CSCF populates received wildcarded identity in the PPK header and forwards the call request to S-CSCF or ST AS depending on ISC or Ma mode. In case of ISC mode, the S-CSCF executes terminating iFCs, and sends the request to the ST AS over ISC.
For dynamic mode connect, the PBX user can receive calls when the PBX has active PBX routes registered. The PBX terminating calls reaches ST AS via S-CSCF over the ISC interface that uses the wIMPU to trigger an ICF for the terminating registered case.
ST AS performs the feature tag processing as described in Section 2.1.6 Feature Tag Processing, and media policing of concurrent media lines as described in Section 2.1.5 Media Policing of Concurrent Media Lines.
The ST AS performs the route selection as described in Section 2.1.3 ST AS Route Handling Static Mode.
If the route selection is successful, the ST AS uses the selected route to forward the call request.
For static mode (Ma mode), the ST AS inserts the selected route in the Route header of the call request, and the call is routed to the PBX through IBCF (Ma mode), or routes the call-back to the S-CSCF (ISC mode) that routes to the PBX through IBCF.
For dynamic mode, an Accept-Contact header is added to the INVITE with required and explicit user preferences saved from the route registration. ST AS follows the route inserted by the S-CSCF, and sends the INVITE back to the S-CSCF that terminates the call through P-CSCF.
2.1.3 ST AS Route Handling Static Mode
A PBX can be connected to IMS with multiple PBX routes simultaneously for increased trunking capacity and robustness. For PBX terminating calls, the ST AS uses random selection among all active routes. If no active route is available, a standby route is used, if defined.
For handling the connection errors, ST AS supports configurable profiles. The profile defines the fault codes to be classified as connection errors.
A connection error implies that ST AS puts the route into error_guard state and cancels the outstanding INVITE request, if necessary. Reselection of another route is not attempted.
The state machine for a PBX route handling is described in Figure 1. The state machine consists of a ready, operator_blocked, and error_guard states.
For PBX route used in the static mode PBX connect, the route is
in ready state after creation, which occurs
when the PBX Service document of the PBX has been retrieved and definition
of all routes has been determined from it.
The operator can
set the route into operator_blocked state
or move it back to ready state through
provisioning.
- Note:
- Move the route from error_guard state to ready state, the route must be first blocked and then unblocked by the operator.
When ST AS attempts to use a PBX route and receives a permanent error related specifically to the route, the route is moved to the error_guard state. The route moves back from error_guard to ready after expiry of an error_guard_timer. The error guard time-out is an operator configurable node parameter. ST AS also attempts to use a route in error_guard state, if that is the only route option it finds. A successful request routed on a route in error_guard state results in the route state being moved to ready state.
2.1.4 Route Handling Dynamic Mode
For dynamic mode connect, a route is in ready state after the route has been registered. When selecting a route for a terminating call, a random selection is done among all routes in ready state.
2.1.5 Media Policing of Concurrent Media Lines
The media policing of concurrent media streams is triggered whenever a SDP-offer is received from any of the involved users during establishment of a PBX originating and PBX Terminating call, or after the call has been established when a session update is performed. If the number of active media lines in the SDP-offer is more than 10, the call or session attempt is rejected.
2.1.6 Feature Tag Processing
Table 1 describes the processing of feature tags in the Accept-Contact header. Where "Known" implies a feature tag configured in, mtasStPrimaryFeatureTag and mtasStSecondaryFeatureTags, and "Unknown" implies a feature tag not configured in, mtasStPrimaryFeatureTag and mtasStSecondaryFeatureTags.
The value urn:urn-7: 3gpp-service.ims.icsi.mmtel is configured in the mtasStPrimaryFeatureTag attribute by default.
With the extended feature tag function, it is possible to tag the primary feature tag with a specified value defined in the attribute mtasStExtendedStringFeatureTag, for example, audio;explicit;require. The function extended feature tag is configured in mtasStExtendedFeatureTag and mtasStExtendedStringFeatureTag Managed Object (MO) attributes.
If the mtasStExtendedFeatureTag attribute is set to true, and the received INVITE does not contain an Accept-Contact header. Then, a new Accept-Contact header entry is added which contains the primary feature tag as defined by mtasStPrimaryFeatureTag, and extended by the feature tag extension as defined by mtasMmtExtendedStringFeatureTag.
|
Accept-Contact Headers |
Action Taken |
|---|---|
|
"Known" feature tag present in one of the Accept-Contact headers in the initial incoming INVITE. |
The session is accepted as an ST AS session if any of the known feature tags are present in the Accept-Contact. If the Accept-Contact header in the initial incoming INVITE does not contain the mtasStPrimaryFeatureTag but contains mtasStSecondaryFeatureTags, then the mtasStPrimaryFeatureTag is added. If there is a feature tag value defined in the mtasStPrimaryFeatureTag of urn-type, for example, urn:urn-7:3gpp-service.ims.icsi.mmtel, the following feature tag is added, unless +g.3gpp.icsi-ref is present in the mtasStSecondaryFeatureTags. The feature tag +g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel" is also copied into the Contact header. |
|
"Unknown" feature tag present along with a recognized MMTel feature tag in one of the Accept-Contact headers in the initial incoming INVITE. |
The session is accepted as an ST AS session if any of the known feature tags are present in the Accept-Contact. If the Accept-Contact header in the initial incoming INVITE does not contain the mtasStPrimaryFeatureTag but contains mtasStSecondaryFeatureTags, then the mtasStPrimaryFeatureTag is added. If there is a feature tag value defined in the mtasStPrimaryFeatureTag of urn-type, for example, urn:urn-7:3gpp-service.ims.icsi.mmtel, the following feature tag is added unless +g.3gpp.icsi-ref is present in the mtasStSecondaryFeatureTags. The feature tag +g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel" is also copied into the Contact header. |
|
"Unknown" feature tag present with no MMTel recognizable feature tag in any of the Accept-Contact headers in the initial incoming INVITE. |
The session is rejected with a 503 if none of the configured feature tags in mtasStSecondaryFeatureTags or mtasStPrimaryFeatureTag matches any of the Accept-Contact headers. |
|
No Accept-Contact headers present. |
|
|
No feature tag present in any of the Accept-Contact headers in the initial incoming INVITE. |
2.1.7 O&M Operations
The O&M operations specific the SIP Trunking connection and control services in ST AS are as follows:
3 Connection and Control Services in ST AS Configuration
The basic SIP Trunking functionality in ST AS is controlled by the MtasSt and MtasStControlAccessProfile Managed Objects (MOs).
In addition, a few attributes related to the SIP Trunking functionality in ST AS are controlled by the MtasShIf and MtasSip MOs.
An overview of the ST MO is shown in Figure 2.
For MOs and attributes related to the ST AS, refer to Managed Object Model (MOM).
3.1 ST AS Administrative State Configuration
The ST AS is enabled by setting the mtasStAdministrativeState attribute in the MtasSt MO to 1 (Unlocked). If the mtasStAdministrativeState is set to 0 (Locked), the ST AS is not provided by the MTAS.
3.2 Transit Function Address Configuration
For static mode connect over Ma interface, a PBX originating call is routed to the terminating side through the transit function in the home network. The address that can be a Fully Qualified Domain Name (FQDN) or IP address of the transit function is specified by the mtasStTransitFunction attribute.
3.3 SIP Trunking Charging Profile Reference
The mtasStChargingProfileRef attribute is the name of the charging profile that is used for the ST AS. A charging profile with this name must have been created before the name is set. If no name is specified, the charging profile with the name default is used. For more information about creation of charging profiles in MTAS, refer to MTAS Charging Management Guide.
3.4 Feature Tag Handling Configuration
The feature tag handling in ST AS is described in Section 2.1.6 Feature Tag Processing.
The mtasStPrimaryFeatureTag defines the primary SIP Trunking feature tag. The primary feature tag is added, if an ST session is detected.
The mtasStSecondaryFeatureTags attribute defines secondary feature tags used to recognize an ST AS session.
The mtasStExtendedStringFeatureTag attribute defines the string extension to add to the primary feature tag.
The mtasStExtendedFeatureTag attribute defines if the MTAS Extended ST feature tagging capability is to be used or not.
The mtasStAllowNoFeatureTag attribute defines if empty Accept-Contact headers without feature tags are allowed or not.
3.5 No Reply Timer Configuration
The mtasStNoReplyTimer attribute specifies the no reply timer for ST AS sessions. The timer is started when 180 Ringing is received. If the timer expires before a final response is received, the call is rejected.
3.6 Access Control Profile Configuration
The MtasStControlAccessProfile MO represents a set of properties describing certain behavior for handling of PBX routes.
3.6.1 PBX Route Error Definition
The mtasStControlAccessProfileErrorCodes attribute defines a list of final SIP response codes that is to be interpreted as an indication of a permanent error on a PBX route. If a PBX Terminating call is rejected with a response code that is included in the list, the route selected for the call is forced into the Error Guard state.
3.6.2 PBX Route Error Guard Timer
The mtasStControlAccessProfileErrorGuard attribute specifies the value of the Error Guard timer. The Error Guard timer is started when a route enters the Error Guard state and upon timer expiry, the route enters the Ready state.
3.6.3 PBX Route Out of Order Timer
The mtasStControlAccessProfileTimeout attribute specifies how long in milliseconds ST AS waits for a provisional or final response after sending an initial request towards a terminating PBX User, before it decides that a PBX route is out of order and forced into the Error Guard state. If the timer value is set to 0, the timer is not used.
3.6.4 ST SIP Port Configuration
It is possible to change the SIP port used for SIP Trunking Traffic in ST AS.
For configuration of the ST SIP port, refer to MTAS SIP Management Guide.
4 Fault Management
For alarms related to the Connection and Control services in ST AS, refer to MTAS Alarm List.