Simple Multiuser over SIP (SMUoS) at "The Society" ================================================== THIS IS AN EARLY DRAFT WITH INITIAL IDEAS, DATE OF ISSUE - 2024-03-01 Responsible ----------- Gesellschaft für rechnergestützte Zusammenarbeit Hengsttalweg 14 2734 Puchberg/Schneeberg Austria (Europe) ZVR-Zahl: 1519918045 *) *) The central registry of associations in Austria (ZVR) can be queried at the address http://zvr.bmi.gv.at. For this purpose, you need the "ZVR-Zahl" Author ------ Christoph VALENTIN Brunhildengasse 3/3/19 1150 Wien General Assumptions: ------------------- - Simple MU Sessions can be synchronized by the DIS Protocol - DIS Sessions can be started by manual input of connection parameters - DIS Sessions can be improved by some "Session Announcement Protocol" - DIS Sessions can be further improved by the SIP - DIS Sessions can be made perfect by an adaptation of Authoring Tools - Simple MU Sessions can be synchronized by the Network Sensor Note: we call this "Network Sensor Sessions" NSS that are realized with the help of the "Network Sensor Node" NSN - NSS can be started by manual input of connection parameters - NSS can be improved by some "Session Announcement Protocol" - NSS can be further improved by the SIP - NSS can be made perfect by an adaptation of Authoring Tools - The Interworking between DIS Sessions and Network Sensor Sessions could be the "door opener" Open issues / problems / unfinished definitions are marked by (?). -----> THE FOLLOWING TEXT NEEDS SERIOUS REWORK -------------------------------------------------------------------------------- 1. Simple MU Sessions can be Started by Manual Input of Connection Parameters 1.1. Architecture with 2 Web3D Browsers +---------------+ +---------------+ | SMU Stub |<---- Input of Session Description ---->| SMU Stub | +-------+-------+ +-------+-------+ | SAI/EAI SAI/EAI | +-------+-------+ Synchronization of Shared State / 3D Chat +-------+-------+ | Web3D Browser |-------- CONNECTIVITY PLATFORM (CP) --------| Web3D Browser | +---------------+ +---------------+ With some means that are not in the scope of the present document, it must be guaranteed that both SMU Stubs use the same session description at a time Following connection parameters need to be manually input by the user, before he starts the instance of the scene at his Web3D Browser (DIS case) - Multicast IP Address 239.255.xxx.xxx .....the same for all instances - Port Number ..............................the same for all instances - Site ID ..................................different(?) for all instances - Application ID ...........................different(?) for all instances 1.1.1. Test Setup DIS Based MU Session Web3D Browser = FreeWrl, Xj3D 1.1.2. Test Setup Network Sensor Based MU Session Web3D Browser = BS Contact, Instant Player, Octaga, ....... Web3D Browser = X3DOM, X_ITE, ....... 1.1.9. Test Setup NSN DIS Interworking Tbd. 2. Simple MU Sessions can be Improved by Some "Session Announcement Protocol" 2.1. Architecture with 2 Web3D Browsers +---------------+ +---------------+ | SMU Stub |<---- Session Announcement Protocol ---->| SMU Stub | +-------+-------+ +-------+-------+ | SAI/EAI SAI/EAI | +-------+-------+ Synchronization of Shared State / 3D Chat +-------+-------+ | Web3D Browser |-------- CONNECTIVITY PLATFORM (CP) --------| Web3D Browser | +---------------+ +---------------+ With some means that are not in the scope of the present document, it must be guaranteed that both SMU Stubs use the same session description at a time However, the set of session descriptions is distributed by the SAP, hence providing some security about using the correct scene and network connection. 2.1.1. Test Setup DIS Based MU Session Web3D Browser = FreeWrl, Xj3D 2.1.2. Test Setup Network Sensor Based MU Session Web3D Browser = BS Contact, Instant Player, Octaga, ....... Web3D Browser = X3DOM, X_ITE, ....... 2.1.9. Test Setup NSN DIS Interworking Tbd. 3. Simple MU Sessions can be Further Improved by the SIP 3.1. Architecture with 2 Web3D Browsers +---------------+ Controlling the MU Session / Conference +---------------+ | SIP UA |--------------------------------------------| SIP UA | +-------+-------+ +-------+-------+ | Some I/f Some I/f | +-------+-------+ +---------------+ | SMU Stub |<---- Session Announcement Protocol ---->| SMU Stub | +-------+-------+ +-------+-------+ | SAI/EAI SAI/EAI | +-------+-------+ Synchronization of Shared State / 3D Chat +-------+-------+ | Web3D Browser |-------- CONNECTIVITY PLATFORM (CP) --------| Web3D Browser | +---------------+ +---------------+ 3.1.1. Test Setup DIS Based MU Session Web3D Browser = FreeWrl, Xj3D 3.1.2. Test Setup Network Sensor Based MU Session Web3D Browser = BS Contact, Instant Player, Octaga, ....... Web3D Browser = X3DOM, X_ITE, ....... 3.1.9. Test Setup NSN DIS Interworking Tbd. 9. Assumptions about the Implementation (VERY DRAFT) The SMU Stub will implement the main UI/GUI for the Simple MU Session. The SIP UA and the Web3D Browser will be controlled by the SMU Stub. The above assumption needs further scrutiny(?) The SMU Stub will be the master storage of the session description. The SIP UAs will be compliant to RFC 3261, at least partially. The session description will be built according to RFC 8866. The SAI/EAI (Scene Access Interface / External Authoring Interface) is spe- cified by the Web3D Consortium. However, it is expected that some additional assumptions will be necessary for this application of the SAI/EAI. Following connection parameters need to be exchanged via SIP, in the application/sdp message body of SIP messages that will have to be defined(?). o-line ====== o= The will be the address of the computer, where the scene can be downloaded via https. See the example below. s-line ====== s= See the example below. c-line ====== c= See the example below. t-line ====== t= The t-line will be evaluated by the SMU Stub. If the SIP UA indicates an invitation to a MU session at a time instance earlier than the , then the SMU Stub will refuse to start the MU session at the Web3D Browser and it will reject the SIP call via the SIP UA. If the SMU Stub detects that the time instance of the is reached during the ongoing MU session, then the SMU Stub will stop the MU session at the Web3D Browser and afterwards hang up the SIP call to all peers via the SIP UA. Example ======= The o-line o=/blackboard/member-space/yeti 1706546400 1706546400 IN IP4 lc-soc-lc.at and the s-line s=/public/srr.x3d would mean, the scene for the MU session can be downloaded from https://lc-soc-lc.at/blackboard/member-space/yeti/public/srr.x3d Together with the c-line (DIS case) c=IN IP4 239.255.1.1/1 this would mean, the SIP INVITE will be sent to the SIP URI sip:/public/srr.x3d@224.0.1.75;ttl=1;mcast=224.0.1.75 and the DIS PDUs will be sent to the mcast address 239.255.1.1 (TTL 1). m-line (DIS case) ====== m= ... The media description for the DIS session will be set as follows = "application" = port to be used with the IPv4 multicast address of the DIS session (from the c-line) = "udp" = "vnd.apache.thrift.binary" Note: the media type application/vnd.apache.thrift.binary is used as temporary solution in our test setup, as long as no SDP description is defined for DIS sessions at an IETF RFC. Citing RFC 8866 [...]If the subfield is "udp", the subfields MUST reference a media type describing the format under the "audio", "video", "text", "application", or "message" top-level media types. The media type registration SHOULD define the packet format for use with UDP transport.[...]