Subject: [Simple] IM: A session or not

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Mar 2001 16:23:24 -0500

Folks,

At the IETF meeting, we discussed the main open issue surrounding the IM
draft: whether or not to view IM as a session, as a signaling path message,
or both. I presented some slides that discussed this, which you can obtain
at:

http://www.cs.columbia.edu/~jdrosen/papers/simple_open_mar01.ppt

We need to resolve this issue asap.

I'd like to work from the following proposal:

1. We support the ability to establish IM as a session. This is accomplished
through some SDP parameter registrations to signal whatever is needed to set
it up, which we need to think about.
2. the messaging session is actually done using SIP, using the current
MESSAGE method, as specified. The SDP would include things like the URL to
use. Generally, these messages would then go directly between the
participants.
3. A MESSAGE method can also be sent as a "page", over the SIP proxies,
without having established a session. In this way, it works identially to
OPTIONS. This supports SMS type of functionality, and makes more sense on
one way devices.
4. A MESSAGE method can be sent over the proxy network, as part of an active
session, rather than direct. As far as the end systems are concerned, it
still appears as a session level media stream; it just happened to come in
through an intermediary. This is actually a critical piece for nat.

Is there consensus on this approach? Questions? Concerns? Flames?

Thanks,
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: Rohan Mahy <[email-masked]>
Date: Fri, 30 Mar 2001 16:28:21 -0800

>it up, which we need to think about.

YUK!

Why is this needed?
Why not just REGISTER a Contact with a methods paramater (as below)?
         Contact: <sip:[email-masked]>;methods=MESSAGE

thanks,
-rohan

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 1 Apr 2001 23:07:06 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, March 31, 2001 8:07 PM
> To: Jonathan Rosenberg
> Cc: 'Henning G. Schulzrinne'; 'Rohan Mahy';
> [email-masked]'
> Subject: Re: [Simple] IM: A session or not
> 
> 
> > 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.
> 
> 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.

True. However, I still think its very helpful to allow media streams (video,
audio, messaging) to all go to separate addresses. Rohan's suggestion to use
registrations to route IM separately will require the proxy holding the
registrations to record-route. So, if you want end to end communications,
and you want IM's to go elsewhere, you really need to have the address for
messaging signaled in SDP as other media are.

As to what it looks like, I think we basically need one parameter, which is
the URI. The URI itself can represent anything else we might need.

m=message 5060 SIP sip:[email-masked]

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

Well, then we get partly down the road towards invite semantics. It is in
this space that lies confusion. 

-Jonathan R.
---

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 2 Apr 2001 15:04:03 +0100

All,

To my mind there are two distinct services which are in common use today,
both under the heading 'Instant Messaging'.

First 'chat' systems are characterised by long-lived sessions, which 2 or
more users participating in real-time interactive information exchange. The
information happens to be discrete text strings, but other than this the
similarity with an audio or video conference is pretty compelling.

Second 'paging' systems are characterised by individual point-to-point
real-time or near real-time text messages e.g. SMS.

These services are sufficiently different to contenance different
implementations.

It is also easy to envisage applications where text messaging is just one of
a number of media available for a session (e.g. a video broad/narrow cast
with a choice of subtitles in different languages, videoconferencing with
text instead of audio)

I think there would be great value in having text chat treated as just
another media type, so it can be offered along with audio, video, whiteboard
etc. media in the SDP. This would also allow any future SIP extensions for
management of conferences - floor control is an example which comes to mind
- to apply to 'chat' session as well.

I don't have a strong opinion on the protocol used for the messages
themselves - I think something lighter than a SIP method could be considered
as, for this part of the application, we are not really re-using any SIP
capabilities.

Regards,

Mark Watson
Nortel Networks

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 30 March 2001 22:23
> To: [email-masked]'
> Subject: [Simple] IM: A session or not
> 
> 
> Folks,
>

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Mon, 2 Apr 2001 12:30:18 -0400

3) Send messages "on this channel", i.e. using the same route as other
signaling messages in this session.

[RRR] Whether it will contain the TCP-IP (or UDP-IP) address of the
"Signaling Channel" or the "path" of the "Signaling channel?"

Radhika R. Roy

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Monday, April 02, 2001 12:03 PM
To: Jonathan Rosenberg; Henning Schulzrinne
Cc: Henning G. Schulzrinne; Rohan Mahy; [email-masked]
Subject: RE: [Simple] IM: A session or not

