Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 26.114  Word version:  18.5.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.6.4…   Y.6.5…   Y.7…

 

A.15  SDP offers and answers with ANBR capability signaling |R16|p. 303

Table A.15.1 demonstrates an example SDP offer with Access Network Bitrate Recommendation (ANBR) capability signalling defined in clause 6.2.9 for speech. The offer for ANBR capability signaling is indicated in the last line via the SDP attribute 'anbr'.
SDP offer
m=audio 49152 RTP/AVP 97 98 99 100 101
b=AS:42
b=RS:0
b=RR:2000
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:97 EVS/16000/1
a=fmtp:97 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 mode-change-capability=2; max-red=220
a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-change-capability=2; max-red=220
a=rtpmap:101 AMR/8000/1
a=fmtp:101 mode-change-capability=2; max-red=220; octet-align=1
a=ptime:20
a=maxptime:240
a=anbr
An example SDP answer is shown in Table A.15.2, where the ANBR capability signalling is also supported by the answerer, as indicated by the last line.
SDP offer
m=audio 49152 RTP/AVPF 97
b=AS:30
b=RS:0
b=RR:2000
a=acfg:1 t=1
a=rtpmap:97 EVS/16000/1
a=fmtp:97 br=5.9-13.2; bw=nb-wb; mode-set=0,1,2; max-red=220
a=ptime:20
a=maxptime:240
a=anbr
Table A.15.3 demonstrates another example SDP offer with ANBR capability signalling, this time for video.
SDP offer
m=video 49154 RTP/AVP 98 97 100 99
b=AS:690
b=RS:0
b=RR:5000
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KAHpWgNQ9oB/U=,aM46gA==
a=imageattr:100 send [x=848,y=480] recv [x=848,y=480]
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:99 send [x=320,y=240] recv [x=320,y=240]
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=848,y=480] recv [x=848,y=480]
a=rtpmap:97 H265/90000
a=fmtp:97 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:97 send [x=320,y=240] recv [x=320,y=240]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=anbr
The corresponding example SDP answer is shown in Table A.15.4, where the ANBR capability signalling is also supported by the answerer, as indicated by the last line.
SDP answer
m=video 49156 RTP/AVPF 98
b=AS:690
b=RS:0
b=RR:5000
a=acfg:1 t=1
a=rtpmap:98 H265/90000
a=fmtp:98 profile-id=1; level-id=93; \
   sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBaLAUg; \
   sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBaoAaiAeFlLktIvQB3CAQQ; \
   sprop-pps=RAHAcYDZIA==
a=imageattr:98 send [x=848,y=480] recv [x=848,y=480]
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
a=anbr
Up

A.16  SDP offers and answers with QoS hint signalling |R16|p. 304

Table A.16.1 demonstrates an example SDP offer with QoS hint signalling defined in clause 6.2.7.4. The offer for QoS hint signalling is indicated in the last line via the SDP attribute '3gpp-qos-hint'.
SDP offer
m=video 43200 RTP/AVP 100
b=AS:15000
b=RS:0
b=RR:2500
a=pcfg:1 t=1
a=rtpmap:100 H265/90000
a=fmtp:100 profile-id=1;level-id=153
a=imageattr:100 send [x=3840,y=2160]
a=label:flus
a=sendonly
a=3gpp-qos-hint:loss=0.00001;latency=300
An example SDP answer is shown in Table A.16.2, where the QoS hint signalling is also supported by the answerer, as indicated by the last line.
SDP answer
m=video 43200 RTP/AVPF 100
b=AS:15000
b=RS:0
b=RR:2500
a=acfg:1 t=1
a=rtpmap:100 H265/90000
a=fmtp:100 profile-id=1;level-id=153
a=imageattr:100 recv [x=3840,y=2160]
a=label:flus
a=recvonly
a=3gpp-qos-hint:loss=0.00001;latency=300
Table A.16.3 demonstrates an example SDP offer with QoS hint signalling defined in clause 6.2.7.4, using explicit split of the end-to-end values. The offer suggests itself to use less than half of the end-to-end loss, but more than half of the end-to-end latency in the SDP attribute '3gpp-qos-hint'.
SDP offer
m=video 43200 RTP/AVP 100
b=AS:15000
b=RS:0
b=RR:2500
a=pcfg:1 t=1
a=rtpmap:100 H265/90000
a=fmtp:100 profile-id=1;level-id=153
a=imageattr:100 send [x=3840,y=2160]
a=label:flus
a=sendonly
a=3gpp-qos-hint:loss=0.00002/local:0.000005;latency=600/local:400
Table A.16.4 demonstrates another example SDP answer where the QoS hint signalling is also supported by the answerer, but where neither the desired QoS hint end-to-end values nor the QoS hint split values from the SDP offer can be supported and are changed in the SDP answer.
SDP answer
m=video 43200 RTP/AVPF 100
b=AS:15000
b=RS:0
b=RR:2500
a=acfg:1 t=1
a=rtpmap:100 H265/90000
a=fmtp:100 profile-id=1;level-id=153
a=imageattr:100 recv [x=3840,y=2160]
a=label:flus
a=recvonly
a=3gpp-qos-hint:loss=0.1;latency=500/local:100
The resulting loss hint is 0.05% for both SDP offerer and SDP answerer (half of the provided end-to-end value), which is a significant relaxation in loss rate compared to the offer in Table A.16.3 that might not be sufficient to provide an acceptable user experience. The resulting latency hint is 400 ms (500-100) for the SDP offerer and 100 ms for the SDP answerer, which is stricter end-to-end than the offer in Table A.16.3, but the answerer takes on the stricter latency and leaves the offerer part of the split from the offer (400 ms) unmodified.
Up

