[JDEV] conferencing with all services

[Fabien Ninoles]

On Tue, Aug 14, 2001 at 04:53:17PM -0700, Max Metral wrote:
> Does (1) really capture all scenarios?  It would seem like the protocol
> needs some cooperation from the jabber server...  It seemed like you were
> also saying that the conferencing group is already addressing this issue?

No, that really depend on the transport conferencing protocol.  May be
the transport need to registered the room as a special users and make
some sort of registration process.  The only scenarios that 1 capture is
to permit a registered Jabber User to enter a room served by a foreign
IM services through his transport account.  All the details is let to
the transport and may be for some, it will be impossible.

The goal is to make the transport translate the conferencing protocol of
the service into a jabber conferencing protocol, which can means, for
example, creating a special service like room at conf.yahoo.jabber.org,
which will serve as proxy to the real yahoo conferencing service.  If it
what's you mean about the "cooperation from the jabber server", I think
is more an agent issue than the server issue.  That's lead to more
encapsulation.  Since my English is quite not good, here is an
illustration:

            (a)                 (b)              (c)
+--------+       +-----------+       +---------+      +---------+
| Jabber |<------| Transport |------>| foreign |----->| foreign +
| Client |------>|   Agent   |<------|  server |<-----| clients +
+--------+       +-----------+       +---------+      +---------+

The protocol talk in (b) and (c) are the foreign service conference
protocol, and the protocol talk in (a) is the jabber conference
protocol.  It's mostly the same as a normal transport normally do,
except that instead of the session looks like a normal chat session,
it's really a group session.   Note that already two transports
implement this:  the MSN private conferencing room agent, and the IRC
group chat agent.  So, no secret here.

Where cooperation is more need from the server, is on the issue of
letting a foreign guest send messages to a jabber conference room.  The
problem is that most foreign client can only send or receive messages
going to or coming from their own services (eg. Yahoo client to Yahoo
server).  So the only way for the Jabber room to send a message to the
foreign guest, is by make it believe that it came from the host user.
Same thing for receiving the message:  the foreign guest have to send it
to a known ID which can only be host user.  The message however needs to
be intercept so that it goes to the room sessions instead.  Take note
that the foreign client doesn't know that this is a conference message
since for him, it only sends it to a single user.  Here a more concrete
example.

host at jabber.exp , which is also registered as host at yahoo.jabber.exp,
create a conference room room at conf.jabber.exp.  He want to invite is
friend guest at yahoo.jabber.org to the room.  The room sent the invite
to guest at yahoo.jabber.exp, with the host at jabber.exp as a guest_by
attribute.  The yahoo transport intercept the conferencing message and
transform it in a regular message with host at yahoo.jabber.exp as owner
(note the translation from the original user adress: host at jabber.exp to
the transport registered adress host at yahoo.jabber.exp... in fact, it's
the yahoo account ID which is used but I prefer to used the Jabber ID to
be more explicite) and immediately ask for a presence information from
the yahoo client.  From now, every message coming from
guest at yahoo.jabber.exp to host@[yahoo.]jabber.exp must go instead at
room at conf.jabber.exp until a presence unavailable is send from foreign.
In other words, host at yahoo.jabber.exp is used as the alias for the
jabber conference room jid when used by foreign at yahoo.jabber.exp.

The 3rd solutions address the issue of joining a jabber conference room
to an existing foreign conference room.  I see it like the second
solutions except that the invitation is made to an entire foreign
conference room (like room at conf.yahoo.jabber.exp) instead to an
individual guest.

Sorry, I know my English is pretty bad but I hope this help (gasp!  not
even sure! :/ ) a little more.  Don't be afraid to ask question.
Fabien

> -----Original Message-----
> From: fabien at Nightbird.Dynamic.TZoNE.ORG
> I can see three different kinds of "room proxy".
> 
> 1- Each transport translate their room protocol to the jabber
> conferencing protocol.  This enable jabber user to join other transports
> conferencing service.  It's the more easy one to implement IMHO, but the
> difficulties are really proper to each protocol.
> 
> 2- The jabber server handle the connection.  Since it's a jabber
> service, only jabber clients can create the room and invite people from
> there.  Guest coming from normal jabber user used the normal
> conferencing protocol.  But guest coming from a transport agent (called
> "foreign guest") are bind to the "host user".  Every
> message then send by the foreign guest to the user (remember, the
> destination of a message coming from a yahoo client must be another
> yahoo account) are send to the conferencing room and no more private
> talk is possible.  Also, the conference room send their message as
> coming from the "host user" who invite him since the message most came
> from a yahoo account to the yahoo client.  I think this can be implement
> with very small change over the conferencing module, simply by adding
> the special "foreign guest" user type.  The only thing I'm not sure is where
> the messages coming from the foreign guest should be handled... in the
> transport or in the conferencing module?  The former is not very clean
> and ask for modifications on all transport agent.  The later is more
> clean but I'm not sure if it's possible at all.  Remember that all
> messages are directed to the "host user".
> 
> 3- Finally, the third method is as you describe and can be implement
> like a mix of the two first methods, the special jabber conferencing
> room acting like an anteroom to the transport conferencing room, the
> later being see as a foreign guest of the former.
> 
> Of all those solutions, the first is the one that need more work.
> Also, a critical part came from the jabber conferencing where we must
> forward foreign guest message correctly to the room instead of to the
> host user.  Since both issues seems to involve modifying the transport
> agent, I suggest to came with a clear protocol on how to do so before
> beginning the work on the agents.
> 
--
fabien at tzone.org                 http://www.tzone.org/~fabien
GPG KeyID: C15D FE9E BB35 F596 127F  BF7D 8F1F DFC9 BCE0 9436