Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 26.114  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   3…   4…   5…   6…   6.2.3…   6.2.5…   6.2.7…   6.2.10…   7…   7.5…   8…   9…   10…   10.2.1.6…   10.2.2…   10.3…   10.4…   11…   12…   12.3…   12.7…   13a…   16…   16.5…   17…   18…   19…   A…   A.3…   A.4…   A.5…   A.10…   A.14…   A.15…   B…   C…   C.1.3…   C.1.3.5   C.2…   D   E…   E.18…   E.31…   G…   K…   L…   M…   N…   O…   P…   P.3   Q…   R…   S…   T…   U…   V…   W…   X…   Y…   Y.6…   Y.7…

 

6.2.10  Data channel |R16|p. 70

6.2.10.1  General |R17|p. 70

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 [172]), regardless of data channel media being part of the SDP or not.
One or more data channel SDP media descriptions formatted according to [172] 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 must 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 must 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 must 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 must 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 must therefore not be used in this specification.
Data channel stream IDs below 1000 must be reserved for using the HTTP [73] protocol, henceforth denoted as "bootstrap data channels", to retrieve an HTML web page including JavaScript(s), and optionally image(s) and style sheet(s), henceforth denoted as a "data channel application". 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.
Copy of original 3GPP image for 3GPP TS 26.114, Fig. 6.2.10.1-1: Data Channel Workflow
Figure 6.2.10.1-1: Data Channel Workflow
(⇒ copy of original 3GPP image)
Up
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 must be configured as ordered, reliable, with normal SCTP multiplexing priority. The bootstrap data channel shall use a well-defined sub-protocol. The sub-protocol should be HTTP (not encapsulating HTTP in TCP), represented by the following, example SDP "a=dcmap" line, which therefore must be present in each data channel media description in an SDP offer from a DCMTSI client in terminal:
a=dcmap:0 subprotocol="http"
When the HTTP subprotocol is used, any other data channels used by the data channel application JavaScript(s) sent in the bootstrap data channel must 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 must 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.
Stream ID Content Source
0Local network provider
10Local user
100Remote network provider
110Remote user
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).
Copy of original 3GPP image for 3GPP TS 26.114, Fig. 6.2.10.1-3: Distribution of local data channel application to both UE
Up

6.2.10.2  Generating SDP offer |R17|p. 73

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 [172]. 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.
Up

6.2.10.3  Generating SDP answer |R17|p. 73

An answering DCMTSI client in terminal may accept an SDP offer with data channel as described by [172].
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 [172]. 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 [172]. 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 …).
Up

6.2.10.4  Receiving SDP answer |R17|p. 74

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.
Up

6.2.11  Still Images |R17|p. 74

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 ITT4RT client if not understood. The parameters have the following semantics:
item_count: provides the number of images in the corresponding image collection or image sequence. 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 desciption 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.
Up

6.3  Session control proceduresp. 74

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 [81] 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.
Up

Up   Top   ToC