Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.114  Word version:  19.0.0

Top   Top   Up   Prev   None
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.6.4…   Y.6.5…   Y.7… 
Y.7 Media transport  Y.7.1 RTP  Y.7.2 RTCP  Y.8 SDP Examples (informative)  Y.9  Recommended audio mixing gains  Y.9.1 RTP header extension for audio mixing gain  Z Computation of b=AS for IVAS  Z.1 General  Z.2 Procedure for computing the bandwidth  AA IANA registration information for Data Channel Sub-protocols  AA.1 Introduction  AA.2 HTTP  AA.3 MPEG Scene Description  AB  IANA registration information for media feature tags  AB.1 Introduction  AB.2 g.3gpp.dc-mux  $ Change history 

 

Y.7  Media transport  p. 501

Y.7.1  RTP  p. 501

RTP signaling impacts are FFS.

Y.7.2  RTCP  p. 501

When viewport-dependent processing (VDP) of 360-degree video is successfully negotiated between the ITT4RT-Tx client and ITT4RT-Rx client as per the SDP-based procedures described in clause Y.6.2, the RTCP feedback (FB) message type 'Viewport' shall carry requested viewport information during the RTP transmission of media signalled from the ITT4RT-Rx client to the ITT4RT-Tx client.
The signalling of 'Viewport' requests shall use RTCP feedback messages as specified in RFC 4585. The RTCP feedback message is identified by PT (payload type) = PSFB (206) which refers to payload-specific feedback message. FMT (feedback message type) shall be set to the value assigned by IANA for Viewport feedback messages. The IANA registration information for the FMT value for 'Viewport' is provided in Annex R.3 of TS 26.114. The RTCP feedback method may involve signalling of viewport information in both of the immediate feedback and early RTCP modes.
The FCI (feedback control information) format for Viewport shall be as follows. The FCI shall contain exactly one viewport. The signalled desired viewport information in the RTCP feedback message for 'Viewport' is composed of the following parameters (as defined as shape type value equal to 0 in clause 7.5.6 of ISO/IEC 23090-2 [179]):
  • Viewport_azimuth: Specifies the azimuth of the centre point of the sphere region corresponding to the requested viewport in units of 2−16 degrees relative to the global coordinate axes expressed in signed 32-bit integer format, in the range of −180 * 216 to 180 * 216 − 1, inclusive..
  • Viewport_elevation: Specifies the elevation of the centre point of the sphere region corresponding to the requested viewport in units of 2−16 degrees relative to the global coordinate axes expressed in signed 32-bit integer format, in the range of −90 * 216 to 90 * 216, inclusive.
  • Viewport_tilt: Specifies the tilt angle of the sphere region corresponding to the requested viewport, in units of 2−16 degrees, relative to the global coordinate axes expressed in signed 32-bit integer format, in the range of −180 * 216 to 180 * 216 − 1, inclusive.
  • Viewport_azimuth_range: Specifies the azimuth range of the sphere region corresponding to the requested viewport through the centre point of the sphere region in units of 2-16 degrees expressed in unsigned 32-bit integer format, in the range of 0 to 180 * 216, inclusive.
  • Viewport_elevation_range: Specifies the elevation range of the sphere region corresponding to the requested viewport through the centre point of the sphere region in units of 2−16 degrees expressed in unsigned 32-bit integer format, in the range of 0 to 180 * 216, inclusive.
The RTCP feedback message for 'Viewport' shall contain all of the parameters Viewport_azimuth, Viewport_elevation, Viewport_tilt, Viewport_azimuth_range and Viewport_elevation_range. The values for the each of the parameters Viewport_azimuth, Viewport_elevation, Viewport_tilt, Viewport_azimuth_range and Viewport_elevation_range shall each be indicated using four bytes.
The FCI for the RTCP feedback message for 'Viewport' shall follow the following format: 
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Viewport_azimuth                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Viewport_elevation                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Viewport_tilt                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Viewport_azimuth_range                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Viewport_elevation_range                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For each 4-byte indication of the Viewport_azimuth, Viewport_elevation, Viewport_tilt, Viewport_azimuth_range and Viewport_elevation_range, the bytes will be ordered in the order of importance such that high bytes shall be followed by the low bytes, where the highest byte holds the most significant bits and lowest byte holds the least significant bits.
Up

Y.8  SDP Examples (informative)  p. 502

An example SDP offer for multiple 360-degree video is shown in Table Y.8.1.
SDP offer 
; 1st conference room @ conference location
;
m=video 49144 RTP/AVP 98 100
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:main
 ; indicates this m-line is from the main source from the conference location
a=rtpmap:98 H265/90000
 ; 360 video
a=3gpp_360video:98…
a=rtpmap:100 H265/90000
 ; 2D video
