Subject: [Simple] Multiparty IM

From: "Robert Osborne" <[email-masked]>
Date: Wed, 24 Jan 2001 20:11:32 -0800

Hi,
 
just going through the draft
<http://www.ietf.org/internet-drafts/draft-rosenberg-impp-im-00.txt>
draft-rosenberg-impp-im-00.txt, and started to think about how
multiparty IM might work. By this I mean the common scenario, that most
IM clients support, of A talking to B, and A or B inviting C into the
session.
 
Looking through the draft this could be solved, by A sending a message
to each participant. However B will not know that C has joined the
session, and C will not know about B. Therefore any messages sent by
them will only be sent to A. 
 
Another problem is that if B wishes to leave an IM session, there is no
way for him/her to notify the other participants of the session.
Therefore B could continue to receive messages, without wanting to.
 
Has anyone looked at this problem, and come up with a simple and
effective solution?
 
Rob O 

Rob Osborne 
Program Manager 

Microsoft

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Jan 2001 07:47:27 -0800

At 11:11 24/01/2001 -0800, Robert Osborne wrote:
>ust going through the draft 
><http://www.ietf.org/internet-drafts/draft-rosenberg-impp-im-00.txt>draft-rosenberg-impp-im-00.txt, 
>and started to think about how multiparty IM might work. By this I mean 
>the common scenario, that most IM clients support, of A talking to B, and 
>A or B inviting C into the session.
>
>Looking through the draft this could be solved, by A sending a message to 
>each participant. However B will not know that C has joined the session, 
>and C will not know about B. Therefore any messages sent by them will only 
>be sent to A.
>
>way for him/her to notify the other participants of the session. Therefore 
>B could continue to receive messages, without wanting to.
>
>Has anyone looked at this problem, and come up with a simple and effective 
>solution?
>

The IRC way is to give the session concept separate existence, and have all 
messages sent to the session instead of the participants.
This is the essence of a "channel".

Note: The IMPP requirements and CPIM documents do not have the concept of 
"session".

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: hammer michael <[email-masked]>
Date: Fri, 26 Jan 2001 14:54:20 -0800

It seems like there are two concepts of session to consider:

Connection-oriented:  SIP signaling with separate media streams

Connectionless:  Message-oriented with content and signaling combined

The prior is flow-oriented, the latter discrete.  If SIP is to handle both, 
then some means of distinguishing between the two types of "session" 
establishment, modification, and release may be needed.

Mike

At 08:57 AM 01/26/2001 -0800, Robert Osborne wrote:

> >-----Original Message-----
> >From: Harald Alvestrand [mailto:[email-masked]]
> >Sent: Friday, January 26, 2001 7:47 AM
> >To: Robert Osborne; [email-masked]
> >Subject: Re: [Simple] Multiparty IM
> >
> >
> >><http://www.ietf.org/internet-drafts/draft-rosenberg-impp-im-0>0.txt>dra 
> ft-rosenberg-impp-im-00.txt,
>I agree with you that there needs to be an independent session
>concept. With this session it would be possible to invite people,
>leave, and notify existing members of new members joining.
>
>In the initial implementation of RVP, we believed you could
>determine the members of a session by simply using some information
>included within the headers of an IM. Unfortunately we quickly
>discovered that due to error conditions, it was very easy to get
>the participant list out of step, and therefore had to resort to
>an Invite, Ack, Join, Leave command flow.
>
>I am hoping that someone has come up with a better solution, that
>fits within the current SIP IM proposal of just using a MESSAGE
>to send an IM. Is there something I am missing that allows for
>good participant management using just this method?
>
>Is this something that will be changed, or will the CPIM assume
>that there will be no multi-party IM?
>
>Rob O
>
> >
> >--
>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 Jan 2001 02:06:16 -0500

> From: Robert Osborne [mailto:[email-masked]]
> Sent: Friday, January 26, 2001 11:58 AM
> To: Harald Alvestrand; [email-masked]
> Subject: RE: [Simple] Multiparty IM
> 
> 
> 
> 

---
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 Jan 2001 02:12:20 -0500

(sorry for the previous empty response... outlook is "trigger happy")

> good participant management using just this method?

This problem has come up within traditional SIP applications for multiparty
conferencing. The same requirements exist there - the ability to add/remove
participants from a session (most likely using multi-unicast media) without
a centralized server of any sort. The problems you describe - of tracking
membership and maintaining consistent group state - exist there as well. We
have the sketch of a solution which basically involves a flooding-like
mechanism where each participant tells the other of its known members when
there is a change. Any differences detected cause further exchanges with
other peers. Effectively, its much like a link-state routing protocol, which
is trying to solve a similar problem. Continued work on this topic is taking
place at the sip interim meeting in Dallas next week.

Of course, the easiest way byfar is to have the notion of a central server
of some sorts, which can track membership and send messages out to all
participants. There is a draft on this subject:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-mode
ls-00.txt

-Jonathan R.

---

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Jan 2001 15:14:30 -0500

The multiparty discussion makes me wonder: The current SIMPLE definition of
IM treats IMs more like pages then conversations. The client can correlate
the callID and make a best effort attempt to thread conversations, but that
is about it. The multiparty conferencing approaches you mentioned in general
SIP deal with explicit call legs, do they not?

Would it make sense to also include the concept of text conferences with an
explicit session, i.e. with an INVITE and a BYE? For example, yahoo allows
one to send an instant message (much like in SIMPLE), and also to invite
contacts to a conference. Only the conference mode supports multiparty
messaging.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, January 29, 2001 1:12 AM
> To: 'Robert Osborne'; Harald Alvestrand; 
ls-00.txt

-Jonathan R.

---

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 29 Jan 2001 12:45:42 -0800

A simple solution would be to negotiate a "chat" or "text" media, just
like we negotiate audio or video. After all, the requirements of doing
multiparty audio are about the same as the requirement of doing
multiparty chat; this go for the signalling requirements, i.e. how to
find conference members, and the transmission requirements, i.e. whether
to use multicast groups, transmission server, or some form of ad hoc
replication. We would thus have two separate solutions, simple "page
like" messages using the "message" construct, and "message sessions"
services.

This solution would have the additional advantage of not overloading the
signalling infrastructure with media traffic, even if that media is
text. I always have this vision of the signalling server being
dimemsioned based on the classic voice hypothesis, such as 100 second
sessions and 10% busy users at peak hour, and then being congested
because we forgot that text messaging can generate 10 times more
messages than mere session signalling...

In any case, if we keep messaging in the signalling channel, we should
also keep it simple!

-- Christian Huitema

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, January 29, 2001 12:15 PM
To: Jonathan Rosenberg; [email-masked]'
Subject: RE: [Simple] Multiparty IM

The multiparty discussion makes me wonder: The current SIMPLE definition
of IM treats IMs more like pages then conversations. The client can
correlate the callID and make a best effort attempt to thread
conversations, but that is about it. The multiparty conferencing
approaches you mentioned in general SIP deal with explicit call legs, do
they not?

Would it make sense to also include the concept of text conferences with
an explicit session, i.e. with an INVITE and a BYE? For example, yahoo
allows one to send an instant message (much like in SIMPLE), and also to
invite contacts to a conference. Only the conference mode supports
multiparty messaging.

> > fits within the current SIP IM proposal of just using a MESSAGE to 
> > send an IM. Is there something I am missing that allows for good 
> > participant management using just this method?
> 
ls-00.txt

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 1 Feb 2001 03:47:11 -0500

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, January 29, 2001 3:46 PM
> To: Ben Campbell; Jonathan Rosenberg; [email-masked]

That has always been the intention. You can do text based chat, in a
"streaming" model, using rfc2793 (text over RTP) right now, with no
extensions or additional work. THe existing conferencing mechanisms will all
work for that as well.

However, there is a difference between the text over RTP chat and the IM we
are discussing here. One is "messaging", and the other is "streaming media".
Messaging is characterized by self contained messages, each of which
contains an atomic message which is usefully displayed by itself, and can
live by itself without any other session context. Not so for streaming
media; there, the packets will contain individual letters or groups thereof,
sent based on latency requirements rather than based on some notion of an
atomic message. 

One could imagine a multiparty message session being set up much like the
centrzlied conference servers in SIP. Each participant INVITEs to the same
URL on a conference server. Any MESSAGE method sent to that URL is
replicated to all other users who have joined the session on the server.
This would allow me to trivially add multiparty IM to an existing SIP
conference.

-Jonathan R.

---