There are indeed many benefits in having actual messaging sessions, but
we should not loose the potential benefits of sending messages through
the "signaling channel" when appropriate: firewall traversal, support of
mobility, immediate page, etc. So, if we go forward with the plan of
documenting an "m=message" media in SDP, we will need to specify at
least three options:

1) Send messages to a specified TCP-IP (or UDP-IP) address,
2) Send messages to a SIP URL,
3) Send messages "on this channel", i.e. using the same route as other
signaling messages in this session.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 Apr 2001 12:07:25 -0700

> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Monday, April 02, 2001 11:14 AM
> To: [email-masked]
> Cc: 'Christian Huitema'; Jonathan Rosenberg; Rohan Mahy;
> [email-masked] wrote:
> >
> > >...if we go forward with the plan of
> > I think (1) and (2) are basically the same situation, and are
covered
> > by Jonathan's proposal. Situation (3) -- an instant messaging
session
> > with a distinct beginning and end, but using the proxy network -- is
> > a new case that needs to have syntax defined for it.
> 
> This is basically one or more MESSAGE within the call-id/call-leg
> context of an INVITE. Or am I missing something here?

Yes. In fact, having this construct might be useful for several media,
not just text...

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 30 Apr 2001 12:59:03 +0100

All,

I think a baseline requirement for the 'chat' type of service is that it can
be combined with other media types, just like voice can.

For example you could have text chat combined with video - which if it's a
unidirection session provides for subtitles - if you allow multiple 'chat'
media streams in a single session, then you can implement subtitles in
multiple languages etc. etc.

Also, combining 'chat' media with, say, a voice/video multi-cast of a
lecture or presentation would allow the observers to submit near-real-time
questions in a way which give the presenter control of which questions are
asked when - so you don't need to interrupt to ask a question.

Just some examples to illustrate that the concept of 'chat' as a media makes
sense.

Considering 'chat' as just another media type would meet this requirement.
There may be other ways, but I'm not sure SUBSCRIBE/NOTIFY meets this
requirement.

Regards,

Mark Watson
Nortel Networks

> From: Roland Auckenthaler [mailto:[email-masked]]
> Sent: 25 April 2001 08:51
> To: simple
> >   2) Create a session for the chat.
> >
> >      a) Using INVITE/BYE, signalling a MESSAGE based chat
> >         with the SDP, including enough information to indicate
> >           1)  The sequence of messages to follow a different path
> >               than the INVITE and BYE.
> >           2)  The sequence of messages follows the same path as
> >               the INVITE and BYE.
> >         One problem to address will be how endpoints working with
> >         routing elements can indicate that INVITE to voice sessions
> >         should go to one endpoint (a phone maybe) while INVITEs to
> >         chat should go somewhere else.
> >
> >      b) Using something other than INVITE/BYE to bound MESSAGE based
> >         chat.
> 
> I'm quite new to the topic of SIP and also this mailing list but in my
> opinion another solution for a "chat"-based session could use 
> a similar
> setup to presence, i.e. SUBSCRIBE/NOTIFY. A "chat-room" can 
> be entered using
> a SUBSCRIBE. This is notified by the server. Then further 
> messaging to and
> from the server is done using MESSAGE. Subsequent NOTIFY 
> requests could then
> allow to signal state changes in the chat room, such as 
> leaving or entering
> of new users.
> 
> Roland
>

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 1 May 2001 16:21:38 -0500

>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. 

This does not compute. If you are treating the MESSAGEs as
"media" for the INVITE session, then the routing of the 
MESSAGE should be independent from the routing for the INVITE and
ideally should be directly end-to-end. If you want something different,
then you need a different mechanism than INVITE. (You are speaking
about the option of using SDP to describe a application/sip "session",
right?)

>
>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.

This is equivalent to asking if proxy/redirect servers should care
about the SDP / media, right? Again, I am unsure of exactly what
you are proposing.

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

/sean

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 May 2001 11:56:54 -0400

I was not suggesting a UAC would ever send an im: URL, but that if I typed
in an im: URL, the UAC would use the srv/naptr stuff to resolve to a sip:
URL, then use the sip: URL in the INVITE.

If I were to publish an instant message address on a business card, it
expected it _would_ be an im: URL. (Realizing of course I would more likely
be publishing a presence URL and letting the presence system deliver the
message address)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 10:49 AM
> To: 'James Undery'; Ben Campbell
> Cc: Robert Sparks; [email-masked]
> > I don't think CPIM requires that the im: tag is used for 
> > anything other than
> > interworking. Using im: URLs will cause problems for proxies 
> > that don't know how
> > to route them, i.e. just like sip:.
> 
> I strongly agree.
> 
> /a
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 2 May 2001 16:26:03 -0400

