[Standards] Jingle session lifetime

Peter Saint-Andre stpeter at jabber.org
Fri Mar 30 16:22:05 UTC 2007

Robert McQueen wrote:
> Lauri Kaila wrote:
>> Dear list,
>> Is it acceptable behaviour to send Jingle action stanzas (transport
>> candidates) immediately after session-initiate, before IQ response is
>> received? Google Talk seems to do that. It does optimize the session
>> setup time, but I'd interpret XEP-0166 so that the session isn't in
>> PENDING state before it's provisionally accepted. If the recipient
>> sends an error response to session-initiate, it likely sends
>> <unknown-session/> to the orphanded actions.
> This sounds fine to me. Our client can start following up a
> "session-initiate" with "transport-info" right away, and just deals with
> the errors that result if it was talking to a session that the other end
> nacked for some reason.
>> Another case when the validity of the session isn't quite clear to me
>> is when two clients send session-terminate simultaneously. The clients
>> will receive terminate right after they sent their own. Should the
>> client send ok response or <out-of-order/> or maybe even
>> <unknown-session/>?
> We discard our idea of the session when we send the terminate, and
> ignore the reply, because if someone refuses the terminate somehow then
> there's nothing we can do anyway, we're not going to send them any more
> media, and we're ignoring anything they're sending us. This means that
> if the terminates cross over, we just reply to each other with
> unknown-session, and neither end cares because they've already stopped
> their streaming.
> It's the same as the content-modify cases - the acknowledements are
> pretty irrelevant because the signalling is simply reporting either "I
> am no longer paying attention to your incoming media" or "I am no longer
> sending you outgoing media". Both are enforcable by the person who sent
> the modification request, so the other end can like it or lump it...
>> There is also the "quick key" case: The initiator wishes to end
>> session before it has received the provisional response. I think the
>> correct way to handle this is simply wait for the response and send
>> terminate right after. But it would be simpler for implementation to
>> send session-terminate immediately, ignore incoming error stanzas and
>> response with <unknown-session/> for possible incoming actions.
> I don't see what you mean by "quick key" - you're terminating a session
> before it's been set up, or you're talking about waiting for the peer to
> responding to us before we heed the user's request that the session
> should end? I think this is bad, we should effect all requested changes
> to the streaming immediately, for privacy reasons at least, not to
> mention sanity - if the other end refuses to terminate the session, what
> can we do about it anyway?
>> I'm not saying that these need to be covered by the spec. Just asking
>> if someone has any comments?

I agree with Rob's assessment and I think it would be helpful for the 
spec to discuss this in the implementation notes or elsewhere. I'll work 
that into the next version.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070330/15d4bcf9/attachment.bin>

More information about the Standards mailing list