Subject: RE: [SIP] IM Questions

From: diyanat <[email-masked]>
Date: Mon, 18 Sep 2000 17:15:15 +0530

the associated problems with IM on sip are that:

1. there is no way of identifying the complete list of subscribers to a
user who joins a group chat. although separate notifications can be sent
for each user, imagine doing that to a chokeful room of 50 users. it
will cause a thundering herd effect.

2. there is no way of having reverse lists, ban lists, etc. within the
SUBSCRIBE/NOTIFY mechanism. there are suggestions that we do this
through a web interface. in that case, we might as well do the complete
IM through web requests leaving only MESSAGE for unsolicited, push
delivery of messages.

Instant messaging is a type of session that can be initiated by SIP just
like an RTP session.
I would suggest that SIP can try a nomeclature of specifying a type of
IM session within the body of an INVITE rather than being an IM session
in itself. Remember that SIP is just an Intiation Protocol not a Session
Protocol in itself.

I have spent considerable time pestering rosenberg and schulzrinne about
these issues. One suggestion from schulzrinne was that we could take a
look at IRC itself for group chats. however, to  date IRC doesnt have a
formal URL definition. In anycase, if we adapt IRC protcol, it would be
a fairly good choice.

IRC already does what most IMs claim to do and more. it can be easily
expanded and it has a far larger user base as compared to proprietory
protocols and it is open. unfortunatley for the big buck corporations,
the best of the irc systems are for free and that is reason enough for
them to look away.

it maybe a good idea to implement a session description like IRC/TCP
specifying. the userid/password/server names are already well defined
within the sip url. there is little else required to make the call. I
have already tried integrating the mirc to do this with our sip client.
it is a little slow in logging/connection but it works.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Sean Olson <[email-masked]>
Date: Mon, 18 Sep 2000 17:22:49 +0200

I may be misunderstanding some of the terminology you are using. See my
comments inline.

> will cause a thundering herd effect.

If joining a group chat is accomplished via a REGISTER, then this (
supplying the new user with the list of current members) can
be easily achieved. What you seem to want is to provide the current
members
of the group notification that a member has been added/deleted. This
does not seem to be horribly heavy weight if implemented using a NOTIFY
to each member. You could even piggyback this on another
MESSAGE/response 
depending on your needs. I guess I'm missing the problem here. 
(I'm assuming a centralized server for the group chat.)

> SUBSCRIBE/NOTIFY mechanism. 

What about using Caller Preferences for this? Or do you want a more
centralized approach?

> there are suggestions that we do this

It doesn't seem unreasonable to couple SIP with HTTP. They complement
each other quite well. MESSAGE is meant for push delivery of
messages. If you want a polling or queueing mechanism, it is 
relatively easy to do on top of MESSAGE.

> in itself. Remember that SIP is just an Intiation Protocol not a Session

There are many good reasons to use MESSAGE outside of a INVITE session.
The primary reason is the "instant" part. Why initiate a session for a
one shot message? It is also nice to leave the correlation of MESSAGEs 
up to the applications/peers (a 'session' model may not be
appropriate).  
There is nothing to say you can't use INVITE to initiate an RTP session
for text (RFC2793). 
This may in fact be more appropriate for your application.

> the best of the irc systems are for free and that is reason enough for

IRC is far from perfect. I don't like the relay segmentation problems.
There are also nice synergies when you use the same mechanism for IM 
that you use for VoIP. Who says SIP can't be free as well? :) 

--
Sean Olson <[email-masked]>

---

From: diyanat <[email-masked]>
Date: Tue, 19 Sep 2000 11:45:23 +0530

sean,

i guess that i was a little abrupt with my rantings. i have, in an
earlier post covered some issues of IM that i have faced with practical
implementations. let me very briefly run through them.

First Issue:
A group chat may or may not use a centralised server. 
IF we use a centralised server
        the bandwidth requirements of the centralised server 
        will go up as the square of the number of users per group.
        for ex: if there are three members in a group,
                        each message is relayed twice.
                if there are fifty memebers in a group,
                        each message is relyaed 50 times.
ELSE we use a peer to peer group chat
       each member of the group has to be informed of any
       new members joining or leaving the group. so that
       the group list is synchronised by everyone.

in our implementation, we did the following:
1. new group starts it's life as a 1-1 chat between two users. this
essentially consists of MESSAGE requests flying back and forth with the
same Call-ID but different CSeq for each message.
2. a new user is INVITEd to join the group by sending (hold your
breath!) and INVITE message with SDP specifying SIP/2.0/UDP MESSAGE as
the media description. multiple a=participant=userid specify the other
participants in the list.
3. upon receiving an INVITE, the called user reacts just like a normal
SIP response and awaits an ACK from the caller.
4. Once the MESSAGE session is established, the called user sends a
dummy MESSAGE with the group chat's Call-ID to update everyone's group
list.

the advantages of this scheme are:
1. any member of the list can now choose between taking a text only or a
text+voice chat. this is especially important if the UA can handle only
one voice call while being able to handle multiple message sessions.
2. a user can maintain (and it does in our UA) the list of banned userid
or refuse to receive messages from a particular user.
3. while sending a message to all the group members, if a 200 OK
response doesnt arrive from a particular user, the user is removed from
the group list if it is a final response. thus, a userid is removed from
a list when a user returns with a 400+ final response.
4. as the scheme is completely peer-to-peer, the centralised chat server
bandwidth is conserved and the users have to pay (nominally though, text
is hardly bandwidth intensive) by bandwidth whenever they send a group
message.
5. this scheme can very well include using a group chat server (where
in, the chat server represents a bunch of users).
6. this scheme will work well with the existing clients that understand
only MESSAGE, INVITE. we are only adding a new session type.INVITE is
interpreted the same way as before.

Second Issue:
dr. rosenberg convinced me that polymorphism of MESSAGE is a bad idea
and thus, there is no point using MESSAGE to invite a  user. invite with
an INVITE, and message with a MESSAGE. get out of a group by saying BYE.
simple.

the idea of a session-less messaging is great. It is essentially a page.
an SMS for the Net. If the MESSAAGE receiver returns a reply back with
the same Call-ID, then it is an ad-hoc session, else it was a page and
sender can forget about the MESSAGE. am i right on this?

But are we moving towards IM domination or are we adding minimal IM for
functionality? the approach in would be different for the two aims. If
we are to provide a high class IM, then we cannot bifurcate the
SUBSCRIBE, MESSAGE and REGISTER into separate and independent proposals.
they all MUST be implemented and available together. The solution has to
be optimal in anycase. For instance, within a single SUBSCRIBE message,
we should be able to subscribe to more than one presentities. Similarly,
in MESSAGE we need to be able to CC to more than one people. we need to
adding forking, we need to add message signing and we need to add store
and forward deliveries (deliver me a message that coffee is ready in 5
minutes).

Issue three:
the main advantage of peer to peer messaging is that there are no
servers to crash out and attack. a trivial Redirect UDP server handling
REGISTER and MESSAGE is all that is required. this is architecturally a
beautiful piece. the problem is that without a server, that you cannot
add more services and functionality to a network unless the UAs are
replaced. while in a server based messaging system, sky is the limit
(rather, the complexity and bandwidth are the limitations).
it would be best if you could leave out the decision of either of the
two to the implementors and have a protocol that will work well in both
cases. I think that MESSAGE is one such scheme. But SUBSCRIBE is not. In
a steamy undernet server, i cant imagine sending SUBSCRIBE to over
hunderd users each time I join or leave a group.

- farhan

---

From: Sean Olson <[email-masked]>
Date: Tue, 19 Sep 2000 16:29:21 +0200

Interesting ideas. Comments inline

>                         each message is relyaed 50 times.

If you are speaking about text messages, the bandwidth is minimal.
This can be done in a stateless manner by the centralised server
and so involves no state information per message (there is 
registration state of course). 

>        the group list is synchronised by everyone.

There are clever ways to do this that don't involve notifying 
every single member but they are brittle.
 
> dummy MESSAGE with the group chat's Call-ID to update everyone's group

Why not use the Call-ID of the INVITE and skip step 4. Other than
that, this is basically what I had in mind as well (except for the
media description :) 

> or refuse to receive messages from a particular user.

This can be done with a centralized server as well.

> a list when a user returns with a 400+ final response.

I'm not sure I would take this approach. There are many 400+ responses
that might indicate just a transient error that might be recoverable
on subsequent MESSAGE requests, especially since the routing of the
MESSAGE might involve things like forking, DNS SRV lookups, etc.
A 600 class response would clearly indicate that the user should be
removed, but the other response codes I would look at individually.

> is hardly bandwidth intensive) by bandwidth whenever they send a group

But the user ends up paying proportionally to the size of the group :(

> interpreted the same way as before.

With a new media type and the understanding that the first MESSAGE
after the INVITE conveys the Call-ID for the chat session.
 
> sender can forget about the MESSAGE. am i right on this?

Exactly. 

> they all MUST be implemented and available together. 

Actually they all work quite well independently. MESSAGE does not
rely on SUBSCRIBE or REGISTER. REGSITER obviously does not depend
on MESSAGE or SUBSCRIBE. And SUBSCRIBE can be used for things far
beyond IM. They do work wonderfully together though.

> The solution has to
> we should be able to subscribe to more than one presentities. 

You can do this with SUBSCRIBE. It all depends on your interpretation
of the Request-URI.

> Similarly,

I agree this is a shortcoming with MESSAGE. I would like to see
a Cc: and/or Also: header for this purpose. [this opens up all kinds
of problems though as the original cc draft demonstrated]
 
> REGISTER and MESSAGE is all that is required. 

You don't consider this a central server? Or do you intend to
implement this on one of the peers?

> this is architecturally a
> cases. I think that MESSAGE is one such scheme. But SUBSCRIBE is not.

I don't understand your argument regarding SUBSCRIBE vs. MESSAGE.
[I'm making the bold assumption that you can send a NOTIFY without
a prior SUBSCRIBE; not in the current draft, but a useful mechanism]

> In

Vs. sending your MESSAGE to a hundred users?