Subject: [Simple] Implicit MESSAGE sessions revisited

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Sep 2001 10:48:08 -0500

(My apologies in advance for re-opening an old can of worms...)

It seems to the main advantages of explicit (that is, established by 
INVITE) IM sessions are that it can take advantage of  existing SIP work 
for things like complex multipary conferencing scenarios (i.e. chat 
rooms). I hope that we do not see a lot of implementations using it for 
simple things like 2 party chats.

Dean recently commented to me out-of-band, that most 2 party chat 
features can be handled without an explicit session. The most such 
feature obvious is strictly a user interface convenience, where the UI 
can present a series of messages as a thread, using the call-leg to 
identify the thread, CSeq to provide ordering, etc.

But there are other features, such as short-circuiting the path of 
subsequent messages by skipping intervening proxies which do not record 
route, etc. that MESSAGE does not allow. We originally _did_ allow this, 
but the most recent version of the MESSAGE draft deprecates the use of 
_any_ implied session semantics with MESSAGE requests. We made this 
change because at that time we planned to use _explicit_ essions of 
MESSAGE requests to support any session semantics.

In light of the current controversy over the explicit IM session 
concept, I am beginning to wonder if it was a good idea to entirely 
deprecate implicit IM sessions. If we are not going to support explicit 
sessions of IM sessions, does it make sense to revive implicit session 
semantics?

Specifically, should we bring back an optional use of Contact headers in 
MESSAGE requests and associated responses, and should we allow 
record-route semantics? For those who wanted to keep explicit MESSAGE 
request sessions for firewall reasons, would this option help matters?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2001 13:29:36 -0400

Comments below.

	Paul Kyzivat

> simple things like 2 party chats.

I believe there are a number of other advantages.

The most obvious is explicit call control - there is a clear beginning
and end to a session. If I don't want to talk to you anymore, I can hang
up. And if you call back, I can refuse to answer. The act of my hanging
up is a clear signal that I am done with the session.

Another advantage is that multiple media can be clearly tied together in
one call. This is important if those media are needed together. For
instance, if I want you to assist me in operating a troublesome
application, I need an application sharing protocol plus some other
protocol for communicating with you - which might be voice or might be
IM. It doesn't do me any good to have one without the other. And then,
in mid-call, I may decide that IM is too cumbersome, and that voice
would be more helpful. With a call tying everything together, I can
simply reinvite, adding voice, and be reasonably confident that the
voice will be connected to the same endpoint where I am already
interacting with you, rather than some other place like your voicemail
server.

This last example also is relevant when starting out with only IM. I may
still want to switch to voice in mid-call.

All of these are cases that make sense with 2-party calls.

To avoid being spammed excessively, I think I must be reasonably
restrictive about who I accept page mode IMs from. I may be less
restrictive in who I automatically reject when receiving an INVITE - I
can look at who is calling and decide then whether to answer or not.
Most likely I will only accept page mode from an explicit list of
friends, but may at least entertain calls from anyone not on an exclude
list. 

My impression is that most existing IM products don't have true session
mode. Instead they seem to presume that messages to me will only
originate with people on my buddy list. I don't know whether this is
enforced however. If it is not, then eventually it will be abused by
spammers. But there is need for the IM from unknown parties, and I don't
think it can be satisfied by having each potential caller first asking
to be a buddy.

My implication is that when I want to send an IM, or session of IMs, to
someone, it may be best to use session mode unless I know I am dealing
with someone who will permit page mode. Or maybe I should always be
prepared to try both ways.

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Sep 2001 13:04:36 -0500

> All of these are cases that make sense with 2-party calls.

I agree on the explicit call control--there is some advantage in knowing 
when the session ends that can be a minor pain in an implicit session. 
The adding of an additional media stream can normally be handled by a 
new invite, even if the original session was implicit. I can see an 
issue, though, if one participant is not reachable via a direct media 
session, but had been available for a SIP message.

> think it can be satisfied by having each potential caller first asking

AOL works much like you describe, I think. Others (yahoo for example) 
has a clear distinction between sending a message and inviting someone 
to a conference--even if it is just a text conference.

> prepared to try both ways.

I would expect a class of endpoints that could only accept page mode, 
and a class that can do both. I would be surprised to see endpoints that 
could _only_ do sessions, but not page mode.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2001 15:15:29 -0400

> could _only_ do sessions, but not page mode.

I didn't mean to suggest that an endpoint wouldn't be *able* to do page
mode. Only that it might not be *willing* to do page mode with some
callers.