Subject: Re: [SIP] IM Questions

From: "farhan" <[email-masked]>
Date: Tue, 19 Sep 2000 23:44:39 +0530

my apologies for sending the last two mails from a colleagues email id. the
messages sent from diyanat's email id were mine.

back to u sean ...

>>                         each message is relayed twice.
>>                 if there are fifty memebers in a group,
>>                         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).

if the server is stateless, then the error recovery is again the job of
MESSAGE orginator. this leads to an unelegent situation where the central
server is aware of group memberships and hence the state of a group but
refuses to deliver MESSAGEs. the state is now split between the sender and
the centralised server.
I guess that such a situation can lead to fragile states. a state ought to
be completely maintain at one node. Let me give u an example:
a sender has a list of five group members while the central server has six
in its list. now when the sender sends one copy to the server, the server
replicates this to the six members. as the server doesn't maintain the
state, it promptly forgets about the message and relays back responses from
six group members. the sender realises that the sixth new member of the list
is a sworn enemy of his and should never have received the message. however,
the group server didnt know nor did the sender know about this.

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

If A, B and C were a group and A INVITED D. then B and C should know that D
has joined (to put D on their group lists). Therefore, it is D who should
signal this to B and C. Using the Call-ID of the INIVTE, D now sends a dummy
message to B and C and gets onto their group lists.
I havent understood how I can skip this step. This step is as kludgy as it
gets and I would rather not do this at all.

>> 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.
>
>This can be done with a centralized server as well.

The advantage of doing this with a central server is that a user could login
from anywhere and retrieve her original friends list (note that I didnt use
the patente word 'buddy'). I have tried to keep away from stout servers and
put more intelligence on the peers. This is the guiding principle enunciated
by Henning.

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

Absolutely. you are right.

>> 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.
>
>But the user ends up paying proportionally to the size of the group :(

Which is poetic justice of sorts. groups are usually about 5-4 each. bigger
groups are just a headache for everyone and usually a person ends up
chatting with just a couple of others in a packed room.

>> 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.
>
>With a new media type and the understanding that the first MESSAGE
>after the INVITE conveys the Call-ID for the chat session.

The Call-ID specified in the INVITE is the same as the Call-ID of the
subsequent messages for that session.
btw, this scheme makes it possible to have more than one sessions with
another user. most of the current crop of messengers drop all the messages
from a user into a single window. this makes it impossible to have a session
of a different context between two specific users in a group.

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

hmmm  "SUBSCRIBE can be used for things far beyond IM" . can i subscribe to
being invited for a session whenever it is on? for instance, i want to know
be invited to the soccer commentary whenever the game starts.

>> 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.
>
>You don't consider this a central server? Or do you intend to
>implement this on one of the peers?

My redirect server is about 1000 lines of code. It handles SIP messages as
fast as they come in. UAs just get each other's Contact: and go away. Thus,
the server is not really required to sustain sessions. I would have loved to
be able to implement this on a peer. the problem however is, how do u (a
fresh user, just logged in from a dialip) contact the first peer of the
network?

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

I meant that MESSAGE work both peer to peer as well as through centralised
servers.
However, SUBSCRIBE requires a presence server to be present so that offline
userids can be subscribed to. Thus, presence requires a presence server.

>> In
>> a steamy undernet server, i cant imagine sending SUBSCRIBE to over
>> hunderd users each time I join or leave a group.
>
>Vs. sending your MESSAGE to a hundred users?

ouch! that is true. but  can't a server consolidate the list of all the
joins and leaves of the past few seoncds and send a update of the userlist
to all the group members? this area does require a more optimal solution.

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

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 20 Sep 2000 11:04:14 -0700

Greetings:

> the group server didnt know nor did the sender know about this.

I was wondering if here one can use "Caller preferences" to indicate the
centralized server to perform Accept-Contact or Reject-Contact per IM message.
This essentially will involve sending a new REGISTER with the mentioned
headers. This raises a question:

How can an individual message be marked for distribution to only a subset of
buddy list without the overhead of sending a new REGISTER to indicate so?

> signal this to B and C.

There are constraints here:

a. Is D a part of the group? If not add it -- should be performed by the
centralized server. INVITE D.
b. Propagate the notification that D is on-line -- should be performed by the
centralized server.
c. Add D to the buddy list inbox for distribution of originating MESSAGEs --
should be performed by the centralized server.

This essentailly leads to a thin UAC and intelligent central control -- the
server.

Regards,

[email-masked]

> Using the Call-ID of the INIVTE, D now sends a dummy