Version 3.0.0 of Sentinel VoLTE adds experimental support for companion devices.
Companion devices are VoLTE UEs that are linked to a primary device such as a smart phone. Smart watches are a common type of companion device.
Sentinel VoLTE’s companion device support enables primary and companion devices to share one phone number, that of the primary device:
A call to the shared number will alert both devices in parallel.
Calls from the companion device will appear to originate from the shared number.
This type of service is sometimes referred to as "One Number", "Multi-SIM" or "Multi-Device".
- Overview of Operation
- Provisioning Companion Devices
- MMTel Procedures
- SCC T-ADS Procedures
- Stripping Preconditions
Companion device behaviour is enabled for a subscriber when the operator provisions companion device information
in the subscriber’s
Metaswitch-TAS-Services document in HSS transparent data.
See Provisioning Companion Devices below.
Metaswitch-TAS-Services document is read by the MMTel
If companion device information is present, it is saved in session state for use by subsequent features.
Originating call attempts from the companion device require no special treatment in Sentinel VoLTE. It is assumed the companion device uses the public identity of the primary device, as it is in the same implicit registration set (see Requirements of the Companion Device below).
If the terminating MMTel-AS instance finds companion device information in the called parties'
then it is encoded in a SIP header (
X-Msw-Companion-Device) on the INVITE request, and forwarded downstream.
This triggers additional behaviour in the terminating SCC-AS.
The terminating SCC-AS instance checks for the
X-Msw-Companion-Device header, and if present, overrides the T-ADS routing mode to be "parallel".
This means that all registered devices for the called party are alerted simultaneously, using SIP forking.
This also includes the primary device even if it is using 3G/CS radio.
The subscriber may answer the call using the primary or companion device, and the other forked legs are automatically cancelled.
The companion device must be a 4G VoLTE/VoWifi-capable UE.
It will use the same IMS subscription and service profile as the primary device.
It may register its own IMS public identities.
These identities should be barred, but in the same implicit registration set as the primary device’s identities.
This means the default public identity for the companion device will be the same as the primary device.
Only 4G (VoLTE/VoWifi) companion devices are supported in this release. Devices using 3G radio access will be supported in a future release.
A subscriber’s companion device information must be provisioned in HSS transparent data, using the
Metaswitch-TAS-Services service indication.
The document’s XML schema is shown in the
Below is an example XML fragment showing that the user has a companion device capable of PS radio (VoLTE/VoWifi), which is currently the only supported type of companion device.
<metaswitch-services xmlns="http://metaswitch.com/XMLSchema/tas"> ... <complete-companion-device> <operator-companion-device authorized="true"> <radio-access> <network>PS</network> </radio-access> </operator-companion-device> </complete-companion-device> ... </metaswitch-services>
This information can be provisioned manually using the REM HSS Transparent Data Editor.
If the selected charging mode is Diameter Ro/Rf, there is no impact on charging when a companion device is in use. The calling and called party numbers are those of the primary device.
If CAMEL online charging is used via the IM-SSF service, and the SCC T-ADS forks an INVITE creating multiple outbound legs, then an IM-SSF service instance (and SCP dialog) is created for each outbound leg. Only one leg will be answered, and CAMEL charging will be performed as usual for that leg. The unused legs will terminate, and record zero-length calls on their SCP dialogs.
The terminating MMTel instance’s
feature reads the
Metaswitch-TAS-Services document from HSS transparent data.
If companion device information is found, this is added to session state.
SetCompanionDeviceHeaders feature adds the
X-Msw-Companion-Device header to the outgoing INVITE.
This header will be used in the terminating SCC-AS instance to trigger companion device behaviour.
If the INVITE is retargeted by the MMTel-AS, then the
X-Msw-Companion-Device header is automatically removed.
This is because the terminating subscriber has changed, and the TAS does not know if the new subscriber has a companion device.
The INVITE will return to the S-CSCF, which will trigger a new terminating MMTel instance if necessary.
When the new terminating MMTel instance runs, SubscriberDataLookupFromHSS will read
Metaswitch-TAS-Services for the new subscriber.
The terminating SCC instance’s SCCTADSDataLookup
feature checks for the
If found, then the T-ADS routing mode is set to "parallel", overriding the configured default routing mode.
This means the
feature will be used to send the INVITE to the called party,
so that the primary and companion devices will be alerted simultaneously.
This includes the primary device whether it is attached to a CS or PS access network.
Companion devices are currently only supported on PS access networks.
Companion devices on CS networks will be supported in a future release.
If the companion device is registered then it will automatically be included in the determination of outbound routes. If a CSRN can be determined then T-ADS will automatically fork to the CS network. This means the primary device will be alerted if it is currently attached to CS.
If T-ADS is configured with
EnableSipInstanceRouting = true, then it will fork the INVITE
towards the available PS contact addresses, including the companion device, if any.
EnableSipInstanceRouting = false then T-ADS will create a single outbould PS leg,
and let the S-CSCF perform the forking to all available PS contacts,
which will include the companion device if it has registered with the S-CSCF.
If configured with
VoiceOverPSSupportRequired = true, then before determining the outbound PS routes,
T-ADS will query the HSS
T-ADS Information data reference to confirm that the subscriber is currently
attached to the PS network.
More information about how outbound CS and PS routes are determined can be found in the SCCTADSDataLookup feature documentation.
If a companion device is in use, then SIP forking is more likely to occur. SIP forking may cause issues with upstream devices that cannot properly handle preconditions negotiation on multiple early dialogs. If this is a problem, then this can be worked around by enabling the StripPreconditions feature.