;
; 2nd conference room @ conference location
;
m=video 49154 RTP/AVP 102 104
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:alt
 ; indicates this m-line is from an alt source from the conference location
a=rtpmap:102 H265/90000
 ; 360 video
a=3gpp_360video:102…
a=rtpmap:104 H265/90000
 ; 2D video
;
; Capture of a remote participant
;
m=video 49164 RTP/AVP 106 108
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:106 H265/90000
 ; 2D video
a=rtpmap:108 H265/90000
 ; 360 video
a=3gpp_360video:108…
An example SDP offer for multiple 360-degree video with group restrictions is shown in Table Y.8.2.
SDP offer 
a=itt4rt_group: D G H / E F H / H G I
 ; create multiple groups at MRF,
 ; each group between a different 360 video from a certain source,
 ; and 2D videos from other sources/
;
; 360 video of 1st conference room @ conference location
;
m=video 49144 RTP/AVP 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:main
 ; indicates this m-line is from the main source from the conference location
a=rtpmap:98 H265/90000 /*360 video*/
a=3gpp_360video:98…
a=mid=D
;
; 2D video of 1st conference room @ conference location
;
m=video 49154 RTP/AVP 100
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:main
 ;indicates this m-line is from the main source from the conference location
a=rtpmap:100 H265/90000 ; 2D video
a=3gpp_overlay:100… ; optional attribute
a=mid=E
;
; 360 video of 2nd conference room @ conference location
;
m=video 49164 RTP/AVP 102
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:alt
 ; indicates this m-line is from an alt source from the conference location
a=rtpmap: 102 H265/90000 ;360 video
a=3gpp_360video:98…
a=mid=F
;
; 2D video of 2nd conference room @ conference location
;
m=video 49174 RTP/AVP 104
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=content:alt
 ; indicates this m-line is from an alt source from the conference location
a=rtpmap:100 H265/90000 ; 2D video
a=3gpp_overlay:104… ; optional attribute
a=mid=G
;
; 2D video capture of a remote participant
;
m=video 49164 RTP/AVP 106
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:106 H265/90000 ; 2D video
a=3gpp_overlay:100… : optional attribute
a=mid=H
;
; 3D capture of a remote participant
;
m=video 49164 RTP/AVP 108
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:950
b=RS:0
b=RR:5000
a=rtpmap:108 H265/90000 ; 360 video
a=3gpp_360video:108…
a=mid=I
Up

Y.9  Recommended audio mixing gains  p. 503

An ITT4RT-Tx client may specify recommended gains for mixing of its transmitted audio streams and update these recommended gains during a session. An ITT4RT-Rx client may or may not use such recommended mixing gains to scale the audio streams prior to mixing.
An ITT4RT-Tx client may for example send the recommended mixing gains r0, r1, .., rN for the audio sources a0 (360 video) and a1, a2, .., aN (overlay videos) of that sender to recommend a mix at the receivers to be r0*a0+r1*a1+……+rN*aN.
If an ITT4RT-Rx client negotiated to receive recommended audio mixing gains and the ITT4RT-Tx client chooses to send these mixing gains, the ITT4RT-Tx client shall indicate each audio mixing gain value to the ITT4RT-Rx client using RTP header-extensions (see clause Y.9.1).
Up

Y.9.1  RTP header extension for audio mixing gain  p. 504

The format for sending a recommended audio mixing gain using the RTP header extension shall be as follows: 
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |  ID   | len=0 |audio-mixing-gain| 
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Audio mixing gain using One-Byte Header Format
The 4-bit ID is the local identifier of this element. The 4-bit length is the number, minus one, of data bytes of this header extension element following the one-byte header. The URI for declaring the audio mixing gain header extension in a Session Description Protocol (SDP) extmap attribute (RFC 5285) and mapping it to a local identifier is: 
urn:3gpp:audio-mixing-gain
The audio mixing gain is expressed in dB as a signed integer in the range "-127" to "0" (hence the numerical values directly represent the gain in dB). A value of "-128" indicates muting the channel. The meaning of positive values other than 0 is undefined and shall be ignored if received.
An ITT4RT-Tx client may repeat the header extension over multiple RTP packets to improve the likelihood of successful transmission as described in (RFC 8285). The number of header extension transmissions (for the same recommended mixing gain) should therefore depend on the probability of delivery.
Up

Z  Computation of b=AS for IVAS |R18|  p. 504

Z.1  General  p. 504

This Annex contains examples of computing b=AS for the IVAS codec when ptime=20. In these examples, it is assumed that no extra bandwidth is allocated for redundancy.

Z.2  Procedure for computing the bandwidth  p. 504

