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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Mar 2001 22:41:54 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 10:22 PM
> To: Jonathan Rosenberg
> Cc: 'Rohan Mahy'; [email-masked]'
> Subject: Re: [Simple] IM: A session or not
> 
> 
> Jonathan Rosenberg wrote:
> 
> > 
> > Because, we don't want to be sending IMs across the proxy 
> network. The above
> > approach would allow MESSAGE to go someplace different than 
> INVITE, but it
> > still goes over the proxy network.
> 
> If we treat MESSAGE as being part of an INVITE session, but not as a
> media stream, such MESSAGES would also go directly to the Contact
> address, bypassing proxies (unless they insist on record-routing).

Assuming they don't record route, yes. However, since we are using INVITE to
set this up, and since we see record-routing today, and most proxies ignore
the media when determining whether to record-route, I would expect there to
be intermediate proxies.

> guess this is another variation. (I still prefer the 
> messages-as-media,
> since it makes it easier to have text and audio chat at the 
> same time.)

Correct. In fact, having messages-as-media is a REQUIREMENT if you want to
do any kind of conferencing applications, and you want to think about cases
where there the server performing video mixing is different from the one
doing IM mixing. We don't assume that audio and video go to the same address
as signaling, and this characteristic has been a tremedously important
component of many applications that can be built with SIP. In fact, it is
one of the foundations of the application component architecture. Making
that assumption for messaging (that messages should follow signaling) would
be a big mistake, IMHO.

Let me give an example. Lets say I want to build a service whereby a user
calls an automated customer care system. The system is an IVR type of thing,
and the user can provide input via dtmf or speech reco. Now, wouldn't it be
cool to add messaging to this. The system could attempt to re-invite the
user with a messaging stream. If the user accepts, the system can ask the
user to type things at certain points in time, and then parse the response
with some kind of natural language processing. Now, I don't want the natural
language processing system be the same server than is running the
application itself, just as I don't want the IVR to be the same as the
server running the application itself. I'd like a *natural language
component*, ala the application component architecture, which receives the
messages from the user, and can look for certain things, and then feed back
the results to the application server itself. Same idea as why I want the
IVR separate, so it can feed back the results to the application server.

While Rohans suggetion does allow the messages and signaling to go different
places, they can only go different places registered to the same user, not
to different users. Furthermore, the approach would completely fail for
cases where the user is in more than one call at a time, and needs messaging
for each call to go someplace different. This will be a common case for the
types of systems I describe above.

-Jonathan R.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 31 Mar 2001 20:07:08 -0500

> the media when determining whether to record-route, I would expect there to

I seem to remember that you said that proxies shouldn't record-route
unless they have a really good reason to. The whole point of the SIP
architecture is to allow direct communications between end systems as
the normal case, with proxy-routing as the exception.

Another question is whether systems could be smart enough to respect the
Contact in a MESSAGE for subsequent messages with the same Call-ID.

I'm trying to see what SIP-level things we can do, as an additional
option for occasional messages.