[Summit] I'd like to discuss about "Another MUJI" in next summit #11

HIro Suzuki hiro.suzuki at d3communications.jp
Fri Jan 13 06:36:39 UTC 2012


 Hello XMPP Communities.

 This is my 1st post to XMPP ML.  I'm very interested in realtime
services by using XMPP Protocol Suits, and I'd like to discuss my some
ideas with you.

 Some years ago, there was a very experimental "MUJI" specification
(xep-0272) as one of XEP series.  After reading this specification,
and some related specifications (for example, Jingle (xep-0166) , MUC
(xep-0045) and so on), I found a kind of solution to realize "Multi
User Jingle".  Just to make clarify to talk about my solusion, I
will call my "MUJI" concept "Another MUJI".

 Now I have reserved air tickets and hotel. (Thank you, I booked Aloft
Hotel.) If you give me a time slot in next XMPP Summit, I'd like to
talk about "Another MUJI" and discuss with you.

-----
Abstract of "Another MUJI"

 In "Another MUJI", I use a MUC server component as a control center
to manage users who are discussing in rich media chat room, in other
words I use MUC protocol as a signaling protocol to manage chat room
users.  And I introduce a media switch to exchange rich media data
path (video, audio, and so on) in chat room.  This media switch is
configured to make "star topology" to set up each user's jingle data
path between each user device and media switch.  This Jingle paths
forms a sort of data plain.

---
 In "Jingle" specification, a data path is set up between one user
device and another user device, but in "Another MUJI", Jingle data
paths are not set up between user devices directly (If Jingle data
paths are set up between user devices directly, this forms "mesh"
topology".  As you know, with a increase of numbers of user, it is
more difficult to set up mesh data path, or to maintain Jingle paths
in geometrical growth)
---

 In order to set up rich media chat room, I think these procedures
as follows are neccesary. 

1. Owner/Moderator creates and configurates a chat room.

2. Moderator joins the chat room by using MUC procudures, and
Moderator's client module as a "Jingle Initiator" requests to set up
"Jingle Session" to a media switch. (In "Another MUJI", the media
switch is cooperated with MUC server component.) When this 1st media
path is set up, the media swich/MUC server component knows rich media
parameters.

3. Participant joins the chat room by using MUC procedures, and the
media switch as a "Jingle Initiator" requests to set up "Jingle
Session" to participant's client module. When this "Jingle Session" is
set up, the media swith will connect betwwen a moderator's path and a
participants's path.

4. One more participant joins the chat room, "Another Muji" system
repeats above procedure 3 again.  And increase of numbers of
participants froms "star topology" (The cnter of "star" is the media
switch/MUC server component, the edges of star are client's devices.)
-----

 Just for information, I attached one picture of "Overview of 'Another
MUJI'" in this mail.  And now, I started to prepare presentation
materials. So it's my pleasure, if you give me a chance to discuss with
you.

Best regards,
Yoshihiro Suzuki
(hiro.suzuki at d3comunications.jp)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/summit/attachments/20120113/2eebc895/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Overview of Another MUJI.jpg
Type: image/jpg
Size: 91010 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/summit/attachments/20120113/2eebc895/attachment-0001.jpg>


More information about the Summit mailing list