[Standards] Jingle session lifetime

Robert McQueen robert.mcqueen at collabora.co.uk
Fri Mar 30 14:52:30 UTC 2007

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?
> -lauri


More information about the Standards mailing list