Sub Topic 001 - SMUoS - Vision

Simple Multiuser over SIP (SMUoS) - VISION

Vision about the First Steps at The Society

Well, the first step of our activities at "The Society", is for sure to learn a little bit about IEEE DIS.

Second step will be / could be, to combine DIS with SIP. This week, I had some reading of RFC 3261. It seems, the use of multicast addresses could be the origin of SIP – I will describe this theory in a little paper soon.

So we should implement a very simple SIP client that interfaces with the used Web3D browser

Better: can we use some existing SIP client? The goal of "The Society" is not to implement anything, but to test 3rd party software. Only, if we need something very special to test something else, then we will implement something.

  1. First step:
    • 1.1. no REGISTER, only INVITE, no SIP server at all
    • 1.2. INVITE is directly sent from SIP client to mcast address 224.0.1.75 "all SIP Servers" (sip:room-name@224.0.1.75)
    • 1.7. all clients that know the room-name answer with 200 OK
    • 1.8. ACK is sent to each client via unicast address from Contact header field
    • 1.9. no provisional responses
    • 1.10. only 200 OK as possible answer (or no answer at all)
    • 1.11. ACK. BYE.
    • 1.12. Contact header field holds name of the user plus the unicast address of the client
    • 1.13. Question: how to describe DIS session in SDP?
  2. Second step:
    • 2.1. no REGISTER, only INVITE, simple SIP server
    • 2.2. the same as 1.2.
    • 2.3. simple SIP server (new element) listens to mcast address 224.0.1.75 "all SIP servers"
    • 2.4. answers with 302 Redirect (redirects to 239.255.x.x multicast address)
    • 2.5. SIP client sends second INVITE towards 239.255.x.x (same Call-ID?, same From-Tag?)
    • 2.6. mapping from room name to mcast address 239.255.x.x is configured at the kamailio server
    • 2.7 - 2.13. the same as 1.7 - 1.13.
  3. Third step:
    • 3.1. REGISTER, INVITE, complex SIP Server
    • 3.2. - 3.5 the same as 2.2. - 2.5.
    • 3.6. some kind of "admin" must authenticate at kamailio an can then register a 239.255.x.x address for the name of a "chat room" dynamically (mapping need not be configured at the kamailio server)
    • 3.7 - 3.13. the same as 2.7 - 2.13.

The "far-end" goal is an interworking between DIS and the BS Contact Network Sensor (which is a more recent networking technology), or even between DIS and a "HTML based" (WebGL) experimental network sensor (WebRTC based).

Vision about some Use Cases

Roles

Trainee = Player, Trainer = Controller, Author, Combined Roles

Architectures

  1. Simple Architecture for 3D Chat
  2. Simple Architecture with SMU Stubs (Application of some "Session Announcement Protocol")
  3. Architecture with SMU Stubs and SIP UAs (enabling voice/video conferences)
  4. Sophisticated Server Software for the Authors of the Scene

Use Cases for the Player

Use Cases for the Controller

Use Cases for the Author

A Little Bit of Technical Details

Please refer to our little text file (latest update 2024-03-01).