Using Kamailio for the spark Project???

[christoph-v]

The first goal of the spark project is to create the so-called "Open Source Conferencing Tool" (so-called "Phase 1" of spark).
However this phase 1 should already target at the far-end goal, i.e. supporting Network Sensor communication of X3D/VRML scenes.
Therefore, we should consider all requirements that are put on X3D/VRML Multiuser Scenes so far:

• a. When the X3D/VRML scene is hosted by a W3C Browser, then the communication shall be compliant to WebRTC/AJAX (refer to following e-mail: http://web3d.org/pipermail/x3d-public_web3d.org/2019-March/010294.html )
• b. The multiuser communication should be backward compatible with classical Web3D browsers and their Network Sensor implementations (BS Contact, Octaga, ......) as well as server implementations (X3Daemon, ......).
• c. The multiuser communication should be backward compatible with HLA/DIS implementations

All these requirements lead to the approach we will try to solve the implementation based on Node.js and WebRTC. Only in case it cannot be solved, then we will try to use a SIP Server like kamailio.

To be discussed

[coderextreme]

See discussion on X3D-public on Electron derivatives for building multiuser systems. And below for editing VRML text inside VsCode. How easy/hard would it be to integrate VRML or X3D DOM player within Electron, which could be used by Discord or VS code (and other Electron apps). Since Discord was mainly for gamers originally, it would be great for Electron to have X3D. Seems like a good environment for 3D modders. This may already be mentioned on the X3D-public mailing list: https://forum.castle-engine.io/t/x3d-classic-highlight-and-snippets-for-vscode/223 The leverage we gain is we don’t have to debug video or voice chat, and we can focus our efforts on collaborative X3D. If somehow, CGE is added as well, cool! I think we have to answer, what is collaborative X3D? Obviously SecondLife used to be a prime example of multiuser 3D. How can we accomplish collaborative X3D? Without seriously damage to ourselves? Can we imagine a collaborative X3D authoring tool in Electron? John

…

On Sat, Apr 16, 2022 at 6:41 AM Christoph VALENTIN ***@***.***> wrote: The first goal of the spark project is to create the so-called "*Open Source Conferencing Tool*" (*so-called "Phase 1" of spark*). However this phase 1 should already target at the far-end goal, i.e. supporting Network Sensor communication of X3D/VRML scenes. Therefore, we should consider all requirements that are put on X3D/VRML Multiuser Scenes so far: - a. When the X3D/VRML scene is hosted by a W3C Browser, then the communication shall be compliant to WebRTC/AJAX (refer to following e-mail: http://web3d.org/pipermail/x3d-public_web3d.org/2019-March/010294.html ) - b. The multiuser communication should be backward compatible with classical Web3D browsers and their Network Sensor implementations (BS Contact, Octaga, ......) as well as server implementations (X3Daemon, ......). - c. The multiuser communication should be backward compatible with HLA/DIS implementations All these requirements lead to the approach we will try to solve the implementation based on Node.js and WebRTC. Only in case it cannot be solved, then we will try to use a SIP Server like kamailio. *To be discussed* — Reply to this email directly, view it on GitHub <#14>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMJ54MRKBZPIF6M3JDI6DVFKRMXANCNFSM5TSIRMKA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[christoph-v]

These questions are too big for the S&P-ARK project, currently. But we can save them for future. I will create a new issue for using Electron.