The R-IM-SSF may also be triggered by an incoming INVITE request from the SIP network when a SIP-AS wishes to create a network initiated call in the IN.

Note In order to establish a network initiated call, an IN protocol that supports such calls is required. Currently the only protocol supporting these types of calls that is also supported by the R-IM-SSF is Ericsson INAP CS1+.

Identifying a network initiated call

A SIP-AS uses the principles specified in RFC 4579 s5.4 (Creating a Conference Using Ad-Hoc SIP Methods) to create a new network initiated call attempt in the IN. In order to identify an INVITE request that represents a new network initiated call attempt, the INVITE from the SIP-AS must contain a Request-URI that:

  • is a SIP URI

  • specifies a user of conference-factory

  • contains the URI parameter oc-rimssf=conference.

The To header in the initial INVITE should identify the phone number of the first call party.

When the first call party answers the call, the R-IM-SSF will respond to the INVITE with a 200 OK. The Contact URI contained in this 200 OK identifies the call to the SIP-AS and must be used by the SIP-AS as the Request-URI or topmost Route header (when received by the R-IM-SSF) in subsequent INVITE requests that add further participants to the call. The To header in subsequent INVITE requests should again identify the phone number of the party to be added to the call.

Triggering the R-IM-SSF

The R-IM-SSF can be triggered in the SIS for a SIP network initiated call by checking for the presence of the required conference URI. For example, the following condition could be used in a SIS trigger to select a composition that invokes the R-IM-SSF for such a call:

<on-condition>
  <and>
    <equal a="${uri.user}" b="conference-factory"/>
    <equal a="${uri.param.oc-rimssf}" b="conference"/>
  </and>
</on-condition>
Tip R-IM-SSF install packages that include support for IN protocols that support network initiated calls include an example SIS trigger and composition that can be used to invoke the R-IM-SSF for a SIP network initiated call.

Find the MSC

The R-IM-SSF general configuration includes a setting for the default MSC address (as an SCCP address) to use for network initiated calls. The R-IM-SSF provides the capability to override this default address on a per call basis using a SIS interceptor.

Once the interceptor completes (if relevant), the R-IM-SSF uses the final determined SCCP address as the destination address for a new outgoing IN dialog. The R-IM-SSF then builds the InitiateCallAttempt to send on this dialog.

Warning The R-IM-SSF rejects the call with a 500 Internal Server Error response if a valid MSC address cannot be determined. This can happen if no default MSC address is configured and an interceptor does not provide a suitable value.

Build the InitiateCallAttempt

The R-IM-SSF uses information from the incoming INVITE to populate the fields of the InitiateCallAttempt request it sends to the MSC.

Field Source Description 
  DestinationRoutingAddress
 
  Request-URI

The Request-URI must contain a numerical address. This address is used to determine the destination address.

 
  CallingPartyNumber
 
  From

The From header must also contain a numerical address. This address is used to determine the calling party number.

 
  LegToBeCreated

n/a

The first leg created has a leg id of 1. This value is incremented by one for each subsequent leg.

When converting a SIP URI address to an IN data value, the final address will have a format based on the international dialling prefix and country code settings provisioned in the general configuration.

Before sending the InitiateCallAttempt message, the R-IM-SSF invokes a SIS interceptor allowing additional fields to be populated in the message.

Once the InitiateCallAttempt has been sent to the MSC and routing of the new call begins, the R-IM-SSF sends a 183 Session Progress provisional response to the INVITE back to the SIP-AS.

Example R-IM-SSF configuration …​ Example INVITE …​ …​ results in 
 IddPrefix
 
 00
 
 CountryCode
 
 64
 
INVITE sip:conference-factory@rimssf.opencloud.com;oc-rimssf=conference SIP/2.0
From: <tel:+64219999999>;tag=MEuBTA
To: <tel:+64211234567>
Call-ID: XuCsVFJjoGKZF7oECrJDtg
CSeq: 0 INVITE
Max-Forwards: 70
...
 
InitiateCallAttempt[
  destinationRoutingAddress
    {
      calledPartyNumber
        nature NATIONAL
        routingToInternalNetworkNumber ALLOWED
        numberingPlan ISDN
        address "211234567"
    }
  callingPartyNumber
    nature NATIONAL
    numberIncomplete false
    numberingPlan ISDN
    presentation ALLOWED
    screening NETWORK_PROVIDED
    address "219999999"
  legToBeCreated
    sendingSideID
      encodedValue CALLING_PARTY
]

Typical call flow

For a call initiated by the SIP network, this is a typical call flow.

  1. An INVITE from SIP-AS initiates the call.

  2. R-IM-SSF creates the new call in the IN network,using InitiateCallAttempt to contact the A-party.

  3. The A-party answers; R-IM-SSF informs SIP-AS.

  4. SIP-AS sends a second INVITE for the B-party.

  5. R-IM-SSF routes the call to the B-party.

  6. The B-party answers; R-IM-SSF informs SIP-AS.

Once the A-party has answered the call and the SIP-AS has been notified, the call progresses in the same way as if the A-party had initiated the call in the IN and the R-IM-SSF had been triggered for that call by an InitialDP.

Previous page Next page