Frequently Asked Questions - Provisioning Services


What information do I need to provision for an Application Server?

Obviously you need to fill in the SIP URI of the Application Server. You can use of course parameters, ports, etc.

Then you need to specify what should the S-CSCF do if this Application Server fails to respond to messages. You can indicate that you want the sessions to be terminated or continued based on how critical is your Application Server in your system.

Because almost any SIP server/proxy/user-agent can act as an Application Servers and they can be trusted, semi-trusted or completely untrusted, you need to also configure what is that Application Server allowed to do when communicating directly with the HSS, on the Sh interface.

Only because you have configured an AS in the HSS, it does not mean that signaling will be redirected towards it. You need to:
- attach this Application Server to one or more Initial Filter Criteria (which contain the message matching rules in the Trigger Points),
- then add the Initial Filter Criteria to a Service Profile,
- then make sure that your users have the right Service Profiles attached.

What is a Service Profile?

A Service Profile is a group of Initial Filter Criteria, each with an attached priority. Each user can have such a Service Profile attached and this is downloaded from the HSS to the S-CSCF on initial registration, profile changes or when there is a message towards a user that has a Service Profile containing at least an Initial Filter Criteria applicable for the terminating towards unregistered user case.

The Initial Filter Criteria will be evaluated for each initial request in the priority order. On a match, the request is forwarded to the respective Application Server. If the Application Server responds with a final response, that response is relayed back and the matching session is terminated. If the Application Server responds with a modified request (proxy mode), the matching session is resumed. When the matching session ends the message will be forwarded further.

Are there any Subsequent Filter Criteria?

No, there is no such thing. Subsequent requests can not be filtered or forwarded towards Application Servers.

If you have an Application Server that needs to receive subsequent requests (like a Online-Charging-Proxy), then you should filter the initial request for that dialog and have the Application Server Record-Route.

What is an Initial Filter Criteria?

The Initial Filter Criteria is the grouping between a Trigger Point (the logical expression matching a message) and an Application Server. The absence of a Trigger Point in an Initial Filter Criteria indicates that the message should always be forwarded to the respective Application Server.

The Initial Filter Criteria can only match Initial Requests, like INVITE, REGISTER, SUBSCRIBE, MESSAGE, etc. Subsequent messages (like BYE, NOTIFY, INVITE inside a dialog, etc) are not checked or forwarded.

Each Initial Filter Criteria can be set to match only when the respective user on which it is set is registered or unregistered or in both cases.

What is a Trigger Point (TP)?

A Trigger Point is a logical expression of Service Point Triggers. It is composed of groups and each group is formed of the logical atoms, the SPT. It can be of 2 types, based on what logical condition is applied inside the groups and between them:

  1. Conjunctive Normal Format (CNF) - (A or B) and (C) and (D or E or F)
  2. Disjunctive Normal Forma (DNF) - (A and B) or (C) or (D and E and F)

The Trigger Point is used to build complex message matching conditions.

What is a Service-Point-Trigger (SPT)?

The Service-Point-Trigger is the smallest logical atom in the Trigger Point. There are 5 distinct types of SPTs, based on what each of them is used to check in the SIP message:

  1. Request-URI equals <value>
  2. SIP Method equals <value>
  3. SIP Header matches <regular expression>
  4. Session Case is one of [originating, terminating, terminating to unregistered user]
  5. SDP Line [<line name>] matches <regular expression>

The result of each SPT can be negated, as required. Also it could be specified to each SPT if it applies to the Initial/Re/De-Registration when checking a REGISTER message for triggering a 3rd Party Registration.

The SIP Header SPT can be used to also test the absence of a header by negating it and omitting the regular expression.