This page describes the steps to enable companion device. For more detailed information on Companion Device refer to the architecture section.

Note

Part of the enabling process involves turning on a second query to the HSS to check if the serving subscriber is a companion device. This query takes place for orig, orig-cdiv, and term sescase calls. This can not be turned on per subscriber.

Enable HSS Metaswitch-TAS-Services query

The Metaswitch-TAS-Services document is read by the MMTel SubscriberDataLookupFromHSS feature. If companion device information is present, it is saved in session state for use by subsequent features.

Enable query

rhino-console> setprofileattributes Operator_SubscriberDataLookupFromHss2ServiceIndicationProfileTable Metaswitch-TAS-Services DisableQuery false

Disable query

rhino-console> setprofileattributes Operator_SubscriberDataLookupFromHss2ServiceIndicationProfileTable Metaswitch-TAS-Services DisableQuery true
Note

If the subscriber does not have a Metaswitch-TAS-Services document, or the document’s companion device section is empty, then the call proceeds normally with no special companion device behaviour.

Companion Device Feature Configuration

Companion Device related features are accessed from the REM Group Feature configuration page. These include Companion Device specific fields and other configuration that is related. To access the features.

  • Select Sentinel from the main menu

  • Select Feature Configuration to bring up Group Feature configuration page

  • From the Group list select Companion Device Support.

For further information on the features listed, refer to.

1

Select Determine Shared and Undisclosed Identities Feature

2

To enable hiding of the undisclosed identity when the Companion Device makes a call and blocking calls to the undisclosed identity.

Select Hide and Block Undisclosed Identities?
companion determine shared undisclosed

3

Click the Save button at the lower right.

1

Select Hide Undisclosed Identity Feature

2

This extra step is needed when hiding undisclosed identities.

Select Hide Undisclosed Identities?

companion hide undisclosed identity

3

Click the Save button at the lower right.

1

Select SCC TADS Data Look Up

2

The SCCTADSDataLookup feature determine PS and CS routes.

The attribute Sip Instance Routing instructs T-ADS to fork the INVITE towards the available PS contact addresses, including the companion device, if any.

The attribute Companion Sip Instance Routing instructs T-ADS to automatically perform forking to all available PS contacts, if the call is to a subscriber with Companion Devices. This will override the Sip Instance Routing attribute.

Select Enable Sip Instance Routing?

Select Enable Companion Sip Instance Routing?

companion scc tads data lookup

3

Click the Save button at the lower right.

1

Select Strip Preconditions

2

Enabling Strip Preconditions is required in deployments with Metaswitch Perimeta and where downstream forking is expected to occur. In this scenario if multiple forked 1xx responses are forwarded upstream, the upstream Perimeta will combine them into a single dialog for the calling UE. This means the UE cannot send UPDATEs on each forked dialog to complete precondition negotiations.

To avoid this issue preconditions must be removed from the outgoing initial INVITE.

Select Strip Preconditions

companion strip preconditions

3

Click the Save button at the lower right.

UsePathForSipInstanceRouting

For devices that don’t include a GRUU inside Contact headers, the Path information from the REGISTER can be used for routing.

Enable UsePathForSipInstanceRouting

    rhino-console> setprofileattributes SCCTADSDataLookUpConfigProfileTable Operator:::: UsePathForSipInstanceRouting true

Disable UsePathForSipInstanceRouting

    rhino-console> setprofileattributes SCCTADSDataLookUpConfigProfileTable Operator:::: UsePathForSipInstanceRouting false

Busy Behaviour

T-ADS can optionally terminate all forked legs when the first 486 (Busy Here) response arrives from any device. This means if multiple devices are alerting, and one device declines the call, then all devices will stop alerting as well. For more information refer to SCCTADSParallelRouting feature.

Enable ReleaseAllLegsOnBusy

rhino-console> setprofileattributes SCCTADSParallelRoutingConfigProfileTable Operator:::: ReleaseAllLegsOnBusy true

Provision Subscribers with Companion Device

Companion Device information is stored in the subscriber’s Metaswitch-TAS-Services document in the HSS. REM can be used to add Companion Devices into the transparent data for the IMS public identities for both the Primary and Companion Devices. In other words the Primary and Companion devices use the same transparent data. This requires that the HSS supports Alias Public User Identity Set.

Note

Configuration of the Metaswitch-TAS-Services document and subsequent query to the HSS is outside the scope of this document. Please refer to your HSS vendor documentation.

Example Configuration

In this example, the called party has a Metaswitch-TAS-Services document that indicates they have a companion device with CS support, by the presence of the device/radio-access/CS element as shown in the XML fragment below:

<metaswitch-services xmlns="http://metaswitch.com/XMLSchema/tas">
  <complete-companion-device>
    <operator-companion-device authorized="true">
      <shared-identity-sip>sip:+641234567@example.com</shared-identity-sip>
      <shared-identity-tel>tel:+641234567</shared-identity-tel>
      <devices>
        <device active="true">
          <model>Acme Watch</model>
          <radio-access>
            <PS/>
            <CS msisdn="641234568"/>
          </radio-access>
        </device>
      </devices>
    </operator-companion-device>
  </complete-companion-device>
</metaswitch-services>
Previous page Next page
Sentinel VoLTE Version 3.1.0