Subject: RE: [Simple] IM: A session or not

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Jul 2001 23:52:16 -0400

> -----Original Message-----
> From: Vasilis Polychronidis 
> [mailto:[email-masked]]
> Sent: Sunday, July 08, 2001 8:40 PM
> To: Jonathan Rosenberg
> Cc: Robert Sparks; [email-masked]';
> [email-masked]'
> Subject: Re: [Simple] IM: A session or not
> 
> 
> Hi All,
> I think this was the last message on this thread (IM: A 
> session or not).
> This was a very interesting discussion.
> Can someone summarize the consensus of the group on this 
> important issue?

I think there was consensus that we would move forward with:

1. defining MESSAGE as a sessionless page mechanism
2. allow for INVITE/BYE to establish an IM session

I think we still have a bit more thinking to do on exactly how the
IM-as-a-session will work. I had proposed including a SIP URL in the SDP,
which will work in many cases, but there are still some record-routing
issues, like the one Robert points out. I don't think those details were yet
ironed out, though.

-Jonathan R.

> > > -----Original Message-----
> > > From: Robert Sparks
> > > Sent: Sunday, May 13, 2001 2:28 AM
> > > To: Jonathan Rosenberg; [email-masked]';
> > > [email-masked]'
> > > Subject: RE: [Simple] IM: A session or not
> > >
> > >
> > > >
> > > >> If the conversation forks in
> > > >> one direction, it will _stay_ forked through the whole
> > > conversation.
> > > >
> > > >By conversation, are you referring to the sip call, or the
> > > message "stream"?
> > >
> > > The stream of MESSAGE requests (the "chat" conversation).
> > > Since we do not
> > > want to make any distinction between a page MESSAGE and a
> > > chat MESSAGE, if
> > > for some reason the stream hits a proxy that forks the chat
> > > MESSAGEs, it
> > > will fork every one.
> > >
> > > This is an unlikely scenario - in the best of worlds, we've
> > > signaled direct
> > > peer-peer delivery of chat MESSAGEs using the SDP in the
> > > INVITE. However, if
> > > we've been forced to use an outbound proxy, or have
> > > introduced a proxy through
> > > preloaded routes, as mentioned above, there's a chance that
> > > something along
> > > the path will fork the chat MESSAGEs.
> > >
> > > I'm not claiming this is a problem. I just wanted to make
> > > sure everyone
> > > understood the possibility existed.
> >
> > Yes, it does. Under normal cases, where either Route is 
> used, or where a
> > direct messaging occurs, it definitely won't. In cases 
> where it does end up
> > forking, you want to be able to reject the message at all 
> hosts except the
> > one that was really supposed to get it. The right way to do 
> that is to
> > include a tag in the To field of all MESSAGE requests. This 
> tag would be set
> > as part of the URI in the SDP. Doing this is a little bit 
> of a stretch; tag
> > is really meant for requests that are part of a session. 
> Technically, since
> > MESSAGE operates like OPTIONS, there is really no SIP 
> session associated
> > with the collection of MESSAGES. But, I think its probably 
> reasonable to use
> > tag in any case. We need to explicitly note, in the text, 
> that a UA should
> > reject a MESSAGE if it contains a to tag that is unrecognized.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> 

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Vasilis Polychronidis <[email-masked]>
Date: Thu, 12 Jul 2001 00:00:50 -0700

Hi Jonathan,
Thank you for your prompt response.
Please see my comments below:

BR,

Vasilis Polychronidis

> 1. defining MESSAGE as a sessionless page mechanism

I would prefer if this becomes a separate ID (Notification/paging service based
on SIP).
Notifications/Pages should be described in a more generic framework. (the same
way SIP Events
are more general than the presence service).
In any rate I do not have any strong feelings about this.
On another issue I am always hesitant of using signaling infrastructure (SIP
proxies) for transporting user messaging.
The signaling infrastructure (SIP proxies) has completely different requirements
(QOS, reliability, availability, etc.) than
your messaging or your transport (RTP, etc.) infrastructure.
IMO mixing signaling data (session initiation) with application data is not a
very good idea.
You do not want the SIP proxies to start dropping INVITE messages (VoIP call set
up)
because your signaling infrastructure is congested from user notification/pages.

SMS which is a huge commercial success was a technical nightmare for the
operators for exactly
the above mentioned reason (mixing signaling in this case SS7 with messaging
data).
I hope we will learn from examples like this and will not repeat similar
technical mistakes.

> 2. allow for INVITE/BYE to establish an IM session

