Subject: [Simple] IM support in SIP

From: "Mark Watson" <[email-masked]>
Date: Fri, 23 Mar 2001 15:20:16 -0000

All,

Sorry to be arriving at this debate late. I was interested in why the choice
was made to implement IM as a new SIP method rather than as a new kind of
media, indicated in the SDP and transparent to the SIP layer.

I read through the thread on 'Multiparty IM', in which this proposal was
made. The answer given there was that the existing text support in RTP is
for 'streaming', rather than support of discrete messages.

This only answers why the existing RTP text support is different from
Instant Messaging, not why treating IM as a new type of media is wrong.

Perhaps this has been resolved at a meeting - if so I'd be very grateful if
someone could indulge me with an explanation.

There seems to be a confusion as to whether IM is 'session-oriented' - like
a conversation - or atomic with individual messages being independent of
each other. In the latter case (which seems to be how it is described in the
CPIM RFCs) I can see why a simple MESSAGE method does the job. In the former
case (which seems to be how people think of using IM) it would seem more
sensible to incorporate the 'session' concept from the start.

It does seem to me that IM is just another media type - sure it is not a
'streamed' media, but consists of a series of discrete messages, but
nevertheless there is no reason to place additional requirements on the SIP
layer to support this new media type.

Also, suppose an average IM 'session' consists of 12 messages (this is a
guess), then the real-time requirements at a proxy for this IM session will
be 4 times (12 transactions vs. 3) as great as for a normal SIP session - it
will be strange for proxy capacity for IM sessions to be so much less than
for streaming media sessions.

Equally, looking forward to other media types which may or may not be
streamed, the QoS requirements for the media will generally be different
from those of the control signalling. Further it makes no sense to route
media via the signalling path, instead of directly between the participants.
Remember the signalling path will often be non-optimal in terms of RTT,
since it may be necessary to route the signalling via a users home proxy in
order to find them.

Apologies if I'm missing something here. I thought the idea of SIP was that
it would be a generic protocol for establishment of many types of
session-based real-time communication applications, and yet the proposal
here is to invent an application-specific SIP mechanism.

Regards,

Mark Watson
Nortel Networks

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Mar 2001 12:54:40 -0500

-----Original Message-----
>From: Mark Watson [mailto:[email-masked]]
>Sent: Friday, March 23, 2001 10:20 AM
>To: [email-masked]'
>Subject: [Simple] IM support in SIP
>
>
>All, 
>Sorry to be arriving at this debate late. I was interested in why the
choice was made to 
>implement IM as a new SIP method rather than as a new kind of media,
indicated in the SDP 
>and transparent to the SIP layer.

Indeed, this was the primary subject of discussion at the simple meeting.

>I read through the thread on 'Multiparty IM', in which this proposal was
made. The answer 
>given there was that the existing text support in RTP is for 'streaming',
rather than 
>support of discrete messages.
>
Instant Messaging, 
>not why treating IM as a new type of media is wrong.
>
someone could 
>indulge me with an explanation.

The reason we went for the solution documented in -01 is the "dual" nature
of messaging. In many systems today, there is no setup or establishment -
you send a message, and thats it. Whether to treat it as "media" or a
mesasge on the sip path was debated in the beginning, with myself,
primarily, arguing for the asynchronous messaging model rather than a
session model. I've come to realize since then that this is probably not the
right view, for both the service and its usage in SIP.

So, during simple, I proposed making messaging a "media service", signaled
in SDP. Its not over RTP, and in fact, as a "media service", it itself uses
SIP and the current MESSAGE method between endpoints directly. This has many
advantages.

>There seems to be a confusion as to whether IM is 'session-oriented' - like
a conversation 
>- or atomic with individual messages being independent of each other. In
the latter case 
>(which seems to be how it is described in the CPIM RFCs) I can see why a
simple MESSAGE 
>method does the job. In the former case (which seems to be how people think
of using IM) it 
>would seem more sensible to incorporate the 'session' concept from the
start.

Right. So, the current proposal is that to set up a messaging session, you
send an INVITE, indicate a message session in SDP, and then send messages
directly between end systems (exception is case of nat... see slides on the
subject from the meeting). When done, send BYE.

Another approach is if you want messaging, you can send sip MESSAGE through
the sip network, but this does NOT setup a session. Its just like any other
non-INVITE message, such as OPTIONS. No session, no record-routing, no
nothing.

>It does seem to me that IM is just another media type - sure it is not a
'streamed' media, 
>but consists of a series of discrete messages, but nevertheless there is no
reason to place 
>additional requirements on the SIP layer to support this new media type.

Correct.

>Also, suppose an average IM 'session' consists of 12 messages (this is a
guess), then the 
>real-time requirements at a proxy for this IM session will be 4 times (12
transactions vs. 
>3) as great as for a normal SIP session - it will be strange for proxy
capacity for IM 
>sessions to be so much less than for streaming media sessions.

Again, correct. Its also really troublesome for messages with large
payloads.

>Equally, looking forward to other media types which may or may not be
streamed, the QoS 
>requirements for the media will generally be different from those of the
control 
>signalling. Further it makes no sense to route media via the signalling
path, instead of 
>directly between the participants. Remember the signalling path will often
be non-optimal 
>in terms of RTT, since it may be necessary to route the signalling via a
users home proxy 
>in order to find them.

Yes, also a good point.

>Apologies if I'm missing something here. I thought the idea of SIP was that
it would be a 
>generic protocol for establishment of many types of session-based real-time
communication 
>applications, and yet the proposal here is to invent an
application-specific SIP mechanism.

So, there was not really consensus on the protocol to use the session
oriented approach, although I think the concerns centered mostly on whether
that meant we would or would not offer a "page" type of service where the
messages went through the sip network, without any sessions.

This is the most important issue we need to resolve for simple, and I think
we should focus list discussion on this. The slides on the proposal will be
available shortly, and I'll also post a note quickly summarizing the
proposal to kick off discussions.

-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: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Fri, 23 Mar 2001 14:07:55 -0500

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, March 23, 2001 12:55 PM
To: 'Mark Watson'; [email-masked]'
Subject: RE: [Simple] IM support in SIP

it would be a 
communication 

[RRR/] It appears that it would be good to make the IM-related method
specific to the following characteristics: 1. Minimum delay with real-time
response and 2. Only one-way transmission of the message.

The important point is that IM-like application (or something similar to
this [may be paging who knows] in the future) has a special characteristics
that is NOT equivalent to the sharing of text and/graphics establishing
among the conference participants after establishing the session.

So, the establishment of the real-time session may NOT be applicable in the
IM-like environment.

- Radhika R. Roy [/RRR].

-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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple