Bug 15562 (SessionHandles)

Summary: Using handle to represent temporary contacts valid during session
Product: Telepathy Reporter: Pekka Pessi <ppessi+telepathy>
Component: tp-specAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED MOVED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Pekka Pessi 2008-04-17 03:40:55 UTC
SIP has concept of forking, where a request for a public ID such as <sip:pekka.pessi@example.com> can be routed to several user-agents. A SIP session can be formed with any of those user-agents, and there might be multiple sessions active with the same public user ID but different user-agent.

The SIP user-agent identifies itself with a contact URI. The contact URI can be public ID, too, known as globally routable user-agent uri (gruu), or it can be private and reachable only through the original session.

The current Contact Handle semantics do not suit handling user-agent contacts. It is a bit like channel-specific handle, meaning that it has Owner (the public identity for human consumption), but it is usable outside the channel, for instance, when sending text MESSAGEs to the particular SIP user-agent with which you have a StreamedMedia channel.
Comment 1 Mikhail Zabaluev 2008-04-17 04:31:13 UTC
I think there's a synergy to be exploited with XMPP resource IDs as well.
What if we have a generic interface where it's possible to retrieve zero or more "UA handles" associated with the regular "address handle". Then, some use cases can make use of the UA handles for precise addressing. There might be also a notion of the default UA handle per address handle, selectable by the client, while addressing should still be limited to address handles to hide implementation differences.

I think it can also solve part of the problem with aliasing in SIP text channels implemented with MESSAGE requests (however, if cross-request Call-ID is not maintained, we have no means to track the aliases).
Comment 2 Simon McVittie 2008-04-17 04:41:34 UTC
This seems quite subtle, and not something we want to rush into!

When the "improved RequestChannel API" has landed, we'd like to be able to support XMPP thread IDs, which I think have similar use cases. I'd somewhat prefer to represent related conversations/messages/channels as "part of the same thread" rather than having some sort of "sub-contact" concept.

So, instead of sending a MESSAGE to the channel-specific-handle for "Pekka as he appears in this particular call", it might be better if the UI opened a text channel that was somehow marked as related to the call, or had the same thread UUID as the call, or something; then the connection manager could deal with the nasty behind-the-scenes stuff in whatever way it thinks best. Perhaps this would imply that the text channel stopped working when the call closed; that's fine, it was "related" anyway.

Channel-specific handles are a necessary evil in XMPP because it's possible to have contacts in a multi-user chat whose identity outside the MUC is not visible. I'd rather avoid polluting other implementations with CSHs if we can help it - they're a real pain to deal with!

In XMPP it is in fact possible to have a private conversation with a contact in a MUC whose identity you don't know - in Gabble you open a text channel to their channel-specific handle, which will stop working if you or they leave the MUC.
Comment 3 Pekka Pessi 2008-04-17 08:23:12 UTC
So technically the SIP session/dialog semantics would map closest to Telepathy if the Remote handle in StreamedMedia channel get always converted to a channel-specific handle? While the session is active,the channel-specific handle could be used to set up a text channel.

That is an solution, but if you don't like channel-specific handles, perhaps there should be another interface for providing session-specific handle only when needed?
Comment 4 GitLab Migration User 2019-12-03 20:17:18 UTC
-- 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/9.

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.