The bandwidth is calculated using the following procedure when no extra bandwidth is allocated for redundancy:
  1. Use the highest negotiated bitrate for the IVAS codec included in the SDP. Use ibr or ibr-recv parameters, if specified.
  2. Add bandwidth needed for PI data. Use pi-br or pi-br-recv parameters, if specified.
  3. Add bandwidth needed for IP, UDP and RTP headers assuming 50 frames per second: 16 kbps for IPv4 and 24 kbps for IPv6.
  4. Add bandwidth needed for RTCP.
  5. The b=AS bandwidth is the sum of the above listed bitrates after rounding up to nearest integer kbps.
If the SDP includes multiple codecs and/or configurations, the bandwidth is calculated for each configuration and the b=AS bandwidth is set to the highest of the bandwidths.
Up

AA  IANA registration information for Data Channel Sub-protocols |R18|  p. 506

AA.1  Introduction  p. 506

This Annex provides the data channel sub-protocol registration information that is referenced from the WebSocket sub-protocol name registry by IANA at https://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name.

AA.2  HTTP  p. 506

The subprotocol Identifier is:
http
The subprotocol Common Name is:
http
The subprotocol is defined in the specification:
3GPP TS 26.114, IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction
A short phrase describing the function of the subprotocol:
A UTF-8 encoded HTTP/1.1 compatible protocol over data channel.
Associated attributes:
None.
Contact information for the organization or person making the registration
3GPP Specifications Manager
3gppContact@etsi.org
+33 (0)492944200
Up

AA.3  MPEG Scene Description  p. 506

The subprotocol Identifier is:
mpeg-sd
The subprotocol Common Name is:
mpeg-sd
The subprotocol is defined in the specification:
3GPP TS 26.114, IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction
A short phrase describing the function of the subprotocol:
A UTF-8 encoded JSON-formatted protocol for the exchange of MPEG-I scene description and scene description updates.
Associated attributes:
None.
Contact information for the organization or person making the registration
3GPP Specifications Manager
3gppContact@etsi.org
+33 (0)492944200
Up

AB  IANA registration information for media feature tags |R19|  p. 508

AB.1  Introduction  p. 508

This Annex provides the media feature tag registration information that is referenced from the IANA registry at https://www.iana.org/assignments/media-feature-tags/media-feature-tags.xhtml.

AB.2  g.3gpp.dc-mux  p. 508

To: iana@iana.org
Subject: Registration of media feature tag g.3gpp.dc-mux
Media feature tag name: g.3gpp.dc-mux
Summary of the media feature indicated by this feature tag:
Support of multiplexing multiple IMS application data channels from different data channel applications on a single SDP media description, resulting in use of multiple a=3gpp-req-app SDP attributes with different application-id tag values. Also, support of multiplexing IMS bootstrap data channels from both local network and remote network bootstrap content sources on a single SDP media description.
Values appropriate for use with this feature tag:
The feature tag is Boolean and may have values of TRUE or FALSE, where the presence of the media feature tag implies a value of TRUE. A value of TRUE indicates an available capability. A value of FALSE indicates the capability is not available.
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:
IMS Multimedia Telephony as described by 3GPP TS 24.173, 3GPP TS 24.229 and 3GPP TS 26.114, used with SIP/SDP signalling and related capability negotiation.
Related standards or documents:
3GPP TS 26.114
Security considerations:
Privacy concerns, related to exposure of personal information:
The endpoint can be identified as a data channel-capable IMS endpoint with DC multiplexing capability, which is also indicated by other characteristic information in SIP and SDP protocols, so any additional concern from this media feature tag is minor.
Denial of service concerns related to consequences of specifying incorrect values:
Incorrectly including the media feature tag means it may receive SDP offers using DC multiplexing without having capability to support it. This could lead to that some application DC will not be routed to the correct application internally in the receiving endpoint and/or the application DC may be ignored on reception.
Incorrectly omitting or removing the media feature tag means that no DC multiplexing will occur, and multiple, separate SDP media descriptions are instead used for bootstrap and/or application DC, increasing the SDP size. This could lead to increased call setup and call modification time, an increased amount of needed link layer connections, exception handling for excess SDP size and resource allocation failure for DC that exceed the available link layer resource limit.
Additional information:
Related feature tags:
+sip.app.subtype=webrtc-datachannel
g.3gpp.datachannel
Related media types or data formats:
Application media type with format webrtc-datachannel
Name(s) & email address(es) of person(s) to contact for further information:
Contact Name: 3GPP Specifications Manager
Contact Email Address: 3gppContact@etsi.org
Intended usage: COMMON
Author/Change controller:
3GPP TSG SA Working Group 4.
Up

$  Change history  p. 510

Up   Top