> Pie-in-the-sky answer: babelfish.
Cool!
> 
> > What you are suggesting
> > is that a chat session be _only_ point to point, ala the use of RTP,
> > and that in no circumstance would it involve a SIP proxy. I'm not
> > comfortable making that strong a statement yet.
> 
> Ah. I see what you're getting at. If you want to do that, it's quite
> acheivable without changing my original proposal: The IP address I
> publish in my SDP is the public address of my local outbound proxy
> for reception of SIP messages. When I send messages to the address
> in your SDP, I indicate that address in the request URI, but send it
> to my local outbound proxy. Yes, it takes some client configuration --
> but so does any use of a local outbound proxy.

Good - that sets the stage for the initial MESSAGE in the chat
session - now do we kick in Route/Record-Route based on the first
MESSAGE of the session?

RjS

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 May 2001 16:54:14 -0400

> session - now do we kick in Route/Record-Route based on the first

Since we are sending over a SIP channel, it would seem the reasonable thing
to do. Refresh my memory--would we honor Record-route for a series of "page"
model messages on the same call leg?

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 2 May 2001 17:48:13 -0500

>> > How much of the call-leg identifier used by the chat session
>> > itself do you signal with the INVITE? 
>> 
>> Good question. My inclination is to use exactly the same correlation
>> information so that matching up of different messaging "sessions"
>> is trivial. Can anyone think why this might be a bad idea?
>
>By same correlation information, you mean same to, from, and call-id,
>counting on the INVITE arriving on a different transport than the 
>MESSAGEs (at least on different ports) so you don't get into CSeq
>mismatch errors? At its best, this will make for great debugging pain.
>What about the other end of the spectrum, where you pass the a whole
>new call-leg tuple as part of the SDP, or at least a new Call-ID?
>
>RjS

A few comments:

First, I'm assuming that you want to use
an INVITE for a chat session of more than one message. Using
CSeq as part of the correlation is difficult to impossible 
depending on how you interpret correlation.

Second, while we are using this INVITE session specifically
to create a chat session, there is no reason not to consider
this for a more general purpose application. You have created
a nested SIP signalling session. There is no reason to limit
that SIP signalling to just the MESSAGE request/response. 
With this in mind, it might make sense to use just the From:/To:
with appropriate tags (ignore the Call-ID).

Third, SDP allows multiple media streams. Are we going to 
allow (in the general case) multiple signalling streams? 
If so, Call-ID is definitely out. But there are more interesting
questions raised by this possibility.

Fourth, why do we need to do correlation based on the INVITE at all?
We have the option to specify a different port on which to receive
this MESSAGE stream. There is a certain elegance to piping it back
into 5060 (or the same port that the INVITE was sent to/from) but
this is not the only way.

Finally, do you need to correlate it based on the INVITE/SDP at all?
Is it important that you are able to distinguish MESSAGEs as belonging
to different streams? (Even in the chat case)

/sean

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 2 May 2001 17:50:00 -0500

>session - now do we kick in Route/Record-Route based on the first

Does Route/Record-Route make sense in a MESSAGE? If you want
to do Route:/Record-Route:, why bother with the enclosing INVITE?

/sean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 8 May 2001 12:30:00 -0400

> Sent: Wednesday, May 02, 2001 3:23 PM
> To: 'Robert Sparks'; [email-masked];
> > From: Robert Sparks [mailto:[email-masked]]
> ...
> > > Firewalls break SIP-IM messages as media; for SIP-IM sessions to
> > > work through them, we expect them to fix them mess they've
> > > created: open holes or modify the SDP.
> > >  
> > > Remember, our job is **NOT** trying to figure out ways to
> > > circumvent measures put in place by firewall administrators. 
> > > If you're concerned about getting the messages through a
> > > firewall regardless of local policy, we should really be putting
> > > together a draft on running SIP IM sessions over HTTP (a la 
> > RFC3093).
> > 
> > And you missed my point altogether here. I wasn't talking about
> > circumventing policy. I was talking about being able to actually
> > _comply_ with it if I wanted to. Firewall like behavior is the
> > cheap and easy answer for why one might want SIP traffic to be
> > forced to go through a proxy - there are others (though I can't
> > at the moment come up with a truly compelling application for
> > any of them with respect to a chat session). 
> 

Actually, the best thing to put in the SDP is a SIP URL. That can
encapsulate everything we might want to convey, and unifies the various
transport treatments we have been talking about.

