[Standards] XEP-0301 Session handling
Gunnar Hellström
For example if you are gatewaying to a SIP call, and want to cause a hangup on the SIP side, or get an indication to the XMPP side when the SIP side has closed the session.
Question:
I wonder if there is a session start - session end indication that has dominating support among XMPP text messaging implementations that can be used as the default mechanism for XEP-0301 real-time text session control.
Right now in XEP-0301, there is an "start" event and a "cancel" event defined in section 4.2.3 with indications that they MAY be used to indicate session start and end.
See http://xmpp.org/extensions/xep-0301.html
I have found some other mechanisms, and I wonder if the "start" and "cancel" events should be deleted from XEP-0301, and instead some already existing mechanism used, in order to not increase the number of optional ways to handle session start and end.
It seems to me that there is a basic mechanism for session control defined in RFC 6121 section 5.1
Initiation of a session should begin with a message with type=chat,
Both parties shall set their presence <show/> to "chat"
End of session should be signaled by indicating directed presence "unavailable".
A change of <show/> to anything else than chat should also be taken as indication of end of session.
An example is presented in section 7 of RFC 6121.
I assume that there are a multitude of exceptions when this sequence does not occur, but it seems to me to be a good basic sequence to support.
On top of that, there seems to be a range of more comprehensive session control options:
-XEP-0166 Jingle session establishment.
-XEP-0155 Session establishment
-XEP-0045 Multi-User Chat ( that also uses directed "unavailable" presence for closing the session as the main method above.)
Proposal:
So, for XEP-0301, I want to check if it would be wise to delete the "start" and "cancel" events from chapter 4.2.3 and instead insert a new subsection in chapter 6 saying:
"6.4 Session control
Session control is essentially out of scope for this media related extension.
A recommendation is though to follow the basic principles described in RFC 6121 section 5.1.
Any further session handling such as Jingle, MUC or the Session establishment extension may be added as found suitable for each specific application of this extension."
-- ___________________________________________________ Gunnar Hellström Omnitor gunnar.h...@omnitor.se +46708204288
Peter Saint-Andre
On 2/28/12 4:07 PM, Gunnar Hellström wrote:
> Sometimes it is very helpful with a clear beginning and a clear end of
> an XMPP text session.
Some people have thought so in the past:
http://xmpp.org/extensions/xep-0155.html
That was mainly developed for the purpose of end-to-end encryption
(XEP-0116). Personally I think it would be good to deprecate it.
> For example if you are gatewaying to a SIP call, and want to cause a
> hangup on the SIP side, or get an indication to the XMPP side when the
> SIP side has closed the session.
We have Jingle for multimedia session management. We could use it for
managing a text session, although personally I think that's overkill.
> *
> Question*:
> I wonder if there is a session start - session end indication that has
> dominating support among XMPP text messaging implementations that can be
> used as the default mechanism for XEP-0301 real-time text session control.
http://xmpp.org/extensions/xep-0085.html might be most appropriate.
>
> Right now in XEP-0301, there is an "start" event and a "cancel" event
> defined in section 4.2.3 with indications that they MAY be used to
> indicate session start and end.
> See http://xmpp.org/extensions/xep-0301.html
>
> I have found some other mechanisms, and I wonder if the "start" and
> "cancel" events should be deleted from XEP-0301, and instead some
> already existing mechanism used, in order to not increase the number of
> optional ways to handle session start and end.
Probably a good idea.
> It seems to me that there is a basic mechanism for session control
> defined in RFC 6121 section 5.1
> Initiation of a session should begin with a message with type=chat,
> Both parties shall set their presence <show/> to "chat"
> End of session should be signaled by indicating directed presence
> "unavailable".
> A change of <show/> to anything else than chat should also be taken as
> indication of end of session.
> An example is presented in section 7 of RFC 6121.
I think XEP-0085 (Chat State Notifications) is more relevant. I don't
think it would be good to overload <show/> states because those are
related to presence in general, not a particular chat session.
> I assume that there are a multitude of exceptions when this sequence
> does not occur, but it seems to me to be a good basic sequence to support.
>
> On top of that, there seems to be a range of more comprehensive session
> control options:
> -XEP-0166 Jingle session establishment.
If we want formal session management for RTT sessions then I think
Jingle is the way to go, but I am not convinced that we need formal
session management.
> -XEP-0155 Session establishment
I think we should deprecate that.
> -XEP-0045 Multi-User Chat ( that also uses directed "unavailable"
> presence for closing the session as the main method above.)
MUC is multi-user, not one-to-one, so I think it's not general enough
for use in RTT.
> *
> Proposal:*
> So, for XEP-0301, I want to check if it would be wise to delete the
> "start" and "cancel" events from chapter 4.2.3 and instead insert a new
> subsection in chapter 6 saying:
>
> "6.4 Session control
> Session control is essentially out of scope for this media related
> extension.
> A recommendation is though to follow the basic principles described in
> RFC 6121 section 5.1.
> Any further session handling such as Jingle, MUC or the Session
> establishment extension may be added as found suitable for each specific
> application of this extension."
My primary question is: do we need formal management of RTT sessions? I
don't think we do, and I think we can handle them informally using a
combination of RFC 6121 and XEP-0085. However, if we really really need
formal management then I would suggest using Jingle.
Peter
--
Peter Saint-Andre
https://stpeter.im/
Mark Rejhon
Sometimes it is very helpful with a clear beginning and a clear end of an XMPP text session.
For example if you are gatewaying to a SIP call, and want to cause a hangup on the SIP side, or get an indication to the XMPP side when the SIP side has closed the session.
Question:
I wonder if there is a session start - session end indication that has dominating support among XMPP text messaging implementations that can be used as the default mechanism for XEP-0301 real-time text session control.
Alice messages Bob. Alice enables real-time text by clicking a button.
Mark Rejhon
Peter Saint-Andre
> I'm interested in feedback about session negotiation techniques, and
> about simplifying XEP-0301 by removing the start/cancel attributes
> (which are OPTIONAL) which are actually not currently used in any of the
> several XEP-0301 implementations I have seen, including the latest
> version of RealJabber (software installer package now available at
> www.realjabber.org <http://www.realjabber.org> ...)
>
> I also need to define a mechanism where both sides of a XEP-0301
> compliant client can negotiate the simultaneous enabling of real-time
> text on both sides, on an example mainstream client that might have RTT
> disabled by default. For example, it should be possible for software
> vendors to add an activation button for real-time text -- like there's
> already a button for audio or video in many popular IM clients. One
> technical method behind the scenes is to use the
> event=start/event=cancel , but a different method is to also
> automatically prompt to send return RTT if it detects incoming RTT.
>
> *Use Case Example #1:*
> Alice messages Bob. Alice enables real-time text by clicking a button.
> On Bob machine, when his software receives an <rtt> element for the
> first time, the software can prompt Bob to enable the real-time text
> feature, as follows:
> /**** Alice is now sending real-time text. Click [Accept] to transmit
> your typing live too./
>
> *Use Case Example #2:*
> Alice messages Bob. Alice enables real-time text by clicking a button.
> Bob's IM client is preconfigured to automatically accept real-time text.
> Upon receiving Alice's real-time text in <rtt>, Bob automatically
> enables sending of <rtt>. A notification message simply gets displayed
> in the message history:
> *** /Alice has activated real-time text. / /Your typing is now being
> transmitted live./
>
> If this method is done, then it is not necessary to worry about using
> the event='start' / event='cancel' for the purposes of RTT-specific
> session signalling, and I can just remove it from XEP-0301 to simplify.
> Also, it is noted that XEP-0301 section 5 already provides a mechanism
> for a client to detect whether the remote client has RTT support, before
> transmitting outgoing unsolicited <rtt>.
Mark, the model you're searching for is what we use in XEP-0085. Please
take a look at the text there and see if you can re-use it for RTT.
Mark Rejhon
On 2/28/12 4:47 PM, Mark Rejhon wrote:
[snip]
> *Use Case Example #1:*
> Alice messages Bob. Alice enables real-time text by clicking a button.
> On Bob machine, when his software receives an <rtt> element for the
> first time, the software can prompt Bob to enable the real-time text
> feature, as follows:
> /**** Alice is now sending real-time text. Click [Accept] to transmit
> your typing live too./
>
> *Use Case Example #2:*
> Alice messages Bob. Alice enables real-time text by clicking a button.
> Bob's IM client is preconfigured to automatically accept real-time text.
> Upon receiving Alice's real-time text in <rtt>, Bob automatically
> enables sending of <rtt>. A notification message simply gets displayed
> in the message history:
> *** /Alice has activated real-time text. / /Your typing is now being
> transmitted live./
>
> If this method is done, then it is not necessary to worry about using
> the event='start' / event='cancel' for the purposes of RTT-specific
> session signalling, and I can just remove it from XEP-0301 to simplify.
> Also, it is noted that XEP-0301 section 5 already provides a mechanism
> for a client to detect whether the remote client has RTT support, before
> transmitting outgoing unsolicited <rtt>.
[snip]
Mark, the model you're searching for is what we use in XEP-0085. Please
take a look at the text there and see if you can re-use it for RTT.
Mark Rejhon
[Answered] Matter of Simplifying XEP-0305 by removing its session signalling
Peter Saint-Andre
> XEP-0085, if used, is very easily complementary with RTT. You just
> simply send <composing/> with the first <rtt/> element transmitted from
> any other state (i.e. <active/> or <paused/>) .... I should add a
> sentence about this general practice.
>
> signalling*
> XEP-0085 can easily justify the removal of the *event='start'* and
> *event='cancel'*
> *
> *
> *[To Discuss] Matter of negotiation of activation of RTT feature*
> /However/, XEP-0085 doesn't answer the question of an appropriate
> negotiation model for deciding whether or not to enable RTT for a chat
> session. (RTT is most ideal when both ends enable it) Peter, do you
> think that my use case examples seem appropriate behaviour?
>
> Comments would be appreciated about this.
I'm suggesting that you use a model similar to XEP-0085 -- if the other
side advertises it (disco/caps), send the first message with some kind
of RTT element. If the response comes back without an RTT element, don't
include any RTT elements in subsequent messages within that conversation.
Mark Rejhon
I'm suggesting that you use a model similar to XEP-0085 -- if the other
side advertises it (disco/caps), send the first message with some kind
of RTT element. If the response comes back without an RTT element, don't
include any RTT elements in subsequent messages within that conversation.
Florian Zeitz
I tend to disagree with this. It would inherently require that both
sides do RTT. I don't see any reason to enforce this artificial
requirement. It is perfectly fine for just one side to send RTT
messages, while the other one uses normal chat messages.
If someone doesn't want to receive RTT messages, he should just not
include the feature in the disco response.
Also I see absolutely no reason for any session negotiation for this XEP
whatsoever, especially without an option for the receiving party to
decline the session. A simple on/off switch on the sending end (only
availabe when the disco feature is present) seems sufficient to me.
As a side note. What you described is actually quite different from what
XEP-0085 says. You're mixing the usual disco case with the backwards
compatibility case where no feature is present, but chat states might
still be supported.
Regards,
Florian
Peter Saint-Andre
> On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre <stp...@stpeter.im
> <mailto:stp...@stpeter.im>> wrote:
>
> I'm suggesting that you use a model similar to XEP-0085 -- if the other
> side advertises it (disco/caps), send the first message with some kind
> of RTT element. If the response comes back without an RTT element, don't
> include any RTT elements in subsequent messages within that
> conversation.
>
>
> Hello!
> This works in niche clients.
>
> However, when bringing real-time text to the mass market, it is presumed
> that vendors (i.e. Microsoft, Google) will want it to be disabled by
> default.
That's a client configuration and UI issue, not a protocol issue.
1. If the interlocutor doesn't advertise support for RTT, consider RTT
unavailable for this conversation and don't proceed to #2.
2. If the interlocutor advertises support for RTT, prompt your user
about whether to try RTT (or have some setting about "try RTT with known
contacts" or somesuch).
3. If you try RTT but the interlocutor doesn't include RTT extensions,
don't include RTT in subsequent messages.
I still don't see the need for protocol-level *negotiation* here.
However, if you are convinced that we need it, then we already have a
protocol for that: Jingle.
Peter Saint-Andre
On 2/28/12 7:42 PM, Florian Zeitz wrote:
> Am 29.02.2012 03:02, schrieb Peter Saint-Andre:
>> On 2/28/12 6:13 PM, Mark Rejhon wrote:
>>> *[To Discuss] Matter of negotiation of activation of RTT feature*
>>> /However/, XEP-0085 doesn't answer the question of an appropriate
>>> negotiation model for deciding whether or not to enable RTT for a chat
>>> session. (RTT is most ideal when both ends enable it) Peter, do you
>>> think that my use case examples seem appropriate behaviour?
>>>
>>> Comments would be appreciated about this.
>>
>> I'm suggesting that you use a model similar to XEP-0085 -- if the other
>> side advertises it (disco/caps), send the first message with some kind
>> of RTT element. If the response comes back without an RTT element, don't
>> include any RTT elements in subsequent messages within that conversation.
>>
>> Peter
>>
>
> I tend to disagree with this. It would inherently require that both
> sides do RTT.
That was the assumption behind chat state notifications. I think it's a
reasonable assumption, but I also think that reasonable people can
disagree about it.
> I don't see any reason to enforce this artificial
> requirement. It is perfectly fine for just one side to send RTT
> messages, while the other one uses normal chat messages.
> If someone doesn't want to receive RTT messages, he should just not
> include the feature in the disco response.
Sure.
> Also I see absolutely no reason for any session negotiation for this XEP
> whatsoever, especially without an option for the receiving party to
> decline the session. A simple on/off switch on the sending end (only
> availabe when the disco feature is present) seems sufficient to me.
I too agree that we don't need session negotiation.
> As a side note. What you described is actually quite different from what
> XEP-0085 says. You're mixing the usual disco case with the backwards
> compatibility case where no feature is present, but chat states might
> still be supported.
Quite possibly. :)
Mark Rejhon
That's a client configuration and UI issue, not a protocol issue.
Peter Saint-Andre
Yes, but that doesn't necessarily mean you need an explicit negotiation
protocol.
Gunnar Hellström
to indicate session start and session end.
Peter Saint-Andre skrev 2012-02-29 04:20:
> Yes, but that doesn't necessarily mean you need an explicit negotiation
> protocol.
Right. The first need I thought about can in fact be reduced to a text
session indicator, not even linked to RTT support.
I will take a scenario to make the need clear.
Assume that there is a SIP based stock exchange service, sending stock
exchange information in text in sessions. It continues as long as a
terminal is connected. A terminal indicates by a BYE that it leaves the
session, so that the server can release the resources. During the
session, the text information may be provided through RFC 4103 or RFC
3428 or RFC 4975. (RFC 4103 makes most sense of course for the RTT
example, but let us look at it in general).
Also assume that you want to make this service available to XMPP users
through a gateway.
Setting up a chat session to the gateway causes it to set up a SIP
session with the stock exchange server.
Messages or real-time text is flowing from the stock exchange server to
the XMPP client.
Then, the XMPP user want to leave the session. What does the user do and
what does the gateway use as an indication that the session is over and
it can take down the session towards the server?
The indication for setting up seems to be either the basic mechanism for
session control defined in RFC 6121 section 5.1 where it is stated that
initiation of a session should begin with a message with type=chat.
Or XEP-0085 chat state going "active"
But what is most appropriate as indication to the gateway that it is
time to take down the session on the SIP side?
The XEP-0085 chat states do not seem to be the primary means to use. The
user may sit there very actively watching the information coming, but
not touching the user interface for half an hour. According to XEP-0085,
the chat state would then be "gone" since long, so taking down the
session on "gone" indication does not seem appropriate.
How about relying on RFC 6121 section 5.1 requiring that
end of session should be signaled by indicating directed presence
"unavailable".
Will that be normally signalled by most XMPP text clients when the user
closes the window where the session was shown?
The stock exchange server example is of course artificial. There may be
many other cases when a simple session indication is important.
And this regardless of the support for and activation of the RTT
feature. So my conclusion now is that this is not at all a XEP-0301
issue, but if we get a conclusion, we could document it as a
recommendation in XEP-0301.
There are other valid cases, when full capability declaration, exchange
and negotiation or RTT capability is important, but let us take one case
at a time.
Thanks
Gunnar
Peter Saint-Andre
Hash: SHA1
I really think that if you want to gateway between SIP and XMPP, you
want to use Jingle. Such gatewaying was one of the core considerations
for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we
can certainly write a spec that defines how to translate between
XEP-0301 and RFC 4103 (e.g., how to translate the SDP). Personally I
don't think we absolutely need a way to complete a formal negotiation
over XMPP itself, because I tend to think that just sending a chat
message is a much more natural interaction, but *if* we think we need
such a negotiation method, we should just use Jingle.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9OcRQACgkQNL8k5A2w/vzgqwCgiBcvV337uC0aDPVQ0zJ2zY+x
dGsAoKhCEcelqsbgJFE5fF1trjKBFkPU
=NhyO
-----END PGP SIGNATURE-----
Gunnar Hellström
> I really think that if you want to gateway between SIP and XMPP, you
> want to use Jingle. Such gatewaying was one of the core considerations
> for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we
> can certainly write a spec that defines how to translate between
> XEP-0301 and RFC 4103 (e.g., how to translate the SDP).
provided.
> Personally I
> don't think we absolutely need a way to complete a formal negotiation
> over XMPP itself, because I tend to think that just sending a chat
> message is a much more natural interaction,
Yes, but the example was a session on the SIP side, and a series of chat
messages on the XMPP side. And the tricky thing with the example was
that it was not a human operating the SIP side. A human will decide -
"ah, now the call is over, so I hang up". Then the gateway can detect
that and release resources. But if it is a server as in the example,
with no real logical end of the session, then we must rely on some
session signaling from the XMPP user to tear down the session.
Can the directed presence "unavailable" signaling described in RFC 6121
section 5.1 be relied upon for the purpose of ending the session?
/Gunnar
Peter Saint-Andre
Gatewaying is tricky. :)
It seems that you want things to seem natural from the XMPP side (no
Jingle or session negotiation required), but then have something more
formal on the SIP side (INVITEs and all that). This means the gateway
needs to be smarter than something which just translates between Jingle
and SIP. Your gateway could use a <gone/> chat state on the XMPP side to
trigger the end of the RTT session on the SIP side. I have concerns
about using unavailable presence -- that works OK for what's described
in RFC 6121, which is an ad-hoc session between two people who don't
normally share presence, but it breaks down if two people do share
presence (not sure how often that would occur through the gateway).
Peter