Content for  TS 26.114  Word version:  18.5.0

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. A "data channel application" consists of an HTML web page including JavaScript(s), and optionally image(s) and style sheet(s). A "bootstrap data channel" is henceforth defined as a data channel used to retrieve data channel application(s) for a DCMTSI client in terminal, with a data channel stream ID below 1000, and using the HTTP (RFC 2616) protocol as data channel subprotocol. The data channel application accessible at the HTTP root ("/") URL through a bootstrap data channel describes the graphical user interface and the logic needed to handle any further data channel usage beyond the bootstrap data channel itself. The meaning of the "authority" (host) part of the URL and consequently the "Host" HTTP header are not defined, shall be ignored on reception, and shall be set to the empty value by a DCMTSI client in terminal. 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 6.2.10.1-1 below.

The data channel application is, referring to the numbered arrows in Figure 6.2.10.1-1:

1. Uploaded to the network, by the UE user or some other authorized party.
2. Stored in a data channel application repository in the network.
3. During the DCMTSI call where it should be used, retrieved from the repository.
4. Sent through a bootstrap data channel to the local UE A.
5. Sent through a bootstrap data channel to the remote UE B. This may happen in parallel with and rather independent of step 4.
6. 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: When the HTTP subprotocol is used, any other data channels used by the data channel application JavaScript(s) sent in the bootstrap data channel shall be represented in an updated SDP as additional "a=dcmap" lines with stream ID values starting from 1000, using stream ID numbers from the JavaScript(s). There are multiple, possible providers of data channel applications. In Figure 6.2.10.1-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 6.2.10.1-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:

1. The local UE user.
2. Other authorized parties associated with the local network (e.g. the local operator).
3. The remote UE user.
4. 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 6.2.10.1-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 6.2.10.1-3, referring to Figure 6.2.10.1-1 and Table 6.2.10.1-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 6.2.7.4. 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.

The "a=3gpp-bdc-used-by" attribute indicates which party uses the bootstrap data channel(s) in the media description. It's a media level attribute, and each data channel SDP media description has at most one "a=3gpp-bdc-used-by" attribute. Before the SDP offerer's network sends the SDP offer to its peer network, it should add the "a=3gpp-bdc-used-by" attribute into the media description(s) to help the SDP answerer's network to distinguish m= lines containing the bootstrap data channels with the same stream ID.

The bdc-used-by parameter indicates which party uses the bootstrap data channel(s) in the media description. The following bdc-used-by values are defined:

• "sender": It shall indicate that the stream ID values of the bootstrap data channel(s) in the corresponding media description (m= line) are mapped to data channel application contents sources as seen from the UE sending this SDP. It means that the bootstrap data channel(s) are used by the UE sending this SDP. Thus the bootstrap data channel(s) are established between the UE sending this SDP and the remote network of the UE sending this SDP and need to be terminated by the remote network of the UE sending this SDP.
• "receiver": It shall indicate that the stream ID values of the bootstrap data channel(s) in the corresponding media description (m= line) are mapped to data channel application contents sources as seen from the UE receiving this SDP. It means that the bootstrap data channel(s) are used by the UE receiving this SDP. Thus the bootstrap data channel(s) are established between the UE receiving this SDP and the local network of the UE sending this SDP, and need to be terminated by the UE receiving the SDP.