Transport RTP et al
If you need an overview about the topic, please visit the WIKI HOME PAGE.
The ALP has been outlined during a brainstorming in spring 2019 (ALP Brainstorming).
A suggestion for dynamic behaviour of the ALP is given at Dynamic Behaviour.
When thinking about the transport of the ALP over one of several transport architectures,
come to ones mind:
carry any data
- UDP - User Datagram Protocol (RFC 768 - STD 6)
- TCP - Transmission Control Protocol (RFC 793 - STD 7)
- SCTP - Stream Control Transmission Protocol (RFC 4960 - proposed standard)
- ......
can carry discrete user data in addition to call setup and maintenance
- SIP - Session Initiation Protocol (RFC 3261 - proposed standard)
- XMPP - Extensible Messaging and Presence Protocol (RFC 6120 - proposed standard)
- RTSP - Real-Time Streaming Protocol Version 2.0 (RFC 7826 - proposed standard)
- ......
carry continuous or discrete media data
- MSRP - Message Session Relay Protcol (RFC 4975 - proposed standard)
- RTP/RTCP - A Transport Protocol for Real-Time Applications (RFC 3550 - STD 64)
- ......
- 3GPP IMS Architecture (ETSI TS 123 228)
- 3GPP Mission Critical Networks (ETSI TS 123 280)
- ......
*) Hints for further items on these lists are gladly accepted.
This Wiki Page describes the transport of the ALP over RTP/SCTP in the Media Plane.
The 3GPP IMS Architecture is taken as background and the SIP Protocol is taken as background, if topics are encountered that affect Session Control or the Architecture.
Citing RFC 3550
[...]Multimedia session: A set of concurrent RTP sessions among a common group of participants. For example, a videoconference (which is a multimedia session) may contain an audio RTP session and a video RTP session.
RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the the encoding itself multiplexes multiple media into a single data stream.[...]
We would like to introduce a new type of RTP session, which distributes the so called "shared state" (actually states and events) among the instances of a 3D scene in a 3D Multiuser Session.
Therefore we will probably be inclined to write a new Internet Draft, in analogy to the RFC 3551 (A/V Profile), which we would like to call the Collaborative 3D Profile (C3P). This step may be omitted, if we find equivalent standards already in place.
We would like to introduce the term "3D Multiuser Session", or simply "Multiuser Session" for each Multimedia Session that hosts at least one RTP session of type C3P.
A Multiuser Session could comprise a C3P session for the movement and simulation of facilities in a 3D game and an audio conference session for the push-to-talk communication of the gamers, e.g.
The ALP has been outlined during a brainstorming in spring 2019 (ALP Brainstorming) and it can be split into several "Functional Areas":
- Session Control, Messaging and Presence, Voice Chat, Avatar Management (User related functions, AAA related)
- (Downloading [Parts of] the Scene via http/https is considered an external function)
- Simulation Control (SSRC Management, Dynamically Adding/Removing Models or Scenery)
- Navigation Mode (Simulation of Avatar Models)
- Simulation of Models and Scenery without Persistent State (event-driven predefined animation and sound)
- Simulation of Models with Discrete Persistent State (state-changes every now and then, non-RT behaviour)
- Simulation of Models with (Quasi-)Continuous Persistent State (continuous state distribution, RT behaviour)
Note: Functional Area 1. could be outsourced to an external control protocol like SIP or XMPP, if available.
- Existing HLA/DIS uses RTP, too. (is this true???)
- RTP is a stable internet standard and allows for real time behaviour (minimizing jitter)
- RTP (actually the APP packet type of RTCP) can be used for arbitrary application data, too
- RTP is not restricted for transport over UDP, but can be transmitted over secure transport, too
Drawback:
- RTP needs the multiplexing capabilities of the lower layers, in order to transmit more than one stream
- The C3P use case will need many streams per RTP session (~64k) - 1 SSRC = 1 Real-Life-Entity = 1 Model = 1 Stream
- this can be handled by SCTP
- WebRTC defines that SCTP should be used at the media plane
- SCTP can multiplex up to 64k streams per SCTP Association
- SCTP can transport RTCP packets (control data) in a secure way, ordered "per stream"
- SCTP can transmit multicast data for the continuous media transmission (U bit set)
