From f77ad991fea6700b20f880521e21cada988dd759 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 16 Dec 2008 23:00:46 +0000 Subject: [PATCH] clarified timeout case git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2571 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0166.xml b/xep-0166.xml index 72dcbead..4013131f 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -856,7 +856,7 @@ PENDING o----------------------+ | type='result'/> ]]>

Note: As soon as an entity sends a session-terminate action, it MUST consider the session to be in the ENDED state (even before receiving acknowledgement from the other party). If the terminating entity receives additional Jingle-related IQ-sets from the other party after sending the session-terminate action, it MUST reply with an <unknown-session/> error.

-

Unfortunately, not all sessions end gracefully. In applications of Jingle that also involve the exchange of presence information, receipt of &UNAVAILABLE; from the other party MAY be considered a session-ending event. However, in this case there is nothing for the party to acknowledge.

+

Not all Jingle sessions end gracefully. When the parties to a Jingle session also exchange XMPP presence information, receipt of &UNAVAILABLE; from the other party SHOULD be considered a session-ending event that justifies proactively sending a session-terminate action to the seemingly unavailable party -- if, that is, no other communication has been received within 5 or 10 seconds from the seemingly unavailable party in the form of XMPP signalling traffic, connectivity checks, or continued media transfer.

At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to inform the other party that a device is ringing.