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.
|
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.
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.
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.
