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

From: Robert Sparks <[email-masked]>
Date: Tue, 1 May 2001 13:54:58 -0400

Folks - we need to move this along so we can free our crucible
for discussion on publishing and authentication.

I propose that we move ahead and develop the text around

*) session free "pages", very much like what we've already defined
*) "chat" sessions consisting of MESSAGE requests bounded by
   an INVITE/BYE

To address the discussions date:

Is it sufficient for the MESSAGE requests in the chat session
to follow the Route established by the INVITE/BYE bounding it?

  Proposal :
   Yes - 
   In the normal case, proxies that don't truly need to be in the
   path of subsequent requests won't record route, so we should
   end up with a minimal path for these requests. 

Would sip services (proxy/redirect servers) need to be able to
distinguish INVITEs for MESSAGE sessions from INVITES from other
streaming media.

  Proposal :
   No - 
   at least not any more than the services already need to be
   able to differentiate between different types of media streams.

Without objection, we will move ahead with these ideas in the text.

RjS

---

From: [email-masked]
Date: Tue, 1 May 2001 18:56:48 -0500

> From: Robert Sparks [mailto:[email-masked]]
> 

Personally, I *really* prefer another approach Jonathan presented
at the SIMPLE meeting during the 50th IETF: the INVITE contains SDP
using UDP or TCP as the transport, and message/sip as the media type.

What you seem to be proposing really sets the idea of sessions as
we've previously known them on its head. On the other hand, if we
use the body to *describe* the session, it is extremely in line
with everything INVITE has meant so far.

v=0
o=adam.roach 97438978197648642 0 IN IP4 138.85.60.124
s=-
p=+19725830000
c=IN IP4 138.85.60.124
t=0 0
m=message 5060 udp sip

(Excuse me if my syntax is incorrect; my knowledge of SDP currently
is strongly biased towards using it for RTP/AVP, and I'm feeling
a bit too lazy just now to look up whether my hypothetical SDP
message is 100% correct -- but I think I get the idea across).

>    able to differentiate between different types of media streams.

This seems okay. Currently, if I have multiple devices which have
different capabilities, I would probably need some sort of incoming
proxy which would interpret parts of the SDP, at least rudimentarily.
E.g. if the snippet "[cr][lf]m=video" is present, it would route to
my PC client. If only "m=audio" lines are present, it might fork to my
desk phone and my mobile. Extending this scheme to treat SIP IM as
just another media makes sense: I could set it up to fork (the
*INVITE*, not the *MEDIA*) to my desktop and my palmtop with a CDPD
modem.

/a