A.17  SDP offers and answers with data channel capability signalling |R16|p. 306

The ellipsis ("...") in the examples in this clause is not part of the SDP but indicates possible presence of other media descriptions in addition to the ones shown in the examples.
Table A.17.1 demonstrates an example SDP offer with data channel capability signalling for the "bootstrap" data channel defined in clause 6.2.10. The offering part is an ICE Lite agent, indicated by "a=ice-lite" on SDP session level (i.e., before first m= line), and thus only offers host candidates, in this example a single host candidate aligned with address information on the corresponding m= and c= lines.
SDP offer
a=ice-options:ice2
a=ice-lite
...
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel 
c=IN IP4 192.0.2.156
b=AS:500
a=candidate:1 1 UDP 2130706431 192.0.2.156 52718 typ host
a=ice-ufrag:8hhY
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=max-message-size:1024
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id: abc3de65cddef001be82
a=dcmap:0 subprotocol="http"
An example SDP answer is shown in Table A.17.2, where the data channel capability signalling from Table A.17.1 is also supported and accepted by the answerer, as indicated by the non-zero port on the m= line. The answering part is an ICE Lite agent, indicated by "a=ice-lite" on SDP session level, and only supports ICE according to the predecessor ICE specification to RFC 8839 as indicated by no "a=ice-options:ice2" being included on SDP session level.
SDP answer
a=ice-lite
...
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel 
c=IN IP4 192.0.2.1
b=AS:500 
a=candidate:1 1 UDP 2130706431 192.0.2.1 52718 typ host
a=ice-ufrag:9uB6
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=max-message-size:1024
a=sctp-port:5002
a=setup:passive
a=fingerprint:SHA-1 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id: dcb3ae65cddef0532d42
a=dcmap:0 subprotocol="http"
Table A.17.3 demonstrates an example SDP offer with multiple possible data channel application sources for the "bootstrap" data channel defined in Table 6.2.10.1-2. In this example, the offering part supports full ICE, indicated by no "a=ice-lite" on SDP session level.
SDP offer
a=ice-options:ice2
...
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel 
c=IN IP6 fe80::6676:baff:fe9c:ee4a
b=AS:500
a=candidate:1 1 UDP 2130706431 fe80::6676:baff:fe9c:ee4a 52718 typ host
a=ice-ufrag:8hhY
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=max-message-size:1024
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id: abc3de65cddef001be82
a=dcmap:0 subprotocol="http"
a=dcmap:10 subprotocol="http"
a=dcmap:100 subprotocol="http"
a=dcmap:110 subprotocol="http"
An example SDP answer is shown in Table A.17.4, where only one of the data channel application sources from the offer in Table A.17.3 is accepted by the answerer, removing the other a=dcmap lines.
Figure 6.2.10.1-3 in clause 6.2.10.1 may be used as illustration to this example, in which case UE A in that Figure would send the offer in Table A.17.3, and UE B would send the answer in Table A.17.4.
In this SDP answer, the answerer (UE B) only accepts stream ID 110 to receive the data channel application from the offerer (UE A), but UE B has rejected to use any other data channel application provider.
SDP answer
a=ice-options:ice2
a=ice-lite
...
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
b=AS:500
a=candidate:1 1 UDP 2130706431 192.0.2.1 52718 typ host
a=ice-ufrag:9uB6
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=max-message-size:1024
a=sctp-port:5002
a=setup:passive
a=fingerprint:SHA-1 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id: dcb3ae65cddef0532d42
a=dcmap:110 subprotocol="http"
Figure 6.2.10.1-3 in clause 6.2.10.1 may be used as illustration also to the example in Table A.17.5, in which case UE A in Figure 6.2.10.1-3 would send the offer in Table A.17.3, and the SDP answer sent back to UE A from the network would be the one in Table A.17.5.
In the SDP answer in Table A.17.5 sent from UE A's (local) network, it is accepting stream ID 10 that would be used by UE A to receive its own, chosen data channel application, corresponding to the data channel application sent to UE B in stream ID 110 based on the SDP answer in Table A.17.4 such that both UEs can use the same application. That application is however received through different stream IDs for UE A and UE B, as shown in Figure 6.2.10.1-3.
SDP answer
a=ice-options:ice2
a=ice-lite
...
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
b=AS:500
a=candidate:1 1 UDP 2130706431 192.0.2.1 52718 typ host
a=ice-ufrag:9uB6
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=max-message-size:1024
a=sctp-port:5010
a=setup:active
a=fingerprint:SHA-1 BC:8A:99:A0:E3:28:CA:B3:09:20:1B:FD:21:D5:AC:B6:F3:5E:45:AF
a=tls-id: cd3bea56dced0f35d224
a=dcmap:10 subprotocol="http"
Table A.17.6 demonstrates an example SDP (re-)offer that adds two non-bootstrap data channel streams used by the data channel application in the bootstrap data channel in Table A.17.5. The data channel application streams (two in this example) desire specific loss and latency characteristics indicated by the "a=3gpp-qos-hint" line (see also Annex A.16) and are offered as a separate m= line due to having different QoS requirements and different destination (e.g. a peer UE) than the bootstrap data channel. The stream with ID 38754 has a strict latency requirement and data older than 150 ms will not be transmitted or re-transmitted. The stream with ID 7216 requires lower loss but can accept somewhat higher latency than stream ID 38754 and therefore allows at most 5 SCTP-level retransmissions.
SDP offer
c=IN IP4 192.0.2.156
a=ice-options:ice2
a=ice-lite
...
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel
b=AS:500
a=candidate:1 1 UDP 2130706431 192.0.2.156 52718 typ host
a=ice-ufrag:8hhY
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=max-message-size:1024
a=sctp-port:5000
a=setup: actpass
a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id: abc3de65cddef001be82
a=dcmap:10 subprotocol="http"
m=application 52720 UDP/DTLS/SCTP webrtc-datachannel
b=AS:1000
a=candidate:1 1 UDP 2130706431 192.0.2.156 52720 typ host
a=ice-ufrag:9uB6
a=ice-pwd: YH75Fviy6338Vbrhrlp8Yh
a=max-message-size:1024
a=sctp-port:5000
a=setup: actpass
a=fingerprint:SHA-1 BC:8A:99:A0:E3:28:CA:B3:09:20:1B:FD:21:D5:AC:B6:F3:5E:45:AF
a=tls-id: cd3bea56dced0f35d224
a=dcmap:38754 max-time=150;label="low latency"
a=dcmap:7216 max-retr=5;label="low loss"
a=3gpp-qos-hint:loss=0.01;latency=100
Table A.17.7 demonstrates an example SDP offer that is transferred from User A's network (the originating network) to User B's network (the terminating network). There are two bootstrap data channels with stream ID 100 in the SDP offer, one is marked by "a=3gpp-bdc-used-by:sender" line which means it is established between User A and User B's network, the other is marked by "a=3gpp-bdc-used-by:receiver" line which means it is established between User A's network and User B.
SDP offer
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel
b=AS:500
a=max-message-size:1024
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id: abc3de65cddef001be82
a=dcmap:100 subprotocol="http"
a=3gpp-bdc-used-by:sender
 
