There is a case for one Telepathy channel replacing another, where the client should make an effort to hide the transition from the user. The channels don't necessary belong to the same connection, or even the same connection manager. Thus staking a claim for the handover extension. It's not required at the moment that the "dying" channel needs to signal a future handover, so that it can close and the client should anticipate a new channel. The new channel can always be created while the handed over channel exists.
Can we cheat and use Conference.InitialChannels for this? We could tweak that property to say that the channels might not necessarily be on the same connection... and you can determine the actual connection from the channel's object path. :o
There is another, slightly different case: fallback during call initiation. The scenario is as follows: 1. A client requests a call channel. 2. The request dispatcher requests the channel from the most suitable connection on connection manager #1 chosen accordingly to some logic (more on that later). 3. The CM#1 tries to establish the call, but meets a condition telling it that the call is better made using a different connection. It signals call disconnection with a (detailed) error indicating this condition. 4. The request dispatcher continues with the logic from step 2 and chooses another connection on CM#2, also suitable for the call request. 5. The handler client tries to make sense of it all, getting either both or only the second of the channels to handle as the call depending on how we decide to represent this case. To allow this, we may need to: - Allow channel request semantics by which the handler will only get the eventually successful channel. It is not yet clear at which point a channel can be considered successful and past the possibility for failover. - Allow the handover property for the successor channel to be requestable, so the UIs can treat it the same way as channel handovers initiated by protocol.
A correction to the original case: we cannot tell what channel do we hand over, and we don't need it. It's supposed to be _the_ active channel on its protocol. Also, the connection of the original channel is forcibly disconnected before the handover can proceed. So the CM of the original channel needs to be internally aware of the handover taking place, in order to not close the channel with an error like it normally would. Given the above, it makes sense to have handover signalling on the first channel too. The client semantics of matching the original channel with its successor need to allow vagueness like, "wait for the next new channel of protocol X with Handover.TakesOverProtocol property bearing the protocol name of the original channel".
There are few more potential cases where handover may be more practical than implementing each heterogeneous protocol pair in one CM. Google Voice ------------ An HTTP request is issued to the service to establish an outbound call. The service makes a VoIP call to the destination, then makes a telephony call (or in likely future, a SIP call, or a Jingle call) to the initiator to complete the call "circuit". Handover-aware implementation: Instead of adding Google Voice request support to three CMs for possible call landing protocols, there could be one CM that does the Google Voice setup and then hands over to the landing CM, signalling the client to expect an incoming channel with certain properties as a continuation. Handover-unaware client behavior: The outbound Google Voice call quickly ends, but an incoming call soon follows. This would suck in a handset without head proximity detection, but presumably handset vendors that integrate Google Voice will ensure that the call client can handle it properly. Enterprise VoIP with cellular call fallback ------------------------------------------- A company or a service provider offers a mobile VoIP service with a feature that calls can be seamlessly resumed as cellular calls when the user leaves a WLAN network ("seamlessly" here mostly means that the users need not care about billing issues; from the signalling and media perspective, the two calls are completely separate). Handover-aware implementation: The client at the caller gets properties to request a continuation channel in case when the original channel/connection goes down due to loss of network connectivity. The client at the callee side can expect and quickly handle an incoming channel with certain identifying properties. Handover-unaware client behavior: Caller: the call simply terminates without continuation. Callee: the original call terminates, the continuation call by a fallback-enabled client is received as an ordinary cellular call. SR-VCC in VoLTE --------------- 3GPP IMS specifications describe continuity scenarios where an IMS packed-switched call session can be handed over to a CS call when the cellular network dictates a downgrade to 2G/3G. Handover-aware implementation: unlike the VoIP->CS fallback case, it can be driven by events from the cellular modem, so there is no need to make a channel request. Like with Google Voice, a signal to expect a channel with particular properties can be used.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/69.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.