[x3d-public] Wg: Fw: The Society: let me not forget for SIP
Christoph Valentin
christoph.valentin at gmx.at
Tue Jan 30 13:04:02 PST 2024
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240130/533096ca/attachment.html>
-------------- next part --------------
Simple Multiuser over SIP (SMUoS) at "The Society"
==================================================
THIS IS AN EARLY DRAFT WITH INITIAL IDEAS, DATE OF ISSUE - 2024-01-30
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 Realized by the DIS Protocol
- this will be tested with FreeWRL
- Simple MU Sessions can be started by manual input of connection parameters
- this will be tested with FreeWRL
- Simple MU Sessions can be improved by transport of connection parameters
over the SIP protocol (SMUoS)
- tests to be defined
Open issues / problems / unfinished definitions are marked by (?).
--------------------------------------------------------------------------------
1. Simple MU Sessions can be Realized by the DIS Protocol
1.1. Simple MU Session without SIP
1.1.1. Architecture with 2 Web3D Browsers
+---------------+ Exchange of DIS PDUs via 239.255.xxx.xxx +---------------+
| Web3D Browser |--------------------------------------------| Web3D Browser |
+---------------+ +---------------+
With some means that are not in the scope of the present document, it must
be guaranteed that both Web3D Browsers load an instance of the same scene
Following connection parameters need to be manually input by the user, before
he starts the instance of the scene at his Web3D Browser
- 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.2. Simple MU Session over SIP (SMUoS)
1.2.1. Architecture with 2 Web3D Browsers and SIP
+---------------+ Exchange of SIP/SDP +---------------+
| SIP UA |--------------------------------------------| SIP UA |
+-------+-------+ +-------+-------+
| REST Interface REST Interface |
+-------+-------+ +---------------+
| SMU Stub | | SMU Stub |
+-------+-------+ +-------+-------+
| SAI/EAI SAI/EAI |
+-------+-------+ Exchange of DIS PDUs via 239.255.xxx.xxx +-------+-------+
| Web3D Browser |--------------------------------------------| Web3D Browser |
+---------------+ +---------------+
Assumptions:
-----------
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. In later
versions, the SMU Stub might learn the session description via some "Session
Announcement Protocol".
The SIP UAs will be compliant to RFC 3261, at least partially.
The SDP will be built according to RFC 8866.
The SAI/EAI (Scene Access Interface / External Authoring Interface) is+
specified 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 SIP message body of SIP messages that will have to be
defined(?).
o= line
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
The <unicast-address> will be the address of the computer, where the
scene can be downloaded via https. (?) can we use an FQDN here?
Example:
(?) the following assumption needs further scrutiny
The o-line
o=yeti 1706546400 1706546400 IN IP4 185.48.228.109
means, the scene for the MU session can be downloaded from
https://185.48.228.109/blackboard/member-space/yeti/scn/1706546400.x3d
s= line
s=- shall be used. Session names will be defined later(?).
c= line
c=<nettype> <addrtype> <connection-address>
The c-line will NOT be contained on session level, but each media
description will contain at least one c-line.
the media description for the DIS session will contain one and only one
c-line of the form
c=IN IP4 239.255.x.x
where 239.255.x.x means the IPv4 multicast address of the DIS session.
t= line
t=<start-time> <stop-time>
The t-line will be evaluated by the SMU Stub.
If the SIP UA tries to invite to a DIS session at a time instance earlier
than the <start-time>, then the SMU Stub will refuse to start the DIS
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 <stop-time> is
reached during the ongoing DIS session, then the SMU Stub will stop
the DIS session at the Web3D Browser and afterwards hang up the SIP
call to all peers via the SIP UA.
m= line
m=<media> <port> <proto> <fmt> ...
The media description for the DIS session will be set as follows
<media> = "application"
<port> = port to be used with the IPv4 multicast address of the DIS
session (from the c-line)
<proto> = "udp"
<fmt> = "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 <proto> subfield is "udp", the <fmt> 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.[...]
More information about the x3d-public
mailing list