m=application 52722 UDP/DTLS/SCTP webrtc-datachannel
b=AS:500
a=max-message-size:1024
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 BC:8A:99:A0:E3:28:CA:B3:09:20:1B:FD:21:D5:AC:B6:F3:5E:45:AF
a=tls-id: cd3bea56dced0f35d224
a=dcmap:100 subprotocol="http"
a=3gpp-bdc-used-by:receiver
Up

A.18  SDP offers and answers for ITT4RT |R17|p. 309

Table A.18.1 shows an example of an SDP offer for an ITT4RT session with a 360 video, 2 overlay streams, and a scene description.
SDP offer
v=0
o=ITT4RT 3413526809 0 IN IP4 server.example.com
s=Example of using AS in MTSI
c=IN IP4 aaa.bbb.ccc.ddd
b=AS:345
t=0 0
a=tcap:1 RTP/AVPF
a=itt4rt_group: 1 2 3
m=video 49154 RTP/AVP 99
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:5000
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=3gpp_360video: Stereo
a=mid:1
m=video 49154 RTP/AVP 99
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:5000
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=mid:2
a=3gpp_overlay:2 1 0,0,0,0,0,0,0,0,0,0
m=video 49154 RTP/AVP 99
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:5000
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=mid:3
a=3gpp_overlay:3 1 0,0,0,0,0,0,0,0,0,0
m=application 52718 UDP/DTLS/SCTP webrtc-datachannel
b=AS:500
a=sctp-port:5002
a=max-message-size:1024
a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tls-id: abc3de65cddef001be82
a=dcmap:110 subprotocol="mpeg-sd"
a=mid:4
Up

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

AA.1  Introductionp. 310

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  HTTPp. 310

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 Descriptionp. 310

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

Up   Top   ToC