This page contains example call flows showing how calls to the primary device’s IMPU are forked to both primary and companion devices under various configurations.

Note

These call flows just show the path of the initial INVITE request up to when it is forked. From that point all scenarios would be identical to typical forking scenarios, so these parts have been omitted as they do not convey any new information.

Example with +sip.instance routing disabled

In this flow, T-ADS is configured with EnableSipInstanceRouting = false. This means that for the PS leg, T-ADS will forward the INVITE normally to the S-CSCF. The S-CSCF sees that there are multiple registrations for the user, so forks the INVITE to both devices.

CS and PS with +sip.instance routing disabled

companion-cs-and-ps-simple

Example with +sip.instance routing enabled

In this flow, T-ADS is configured with EnableSipInstanceRouting = true. This means that T-ADS will perform the forking itself, and create separate PS legs towards each registered device. The Request-Disposition: no-fork header is added to the outbound INVITEs so that downstream nodes do not attempt to fork.

CS and PS with +sip.instance routing enabled

companion-cs-and-ps-enhanced

Example with +sip.instance routing enabled and Voice Over PS support required

In this flow, T-ADS is configured with EnableSipInstanceRouting = true and VoiceOverPSSupportRequired = true. This means that T-ADS will perform the forking itself, but will only create an outbound PS leg if the HSS can detect that the device is currently attached to the PS network. The Request-Disposition: no-fork header is added to the outbound INVITEs so that downstream nodes do not attempt to fork.

PS with +sip.instance routing enabled and Voice Over PS support required

companion-ps-enhanced-vops

Previous page