Support of data channel media is optional for an MTSI client and an MTSI client in terminal. For brevity, an MTSI client supporting data channel is henceforth denoted as a DCMTSI client or DCMTSI client in terminal, respectively.
To indicate support for the procedures in this clause, a DCMTSI client shall when including media feature tags as specified in TS 24.229 include a +sip.app-subtype media feature tag, as specified by RFC 5688, with a value of "webrtc-datachannel" (the application media format used by RFC 8864), regardless of data channel media being part of the SDP or not.
One or more data channel SDP media descriptions formatted according to RFC 8864 may be added to the SDP, alongside other SDP media descriptions such as e.g. speech, video, and text. A data channel SDP media description shall not be placed before the first SDP speech media description. SDP examples are provided in Annex A.17.
If data channels are used in a session, the session setup shall determine the applicable bandwidth limit(s) as defined in clause 6.2.5.
Multiple data channels may be mapped to a single data channel SDP media description, each with a corresponding "a=dcmap" SDP attribute and stream IDs that are unique within that media description. There is no limit to the number of data channels in an SDP media description, but the aggregate of all defined data channels shall keep within the set bandwidth limit and care should be taken to avoid excessive SDP size. If the session is re-negotiated to include a changed number of data channels in an SDP media description, the bandwith limit may either be kept constant, changing the share of bandwidth available to each individual data channel, or the bandwidth limit may be changed to accommodate the changed number of data channels, keeping individual data channel bandwidth shares. Regardless of what approach is used when changing number of used data channels in a media description, the aggregate of all defined data channels shall keep within the re-negotiated bandwidth limit.
If there is a need to use data channels with either different transport IP addresses, different UDP ports, or different SCTP ports, separate data channel SDP media descriptions shall be used, as IP address, UDP port and SCTP port are all constant per SDP media description. Multiple SCTP associations for a single channel, commonly denoted as "multi-homing", defined in RFC 4960 for reasons of redundancy and basically using one destination transport address at a time, is not described for use with WebRTC data channel and shall therefore not be used in this specification.
To ease data channel media implementation and ease interworking with WebRTC data channels, DCMTSI clients shall support ICE Lite and may support full ICE (RFC 8839), for data channel media. DCMTSI clients supporting full ICE shall only use host candidate addresses. SDP "a=candidate" line host address information shall match corresponding SDP "c=" and "m=" line information.
The data channel application is created prior to the DCMTSI call where it is intended to be used, by means left out of scope for this specification. The data channel application workflow is depicted by Figure 18.104.22.168-1 below.
The data channel application is, referring to the numbered arrows in Figure 22.214.171.124-1:
Uploaded to the network, by the UE user or some other authorized party.
Stored in a data channel application repository in the network.
During the DCMTSI call where it should be used, retrieved from the repository.
Sent through a bootstrap data channel to the local UE A.
Sent through a bootstrap data channel to the remote UE B. This may happen in parallel with and rather independent of step 4.
Any additional data channels created and used by the data channel application itself are established (logically) between UE A and UE B. Data transmission on data channels shall not start until there is confirmation that both peers have instantiated the data channel, using the same procedures as described for WebRTC in Section 6.5 of RFC 8864. The traffic may effectively go through the Data Channel Server, e.g., when the bootstrap and end-to-end data channels have the same anchoring point. This traffic may pass across an inter-operator border if UE A and UE B belong to different operators' networks.
The bootstrap data channel is not intended for use directly between DCMTSI clients in terminal. DCMTSI clients in terminal that receive HTTP requests on a bootstrap data channel shall ignore such request and shall update the session by removing the SDP "a=dcmap" line with the stream ID where such HTTP request was received, and closing that stream ID.
The data channel application sent in a bootstrap data channel may be updated at any time, automatically or interactively, using normal HTTP procedures.
A bootstrap data channel shall be configured as ordered, reliable, with normal SCTP multiplexing priority. The sub-protocol for a bootstrap data channel shall be HTTP (not encapsulating HTTP in TCP), represented by the following, example SDP "a=dcmap" line, which therefore shall be present in each data channel media description in an SDP offer from a DCMTSI client in terminal:
There are multiple, possible providers of data channel applications. In Figure 126.96.36.199-1, assume that UE A is local to the operator hosting the data channel server. Further assume that UE B belongs to a different operator (remote). The user of UE A can create and use data channel applications (steps 1-4), which can also be sent to UE B (step 5). Similarly, some other authorized part associated with UE A's operator can create data channel applications for use by UE A (steps 1-4), which can also be sent to UE B (step 5). For simplicity, there's no data channel server and data channel application repository depicted for UE B in Figure 188.8.131.52-1, but those could be present in a more general case. Seen from the perspective of a single UE, there are then at least four possible data channel application providers:
The local UE user.
Other authorized parties associated with the local network (e.g. the local operator).
The remote UE user.
Other authorized parties associated with the remote network (e.g. the remote operator).
The HTML web content making up a data channel application in each bootstrap data channel represents a different context of user interaction and should open in a separate tab, or some corresponding user interface construct, but the details are out of scope for this specification and left open for individual implementations. It shall be possible to use and navigate between different data channel applications from different bootstrap data channels with different stream IDs that are open simultaneously.
Table 184.108.40.206-2 describes a mandatory mapping between stream ID and bootstrap channel data channel application content sources, as seen from a single (local) DCMTSI client in terminal, each of which shall be listed as separate "a=dcmap" lines with "http" subprotocol in SDP when the DCMTSI client in terminal supports receiving data channel application content from that source.
Figure 220.127.116.11-3, referring to Figure 18.104.22.168-1 and Table 22.214.171.124-2, is depicting the stream IDs used for distribution of a data channel application owned by UE A from its local data channel repository to both UE A (stream ID 10) and its remote UE B (stream ID 110).
A DCMTSI client in terminal may include a data channel media description for the "bootstrap" data channels in the initial SDP offer, as described above and according to RFC 8864, RFC 8839. A DCMTSI client in terminal may add or disable (by setting port 0, as for RTP media) additional data channel media descriptions as needed in subsequent SDP offers.
A DCMTSI client in terminal that desires to use data channels with stream IDs from a data channel application retrieved from its local "bootstrap" data channel stream ID 0 or 10, shall initiate a subsequent SDP offer after the initial SDP offer, opening those data channels by adding corresponding "a=dcmap" and (optionally) "a=dcsa" lines. A DCMTSI client in terminal that retrieves a data channel application from a stream ID different than 0 or 10 (e.g. a data channel application from the peer), shall not initiate any subsequent offer to open data channels used by that data channel application.
A data channel media description with specific loss or latency requirements should use "a=3gpp-qos-hint" in the SDP offer, as detailed in clause 126.96.36.199. If subsequent SDP offers or answers adds data channels with more strict loss or latency requirements that cannot be met by keeping current "a=3gpp-qos-hint" and providing suitable SCTP "a=dcmap" parameters, the existing "a=3gpp-qos-hint" should be modified accordingly. Similarly, if subsequent SDP offers or answers closes (removes) data channels that are known to be the limiting factor for choosing the existing "a=3gpp-qos-hint", a more relaxed "a=3gpp-qos-hint" should be chosen to better fit the remaining data channels.
An answering DCMTSI client in terminal may accept an SDP offer with data channel as described by RFC 8864, RFC 8839.
An answering DCMTSI client in terminal that desires to reject the entire SCTP association for all offered data channels shall set the port to 0 (zero) on the corresponding "m=application" line in SDP, as described in RFC 8864. An SCTP association that initially, or as a result of session modification, has no open data channels ("a=dcmap" lines) should be rejected or closed by modifying the session, setting port number to 0 (zero).
An answering DCMTSI client in terminal that desires to accept some offered data channels and reject others shall indicate this by removing the non-desired data channel "a=dcmap" and "a=dcsa" lines from the SDP answer, as described in RFC 8864. The DCMTSI client in terminal accepting a data channel must also accept the corresponding, supported "bootstrap" data channels with stream ID <1000 (e.g. a=dcmap:0 …).
An offering DCMTSI client in terminal receiving an SDP answer where the data channel SCTP association is accepted (port is not 0) may use any offered stream ID that has a corresponding "a=dcmap" line in the SDP answer, as described by Section 6.5 of RFC 8864. Data channels with "a=dcmap" lines in the SDP offer that are not included in the SDP answer must be considered as rejected and shall not be used, as described by Section 6.5 of RFC 8864.
If still images are used in a session, then the imageseq SDP attribute shall be present in the offer of the corresponding video media session. The syntax is defined below
imageseq = "a=imageseq:" PT [SP item_count]
PT is the payload type number to which the attribute applies to as indicated by the "m=video" line. Optional parameters can be ignored by an MTSI client if not understood. The parameters have the following semantics:
provides the number of images in the corresponding image collection or image sequence. For ITT4RT, the parameter is informational from the ITT4RT-Tx client to the ITT4RT-Rx client. An ITT4RT-Rx client shall not include item_count in the SDP offer. If an ITT4RT-Rx client receives item_count in the SDP offer, it should include the same value in the response.
An MTSI client that supports still images shall support long and varying time distances between RTP time stamps. An MTSI client that supports still images should support the HEVC display orientation SEI message as defined in clause D.3.17 and HEVC VUI parameters. An MTSI client that supports and desires to use still images shall in the SDP offer media description of such a bitstream include the "a=imageseq" attribute. An MTSI client that supports still images and that receives the "a=imageseq" attribute in the SDP offer shall keep the "a=imageseq" attribute in the corresponding media description in the SDP answer.
An MTSI client that doesn't support still images shall remove the image attribute in the answer. An MTSI client that sent the "imageseq" attribute in the SDP offer but does not receive it in the corresponding SDP answer, shall not use still images. In such case, the sender should transmit the still image as a regular continuous video stream that conforms to the requirements in clause 7.4.3 for an HEVC compressed video stream. If that is not possible, the sender shall initiate a session re-negotiation to remove the still image media line.
The "imageattr" attribute as specified in RFC 6236 shall be supported and shall indicate the image size.
Addition and removal of media components shall be performed based on the SDP-based offer-answer model as specified in RFC 3264.
During session renegotiation for adding or removing media components, the SDP offerer should continue to use the same media (m=) line(s) from the previously negotiated SDP for the media components that are not being added or removed.
An MTSI client in terminal may support multiple media components including media components of the same media type. An MTSI client in terminal may support adding one or more media components to an on-going session which already contains a media component of the same media type. If an MTSI client in terminal needs to have multiple media components of the same media type in a single MTSI session, then the MTSI client in terminal should use the SDP content attributes as defined in RFC 4796 for identifying different media components.
SDP examples for adding a second video stream to an ongoing video telephony session and removing a video stream from an ongoing video telephony session are given in Annex A.11.
The content attribute can be used in combination with the group attributes defined in RFC 3388 and also in combination with the synchronization attributes defined in clause 6.2.6, for example to identify two (or more) media components are related to each other and if synchronization is needed.