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
|
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.
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 a new data channel application retrieved via 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 they also terminate on different endpoints, e.g., on a server and on the remote UE, hence they are offered as a separate m= lines with different QoS requirements. 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. The application using these data channels is identified by the
"a=3gpp-req-app" lines which also indicates that the two data channels are intended for communication with different end points, via the different
"adc-stream-id-endpoint" parameter values, e.g., a server versus the remote UE.
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:7216 max-retr=5;label="low loss"
a=3gpp-req-app:"application1";7216-UE
a=3gpp-qos-hint:loss=0.01;latency=100
m=application 52724 UDP/DTLS/SCTP webrtc-datachannel
b=AS:1000
a=candidate:1 1 UDP 2130706431 192.0.2.156 52724 typ host
a=ice-ufrag:3cD2
a=ice-pwd: YH75Fviy6338Vbrhrlrsct
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:23:56
a=tls-id: cd3bea56dced0f35e256
a=dcmap:38754 max-time=150;label="low latency"
a=3gpp-req-app:"application1";38754-Server
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
|
The
"a=3gpp-req-app" lines in
Table A.17.6 allow the remote UE to (re-)answer and accept the two new data channels for the application as
Table A.17.8 illustrates.
Table A.17.8 also suggest that the network used the
"adc-stream-id-endpoint" values and resolved that the second
"adc-stream-id-endpoint" is to be a server and provided its IP address on the corresponding media description.
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:77:22
a=tls-id: cd3bea56dced0f35f156
a=dcmap:10 subprotocol="http"
m=application 62347 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
b=AS:500
a=candidate:1 1 UDP 2130706431 192.0.2.126 62347 typ host
a=ice-ufrag:3pD2
a=ice-pwd:YH75Fviy6338Vbrhrlrgb2
a=max-message-size:1024
a=sctp-port:5120
a=setup:passive
a=fingerprint:SHA-1 BC:8A:99:A0:E3:28:CA:B3:09:20:1B:FD:21:D5:AC:B6:F3:5E:CC:EE
a=tls-id: cd3bea56dced0f35792e
a=dcmap:7216 max-retr=5;label="low loss"
a=3gpp-req-app:"application1";7216-UE
a=3gpp-qos-hint:loss=0.01;latency=100
m=application 62357 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.126
b=AS:500
a=candidate:1 1 UDP 2130706431 192.0.2.126 62357 typ host
a=ice-ufrag:3cBe
a=ice-pwd:YH75Fviy6338Vbrhrlhrtl
a=max-message-size:1024
a=sctp-port:5130
a=setup:passive
a=fingerprint:SHA-1 BC:8A:99:A0:E3:28:CA:B3:09:20:1B:FD:21:D5:AC:B6:F3:5E:76:34
a=tls-id: cd3bea56dced0f35514f
a=dcmap:38754 max-time=150;label="low latency"
a=3gpp-req-app:"application1";38754-Server
a=3gpp-qos-hint:loss=0.01;latency=100
|
Table A.17.9 demonstrates an example SDP offer with data channel media stream supporting SDP direction attribute defined in
clause 6.2.10. In this example, the offering part includes the SDP direction attribute
"a=inactive" to indicate the corresponding data channel media stream is to be suspended
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:1001 subprotocol="http"
a=inactive
|
Table A.17.10 demonstrates an example SDP offer with data channel media stream supporting SDP direction attribute defined in
clause 6.2.10. In this example, the offering part include the SDP direction attribute
"a=sendrecv" to indicate the suspended data channel media stream is to be resumed.
SDP offer |
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:1001 subprotocol="http"
a=sendrecv
|
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
|
These examples show SDP offers and answers for speech sessions where IVAS is negotiated. These SDP offer and answer examples are designed to highlight the respective area that is being described and should therefore not be considered as complete SDP offers and answers.
The SDP offers below can be used by MTSI client in terminal, depending on the access technology or the number of audio channels.
When the access technology is unknown to MTSI client in terminal, the SDP offer below can be used to initiate a speech session. In this example, RTP Payload Type 96 is defined for IVAS, RTP Payload Type 97 is defined for EVS, and two sets of RTP Payload Types, 98 and 99, and 100 and 101 are defined for AMR-WB and AMR respectively.
SDP offer |
m=audio 49152 RTP/AVP 96 97 98 99 100 101
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:556
b=RS:0
b=RR:2000
a=rtpmap:96 IVAS/16000/1
a=fmtp:96 cf=OSBA,OMASA,MC,ISM,SBA,Stereo; ibr=512; pi-types=xxx; pi-br=20; max-red=220
a=rtpmap:97 EVS/16000/1
a=fmtp:97 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
|
Comments:
The MTSI client in terminal IVAS with up to 512 kbps and all EVS codecs modes, for both sending and receiving directions. For IVAS, all audio bandwidths from wideband to fullband are offered but no parameter is needed since this is default when the ibw parameter is not included. PI date is also offered for both directions with up to 20 kbps. All audio bandwidths are allowed for both IVAS and EVS. For the EVS mode in IVAS, all EVS configuration parameters use their default values.
The clock rate of IVAS is set to 16 kHz.
The media level bandwidth (b=AS) is calculated for the highest offered bitrate of IVAS, 512 kbps, and including 20 kbps for PI data, and then adding 24 kbps for IPv6 overhead, resulting in 556 kbps.
The SDP answers below can be used by MTSI client in terminal, depending on access technology or service policy. It is assumed that an SDP offer such as described in
Table A.19.1 is received.
In this example, the MTSI client in terminal includes only the IVAS codec in the SDP answer.
SDP answer |
m=audio 49152 RTP/AVPF 96
a=acfg:1 t=1
b=AS:172
b=RS:0
b=RR:2000
a=rtpmap:96 IVAS/16000/1
a=fmtp:96 cf=Stereo; ibr=128; pi-types=xxx; pi-br=20; max-red=220
a=ptime:20
a=maxptime:240
|
Comments:
For IVAS, stereo at 128 kbps is selected for the session, while all other the configuration parameters are the same as in the received SDP offer.
The media level bandwidth (b=AS) is calculated by adding 128 kbps for IVAS, 20 kbps for PI data and adding 24 kbps for IPv6.