This is an excellent idea.
I will list some of the most important (IMO) benefits of doing this (Jonathan
mentioned many of them in previous e-mails):
1. Unification of Multimedia sessions (VoIP, Video with the Instant Messaging
Service).
Control all sessions (IM, Voice, Multimedia) in a unified method using the same
signaling protocol.
2. forking actually works
3. you can actually clean up state in end systems which are
automata (like an IM conference server, which you cannot build without this!)
This is a huge benefit. Multiparty chat sessions is very natural (easy) with
SIP.
4. you can avoid sending 5meg MP3 "IMs" over proxies
This is very important. Separate signaling from transport. Follow similar
architecture as VoIP.
Actually by introducing the concept of a chat (IM) server you can solve the NAT
issues associated with IM
4. you can reuse alot of the sip tools we have constructed for
sessions - transfers, multiparty conferencing, etc.
Again you unify the user experience. User is presented with the same
features/options regardless
the session (IM, Voice, etc.)

> issues, like the one Robert points out. I don't think those details were yet

The session description should be flexible enough to allow different message
transport protocols as well as
peer to peer and client-server (IM server or chat Server) communication models:

c = IN IP4 FQDN or IP Address
m = message <port> <protocol> [ "/" MP integer] <IM-identifier>

where:
FQDN or IP Address = the address/identifier of expected data source or data
relay or data sink
port = port number
protocol = udp | tcp | http | rtp | sip/udp | sip/tcp
    sip/udp and sip/tcp should not be used to transport messages over SIP
proxies (signaling)
IM-identifier = im:user@domain (CPIM IM identifier)
MP stands for message profile
for example MP 0 may mean CPIM
MP 1 may represent some type of XML type message
etc.
The beauty of this format is that is extensible.
Also this approach allow us to separate the signaling addressing from the
transport addressing

Please lets resolve this issue before the next IETF meeting.

---

From: Vijay Saraswat <[email-masked]>
Date: Thu, 12 Jul 2001 09:27:17 -0400