First off, to answer Robert's original questions, I support the notion of
BOTH a page AND a chat conversational model. I think the page should operate
just like OPTIONS, and not have any session level semantics. Like all other
sessions, an IM based chat session should be wrapped in INVITE/BYE, as I
proposed at IETF 50. The chat stream is signaled in SDP. A chat session is
nothing more than a series of pages, which share a common Call-iD (to
indicate that pages are part of the same stream, similar to the usage of the
port number in RTP), and a common CSeq numbering (to provide sequencing,
like the SN in RTP), both of which have unidirectional semantics only. What
I mean by this is that the UAC, in its invite, indicates the call-id it
would like to see for incoming pages for this stream, and the UAS, in the
200 OK, indicate the Call-ID it would like to see. CSeq provides ordering as
always. I see no need for the message stream call-id to be the same as the
call-id for the SIP INVITE/BYE wrapping the session. In fact, I can think of
some compelling third party call control applications where they can't be
the same. I think this is in line with what Sean was arguing for.

I think that "normal" behavior will be for the URL in the SDP to basically
be a Contact URL, enabling direct point to point messaging:

m=message 5060 sip sip:172.1.2.3

here, the call-id is not provided, so presumably the IP address or port
provide the stream identification.

I would expect a more typical scenario to be:

m=message 5060 sip sip:172.1.2.3?Call-Id=[email-masked]

so that a Call-ID is provided.

For a callee behind a firewall, it can instruct the caller to attempt to use
a proxy network to deliver the message stream:

m=message 5060 sip sip:[email-masked]?Call-ID=[email-masked]

now, this causes the caller to send requests to the proxy for
dynamicsoft.com. These requests appear as, and are treated exactly as pages.
There is no record-routing, since pages have no session semantics, and
therefore, record-routing doesn't make sense. I don't want to define two
separate proxy behaviors for MESSAGE - one for pages, and the other for chat
streams that are routed through proxies. This will be a huge pain. 

A smarter callee might realize they are behind a firewall, but can be
reached through a single proxy, which is the only one that record-routed the
initial INVITE:

m=message 5060 sip
sip:[email-masked]?Route=sip:172.1.2.3&Call-ID=[email-masked]

In another case, the callee might realize that they are natted. In that
case, they make use of a third party "proxy" provider. The UA registers,
using TCP and the contact cookie, with this proxy service. This allows them
to receive messages sent to sip:[email-masked]:

m=message 5060 sip sip:[email-masked]?Call-ID=[email-masked]

Now, it is important to note that in this proposal, the Call-iD is *not* the
same in both directions. Just like the RTP port number is not the same, the
Call-ID, which is its analogy, is a local ID used for correlating pages that
are received. This allows us to unify the treatment of pages and chat
streams, which is an important property. By making the behavior mirror that
of RTP, it also means we can easily apply concepts like third party call
control and multiparty conferencing.

Usage of the SIP URL in the SDP allows us to handle pretty much any kind of
transport or addressing scneario. The transport parameter can specify TLS,
TCP, UDP, or whatever. We can specifies Call-ID's, Route's or whatever we
like.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 12 May 2001 02:14:18 -0400

> From: Robert Sparks 
> Sent: Thursday, May 10, 2001 11:09 AM
> To: Jonathan Rosenberg; [email-masked];
> [email-masked]'
> So, we assume that if the first message in a stream can get to
> its destination any subsequent will as well, and don't care if
> it takes the same path each time (beyond what we know before the
> first message is sent and include as preloaded Route headers in 
> the contact SIP URL in the SDP).

There is room for some flexibility to deal with cases where, for some
reason, the proposed route doesn't work. One can imagine that if the sender
never gets a response to the MESSAGE, they instead attempt to send it to the
same URI as the original INVITE was sent to. Or, perhaps they use a
preloaded Route which is the same the INVITE is taking. All of these are
local choices to handle error conditions, and I don't think need to be
standardized.

 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"?

-Jonathan R.

---

---

From: Robert Sparks <[email-masked]>
Date: Sun, 13 May 2001 02:28:17 -0400

>From: Jonathan Rosenberg
>There is room for some flexibility to deal with
>cases where, for some reason, the proposed
>route doesn't work. One can imagine that if
>the sender never gets a response to the 
>MESSAGE, they instead attempt to send it to 
>the same URI as the original INVITE was sent to.
>Or, perhaps they use a preloaded Route which is
>the same the INVITE is taking. All of these are
>local choices to handle error conditions, and 
>I don't think need to be standardized.
>
>

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.

RjS