IM-as-a-session is the right conceptual idea -- when I looked at the SIP
proposal a year ago, the lack of support for this  was one of the things
that stood out (I remarked on this in my evaluation).  SIP is for
*session initiation* ... it is very natural in this context to think of
multiple IM interactions between the same party as constituting a
session. (Note that the MSN Messenger architecture explicitly has the
notion that even one-on-one IM sessions are sustained through a "Session
server".)

One significant issue to be thought through is this .... many, many IM
interactions (and I am willing to bet the proportion is increasing
rather than decreasing as IM sees more business use) are actually still
of the kind:

I: Are you there?
(followed by a long pause)
R: Yeah, whats up
(long pause)
I: Sorry, phone call, am back.
R: cool
I: ok, so what do you think about [....]

In other words, the actual social negotiation of "presence"
(availability of *attention*) might take some time. Regardless of the
technical advances we might make, I will argue that there will always be
a concept of "social presence", hence the need for explicit human
negotiation. So this raises the issue of when should a session
*actually* be established: when the first message is sent from
I(nitiator) to R(esponder), or when the "system" detects that a sequence
of messages (how long does the sequence have to be) has been exchanged
in some amount of time (how short does that have to be)?

Some other issues to be dealt with:
-- determine when a session times out ..most IM session simply get
abandoned .. users dont explicitly indicate that they are leaving them.
(e.g., the phone call phenomenon alluded to above.)
-- figure out whether multi-party chat sessions are/need to be different
from two-party IM sessions

BTW, I dont think the 5meg MP3 IM issue is realistic. All extant IM
systems impose a limit on the size of an IM entering the system. Clients
typically drop IMs exceeding this limit.

Vasilis Polychronidis wrote:

> I would prefer if this becomes a separate ID (Notification/paging
> service based on SIP).
> Notifications/Pages should be described in a more generic framework.
> (the same way SIP Events
> On another issue I am always hesitant of using signaling
> infrastructure (SIP proxies) for transporting user messaging.
> The signaling infrastructure (SIP proxies) has completely different
> requirements (QOS, reliability, availability, etc.) than
> IMO mixing signaling data (session initiation) with application data
> is not a very good idea.
> You do not want the SIP proxies to start dropping INVITE messages
> (VoIP call set up)
> SMS which is a huge commercial success was a technical nightmare for
> the operators for exactly
> the above mentioned reason (mixing signaling in this case SS7 with
> messaging data).
> I hope we will learn from examples like this and will not repeat
> similar technical mistakes.
>
>>
> I will list some of the most important (IMO) benefits of doing this
> (Jonathan mentioned many of them in previous e-mails):
> 1. Unification of Multimedia sessions (VoIP, Video with the Instant
> Messaging Service).
> Control all sessions (IM, Voice, Multimedia) in a unified method using
> the same signaling protocol.
> This is a huge benefit. Multiparty chat sessions is very natural
> (easy) with SIP.
> This is very important. Separate signaling from transport. Follow
> similar architecture as VoIP.
> Actually by introducing the concept of a chat (IM) server you can
> solve the NAT issues associated with IM
> The session description should be flexible enough to allow different
> message transport protocols as well as
> FQDN or IP Address = the address/identifier of expected data source or
> data relay or data sink
> port = port number
>     sip/udp and sip/tcp should not be used to transport messages over
> SIP proxies (signaling)
> Also this approach allow us to separate the signaling addressing from
> the transport addressing
>

---

From: Vasilis Polychronidis <[email-masked]>
Date: Thu, 12 Jul 2001 10:58:27 -0700

Hi Vijay,
Very good comments/questions.
Please see my comments below:

BR,

Vasilis Polychronidis

> notion that even one-on-one IM sessions are sustained through a "Session

Exactly. This architecture makes a lot of sense and solves many potential
problems:
1. NAT issues
2. Universal access issues (mobile, PDA, PC, etc.)
3. Consistency and synchronization issues
4. Authorization/Authentication
5. "Mobility" of buddy lists
6. Security

> (availability of *attention*) might take some time.

True. This is a valid (maybe frequent) use case.
But the user behavior is constraint and shaped by current
IM system implementations.
For example in some IM systems the recipient is first
alerted of ("Vijay wants to chat with you do you accept?") about the
IM session which starts only after explicit acceptance of the invitation by
the
recipient.
Of course you can automate this and start the IM session without explicit
answer from
the called party.
This is an implementation issue and should be decided by the vendor and the
service provider.
The standard should be flexible to allow for the majority of the use cases
(which I think the
IM session model does).
Then this will allow the IM vendors (Server and Client) and the service
providers to differentiate from
each other and the best ones (more features, scalable, etc.) will win.
We should not try to predict user behavior the market will do this for us.

> Regardless of the
> I(nitiator) to R(esponder),

Well here are some of my thoughts on the session initiation issue:
When you want to start an IM session you are basically ringing your called
party.
It is true that the duration of the conceptual ringing may take a long time
but the beauty of SIP is that it allows for such a behavior.
So coming back to your specific issue:
I: sends an INVITE message
the receiving IM User Agent alerts the user by displaying:
"Vijay wants to chat with you do you accept?"
If responder accepts:
R: sends an ACK
bi-directional transport is established via the IM Server (Client-Server
model)
or directly between the two users (Peer to Peer model).

Of course the above are just initial thoughts on this issue I agree with you
that someone needs to
work on the SIMPLE ID where all the use cases are very carefully though out.

> or when the "system" detects that a sequence

I do not support this type of solution. It is more complicated and I do not
see
the additional value of it.

> (e.g., the phone call phenomenon alluded to above.)

Well that should be easy you have a configurable timer.
If session is inactive for a long time send BYE messages.

> from two-party IM sessions

Technically makes sense to unify multiparty and two party chat sessions.
I have though about this and I do not see any compelling technical reason
why they should be different.

>
>
> BTW, I dont think the 5meg MP3 IM issue is realistic.

It is not the issue of individual messages that maybe very big but
IMO the overall volume of IM (user) message traffic vs. signaling
(call/seesion set up messages).
To my understanding certain IESG members have an issue of transporting
"large" user data over the signaling infrastructure (SIP proxies).
IMO "large" refers to the overall user data volume.

> All extant IM

Resolving the above mentioned issues IMO is very critical to the success of
SIMPLE
and I would prefer if we can accomplish this before the next IETF meeting.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jul 2001 16:22:05 -0400

...
> why they should be different.

Depends on what you mean by them being different.

For instance, the same protocol could be used in both cases but there
might be an extra party (a conference server) present for some
multiparty chat sessions.

It would be nice if a two party chat didn't require a server. It would
also be nice for both parties to agree on the message ordering. Always
requiring a server in the middle is one way of agreeing on an ordering
of messages, but there are other ways that don't require a server.

	Paul Kyzivat
	Cisco Systems

---

From: Vasilis Polychronidis <[email-masked]>
Date: Thu, 12 Jul 2001 15:01:12 -0700

Hi Paul,
Please see below:

BR,

Vasilis Polychronidis

> of messages, but there are other ways that don't require a server.

Very true. In my previous Emails I mentioned 2 type of models:
1. Peer to Peer (I think this is the one you prefer)
2. Client-Server model (BTW most of the Service providers prefer this model)
My suggestion is for the protocol to be flexible enough that accommodates both
cases.
I think SIP gives you this flexibility and fits perfectly both models.

---

From: Vasilis Polychronidis <[email-masked]>
Date: Thu, 12 Jul 2001 15:01:34 -0700

Hi Paul,
Please see below:

BR,

Vasilis Polychronidis

My suggestion is for the IM SIMPLE protocol to be flexible enough that
accommodates both  cases.