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:  18.8.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… 
T SDP examples for Multi-party Multimedia Conference Media Handling  T.1 General  T.1.1 Introduction  T.1.2 Quality of Service examples  T.2 MSMTSI video offer/answer examples  T.2.1 MSMTSI offer/answer towards an MTSI client  T.2.2 MSMTSI answer from an MSMTSI MRF  T.2.3 MSMTSI answer from an MSMTSI client in terminal  T.2.4 MSMTSI simulcast offer using a single payload type  T.2.5 MSMTSI simulcast offer using two codecs  T.3 MSMTSI audio offer/answer examples  T.3.1 MSMTSI offer with multi-stream audio support  T.3.2 MSMTSI answer with multi-stream audio support  T.3.3 MSMTSI CCCEx SDP offer/answer example  T.3.3a MSMTSI offer/answer examples using the compact CCC SDP attribute  T.3.4 SIP OPTIONS request for multi-stream audio support 
...

 

T  SDP examples for Multi-party Multimedia Conference Media Handling |R13|  p. 436

T.1  General  p. 436

T.1.1  Introduction |R14|  p. 436

This Annex gives a few examples of media portions from possible SDP offers and answers involving an MSMTSI client and/or MSMTSI MRF. It is not feasible to cover all possible variants of different communication scenarios and MSMTSI capabilities and hence these examples should be regarded as just a few examples of many possible alternatives. For brevity, these examples do not make use of all functionality (like robustness etc) or list all codecs that could be used in a real SDP offer/answer, and for the same reason also limits the number of supported streams compared to what could be used in a real SDP offer/answer.
Up

T.1.2  Quality of Service examples |R14|  p. 436

This clause describes how the QoS bandwidth is reserved for MMCMH sessions based on the codec and bandwidth information in the SDP answer, the number of conference participants, and the topology of the multi-party session.
When determining the QoS bandwidth to reserve for the MMCMH session, the SDP answer is examined for the following:
  • When simulcast is included, the bandwidth reserved for the transmission of the media (on either the uplink or downlink) is enough to cover the simulcast. If multiple media formats are sent concurrently then the reserved bandwidth is enough to carry the sum of their bandwidth requirements. If media formats are sent alternatively, then the reserved bandwidth is enough to carry the bandwidth requirements of the highest codec rate that can be used.
  • If multiple active media lines are included, the reserved bandwidth is enough to carry the sum of the bandwidth requirements of each active media line.
    Table T.0 provides examples of the QoS bandwidth that could be reserved for the example SDP answers listed in the rest of this Annex.
Table in Annex which has the example SDP answer Uplink GBR (kbps) Uplink MBR (kbps) Dowlink GBR (kbps) Downlink MBR (kbps) Comments
T.2452.5452.5Assumed PCC chose symmetric QoS for DL
T.321052590Assumed PCC chose symmetric QoS for DL
T.418651865Estimating QoS for MSMTSI terminal's links, assumed PCC chose symmetric QoS for DL
T.6118118133.5133.5Can not assume symmetric because simulcast is on uplink. Assuming GBR= MBR for speech, but can set GBR lower if PCRF looks at codec-specific parameters and determines the lowest operating rate of the codecs
T.9118118194194Can not assume symmetric because simulcast is on uplink. Assuming GBR= MBR for speech, but can set GBR lower if PCRF looks at codec-specific parameters and determines the lowest operating rate of the codecs
T.10118118133.5133.5Can not assume symmetric because simulcast is on uplink. Assuming GBR= MBR for speech, but can set GBR lower if PCRF looks at codec-specific parameters and determines the lowest operating rate of the codecs
Up

T.2  MSMTSI video offer/answer examples  p. 437

T.2.1  MSMTSI offer/answer towards an MTSI client  p. 437

This offer includes sending two different simulcast streams for the main video, receiving two thumbnail videos, both sending and receiving screenshare video, and has support for BFCP to control screenshare and (possibly) main video, which are all features that can be supported by MSMTSI but that are not supported by a regular MTSI client. All audio is omitted in this example, for brevity, but could be added according to the other examples (e.g., in clause T.3) in this annex.
Video levels are in this example aligned with the maximum size of the video stream, and the maximum receive bandwidth limit is set by the "b="-line rather than just implicitly by the video level bandwidth limit.
The main video is listed as the first video "m="-line and is also explicitly identified through "a=content:main".
One subsequent "m="-line is explicitly identified as screenshare video, using "a=content:slides".
The rest of the video "m="-lines indicate support for two additional, receive-only video thumbnails.
All video "m="-lines offer support for RTP level pause/resume, indicated through "a=rtcp-fb:* ccm pause". The "nowait" parameter is set, indicating that the MSMTSI client expects the RTP media streams to be sent point-to-point on RTP level. That can for example be either between MSMTSI clients in terminal, or between an MSMTSI client in terminal and an MSMTSI MRF. In either case, the "nowait" parameter indicates it is not expected that multiple receivers of the RTP streams are able to send RTCP back to request RTP level pause/resume.
Support for reduced-size RTCP (see clause 7.3.6 and RFC 5506) is offered for all video "m="-lines, to save bandwidth for RTCP feedback messages listed on "a=rtcp-fb"-lines.
BFCP support is offered with client role.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
SDP offer 
m=video 49154 RTP/AVPF 101 102
b=AS:1060
b=RS:0
b=RR:2500
a=rtpmap:101 H264/90000
a=rtpmap:102 H264/90000
a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=fmtp:102 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240]
a=imageattr:102 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \
     recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=rid:0 send pt=101
a=rid:1 send pt=102
a=rid:2 recv pt=101
a=simulcast:send 0;1 recv 2
a=content:main
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49156 RTP/AVPF 103
b=AS:800
b=RS:0
b=RR:2500
a=rtpmap:103 H264/90000
a=fmtp:103 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:103 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360]
a=content:slides
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49158 RTP/AVPF 104
b=AS:240
b=RS:0
b=RR:2500
a=rtpmap:104 H264/90000
a=fmtp:104 packetization-mode=0; profile-level-id=42e00c
a=imageattr:104 recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=recvonly
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49160 RTP/AVPF 105
b=AS:240
b=RS:0
b=RR:2500
a=rtpmap:105 H264/90000
a=fmtp:105 packetization-mode=0; profile-level-id=42e00c
a=imageattr:105 recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=recvonly
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=application 50324 TCP/BFCP *
a=floorctrl:c-only
a=setup:actpass
a=connection:new
SDP answer 
m=video 49154 RTP/AVPF 101
b=AS:450
b=RS:0
b=RR:2500
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=0; profile-level-id=42e00d; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==;
a=imageattr:101 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
m=video 0 RTP/AVPF 103
m=video 0 RTP/AVPF 104
m=video 0 RTP/AVPF 105
m=application 0 TCP/BFCP *
The answerer, being an MTSI client, knows of no MSMTSI features, but has correctly disabled all of them in the SDP answer, according to generic SDP offer/answer rules, keeping unsupported "m="-lines with port set to zero, leaving the session effectively identical to a regular MTSI session with a single video and mono audio.
Up

T.2.2  MSMTSI answer from an MSMTSI MRF  p. 439

This example assumes the same offer as in Table T.1, which is thus not repeated here, but the answerer is here an MSMTSI MRF, supporting all of the offered MSMTSI-specific features. All audio is omitted in this example, for brevity, but could be added according to any of the other examples in this annex.
Note that the "isFocus" tag, identifying this answer as an MRF, is included as part of SIP headers and is thus not visible in the SDP in this example.
The MSMTSI MRF accepts to receive the two offered simulcast streams for the main video. Then, the MSMTSI MRF can send video for the two supported thumbnails, and can also control both main video and screenshare video through BFCP.
It can be noted that the MSMTSI MRF needs to keep all payload type formats that it accepts to use for simulcast on the "m="-line in the answer.
The MSMTSI MRF is, by including the RTP-level "nowait" parameter on the "a=rtcp-fb:* ccm pause" line in the SDP answer, confirming that exchange of RTP level pause/resume messages will be point-to-point and no hold-off period will therefore be necessary when resuming paused streams (see RFC 7728).
Support for reduced-size RTCP (see clause 7.3.6 and RFC 5506) is accepted for all video "m="-lines, to save bandwidth for RTCP feedback messages listed on "a=rtcp-fb"-lines.
The "a=label" lines are added by the MSMTSI MRF to support identification of BFCP-controlled "m="-lines, relating BFCP floor identifications to "m="-lines through "a=floorid" lines under the BFCP "m="-line. In this example, both the main video and the screenshare video "m="-lines are floor controlled. The thumbnail videos are however not floor controlled, so there are no "a=label" lines for those "m="-lines.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
SDP answer 
m=video 49154 RTP/AVPF 101 102
b=AS:1300
b=RS:0
b=RR:2500
a=rtpmap:101 H264/90000
a=rtpmap:102 H264/90000
a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=fmtp:102 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240]
a=imageattr:102 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \
     recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=rid:0 recv pt=101
a=rid:1 recv pt=102
a=rid:2 send pt=101
a=simulcast:recv 0;1 send 2
a=content:main
a=label:m
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49156 RTP/AVPF 103
b=AS:800
b=RS:0
b=RR:2500
a=rtpmap:103 H264/90000
a=fmtp:103 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:103 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360]
a=content:slides
a=label:s
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49158 RTP/AVPF 104
b=AS:240
b=RS:0
b=RR:2500
a=rtpmap:104 H264/90000
a=fmtp:104 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:104 send [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=sendonly
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49160 RTP/AVPF 105
b=AS:240
b=RS:0
b=RR:2500
a=rtpmap:105 H264/90000
a=fmtp:105 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:105 send [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=sendonly
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=application 50324 TCP/BFCP *
a=floorctrl:s-only
a=floorid:1 mstrm:m
a=floorid:2 mstrm:s
a=confid:23984
a=userid:48249
a=setup:active
a=connection:new
Up

T.2.3  MSMTSI answer from an MSMTSI client in terminal  p. 441

This example assumes the same offer as in clause T.2, which is thus not repeated here, but the answerer is here an MSMTSI client in terminal, supporting all of the offered MSMTSI-specific features, although not all of them are feasible to use between MSMTSI clients in terminal. All audio is omitted in this example, for brevity, but could be added according to any of the other examples in this Annex.
Note that the "isFocus" tag is here not included as part of the SIP headers (compare to Annex T.3). This information is used by the answering MSMTSI client to construct an appropriate SDP answer.
The answering MSMTSI client has no reason to send any thumbnail videos to another MSMTSI client in terminal, and has thus disabled them. There is no need for simulcast, meaning that the simulcast attribute and the corresponding "a=rid" attributes are removed from the SDP and simulcast will not be used. It can however act as BFCP server and can also support simultaneous main video and screen sharing, which are both kept.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
SDP answer 
m=video 49154 RTP/AVPF 101
b=AS:1060
b=RS:0
b=RR:2500
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240]
a=content:main
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 49156 RTP/AVPF 103
b=AS:800
b=RS:0
b=RR:2500
a=rtpmap:103 H264/90000
a=fmtp:103 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:103 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360]
a=content:slides
a=label:10
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
m=video 0 RTP/AVPF 104
m=video 0 RTP/AVPF 105
m=application 50324 TCP/BFCP *
a=floorctrl:s-only
a=floorid:1 mstrm:10
a=confid:237
a=userid:278
a=setup:passive
a=connection:new
Up

T.2.4  MSMTSI simulcast offer using a single payload type |R14|  p. 442

This example offer is an excerpt of just the first "m=" block from the example in clause T.2.1 and effectively offers the same functionality, but does not make use of different payload types to distinguish the simulcast formats. Instead different "a=rid" constraints parameters are used. Because there is only a single format listed on the "m=" line containing the "a=simulcast" line, the "a=rid" lines contains constraints parameters (here max-width and max-height) to differentiate the simulcast formats.
SDP lines specifically interesting to this example are highlighted in bold, which would not be the case in an actual SDP.
SDP offer 
m=video 49154 RTP/AVPF 101
b=AS:1060
b=RS:0
b=RR:2500
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     [x=176,y=144] [x=224,y=176] [x=320,y=180] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     [x=176,y=144] [x=224,y=176] [x=320,y=180]
a=rid:0 send pt=101 max-width=1280;max-height=720
a=rid:1 send pt=101 max-width=320;max-height=180
a=rid:2 recv pt=101 max-width=1280;max-height=720
a=simulcast:send 0;1 recv 2
a=content:main
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
Up

T.2.5  MSMTSI simulcast offer using two codecs |R14|  p. 442

This example offer is an excerpt of just the first "m=" block from the example in clause T.2.1 and effectively offers the same functionality, but makes use of simulcast with different video codecs, H.264 and H.265, in addition to the simulcast used for main video thumbnail in clause T.2.1.
SDP lines specifically interesting to this example are highlighted in bold, which would not be the case in an actual SDP.
SDP offer 
m=video 49154 RTP/AVPF 101 102 103 104
b=AS:1960
b=RS:0
b=RR:2500
a=rtpmap:101 H265/90000
a=rtpmap:102 H264/90000
a=rtpmap:103 H265/90000
a=rtpmap:104 H264/90000
a=fmtp:101 profile-id=1; level-id=93; \
     sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwBdLAUg; \
     sprop-sps=QgEBAWAAAAMAgAAAAwAAAwBdoAKAgC0WUuS0i9AHcIBB; \
     sprop-pps=RAHAcYDZIA==
a=fmtp:103 profile-id=1; level-id=30; \
     sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwA8LAUg; \
     sprop-sps=QgEBAWAAAAMAgAAAAwAAAwA8oAoIDxZS5LSL0AdwgEE=; \
     sprop-pps=RAHAcYDZIA==;
a=fmtp:102 packetization-mode=0; profile-level-id=42e01f; \
     sprop-parameter-sets=Z0KADZWgUH6Af1A=,aM46gA==
a=fmtp:104 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=imageattr:101 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240]
a=imageattr:103 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \
     recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=imageattr:102 send [x=1280,y=720] [x=848,y=480] [x=640,y=360] [x=320,y=240] \
     recv [x=1280,y=720,q=0.6] [x=848,y=480] [x=640,y=360] [x=320,y=240]
a=imageattr:104 send [x=176,y=144] [x=224,y=176] [x=320,y=180] \
     recv [x=176,y=144] [x=224,y=176] [x=320,y=180,q=0.6]
a=rid:0 send pt=101
a=rid:1 send pt=103
a=rid:2 recv pt=101
a=rid:4 send pt=102
a=rid:5 send pt=104
a=rid:6 recv pt=102
a=simulcast:send 0;4;1;5 recv 2,6
a=content:main
a=rtcp-rsize
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=rtcp-fb:* ccm pause nowait
a=extmap:4 urn:3gpp:video-orientation
Up

T.3  MSMTSI audio offer/answer examples  p. 443

T.3.1  MSMTSI offer with multi-stream audio support  p. 443

This offer includes multi-stream audio, sending simulcast with multiple codecs for the main audio, receiving two additional audio participants for local rendering, and receiving codec simulcast for all received audio streams. All video is omitted in this example, for brevity, but could be added according to any of the other examples in this annex.
Three different codecs are offered as audio simulcast in the send direction, separated by semicolons. In the simulcast receive direction, a single stream is offered, explicitly accepting three different alternative simulcast formats, separated by comma, which means that the used audio codec (RTP payload format) is allowed to change from one RTP packet to the next.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
SDP offer 
m=audio 49152 RTP/AVP 98 97 99
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:98 EVS/16000/1
a=fmtp:98 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 send pt=97
a=rid:1 send pt=98
a=rid:2 send pt=99
a=rid:3 recv pt=97
a=rid:4 recv pt=98
a=rid:5 recv pt=99
a=simulcast:send 0;1;2 recv 3,4,5
m=audio 49154 RTP/AVP 101 102 103
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 recv pt=101
a=rid:7 recv pt=102
a=rid:8 recv pt=103
a=simulcast:recv 6,7,8
m=audio 49156 RTP/AVPF 104 105 106
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:104 EVS/16000/1
a=fmtp:104 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240 
a=rid:9 recv pt=104
a=rid:10 recv pt=105
a=rid:11 recv pt=106
a=simulcast:recv 9,10,11
Up

T.3.2  MSMTSI answer with multi-stream audio support  p. 444

This answer builds on the offer in Annex T.3.1, includes multi-stream audio, accepting to receive simulcast with multiple codecs for the main audio, sending two additional audio participants for local rendering, and sending codec simulcast for all received audio streams. All video is omitted in this example, for brevity, but could be added according to any of the other examples in this Annex.
The three different codecs from the offer are accepted as audio simulcast in the receive direction, separated by semicolons. In the simulcast send direction, a single stream is accepted, explicitly listing three different alternative simulcast formats, separated by comma, which means that the used audio codec (RTP payload format) may change from one RTP packet to the next.
As in Annex T.2.2, it can be noted that the MSMTSI MRF needs to keep all payload type formats that it accepts to use for simulcast on the "m="-line in the answer.
Blank lines are here added in the SDP for improved readability, but not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
SDP answer 
m=audio 49152 RTP/AVPF 98 97 99
b=AS:113
a=acfg:1 t=1
a=rtpmap:98 EVS/16000/1
a=fmtp:98 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 recv pt=97
a=rid:1 recv pt=98
a=rid:2 recv pt=99
a=rid:3 send pt=98
a=rid:4 send pt=97
a=rid:5 send pt=99
a=simulcast:recv 0;1;2 send 3,4,5
m=audio 49154 RTP/AVPF 101 102 103
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 send pt=101
a=rid:7 send pt=102
a=rid:8 send pt=103
a=simulcast:send 6,7,8
m=audio 49156 RTP/AVPF 104 105 106
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:104 EVS/16000/1
a=fmtp:104 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240 
a=rid:9 send pt=104
a=rid:10 send pt=105
a=rid=11 send pt=106
a=simulcast:send 9,10,11
Up

T.3.3  MSMTSI CCCEx SDP offer/answer example  p. 445

Table T.7 shows example concurrent codec combinations supported at the terminal. All video is omitted in this example, for brevity, but could be added according to any of the other examples in this Annex. As shown in Table T.7, the terminal may have identified three possible CCCEx combinations through profiles (shown for 6 participants). SDP offer examples from the terminal to the MRF for profile A is shown in Table T.8. The MSMTSI MRF may then send an SDP answer as shown using the simulcast attribute and multiple m-lines in Table T.9 enabling a multi-stream multiparty conference (among 6 participants).
Number of participants CCCEx combinations supported at the MSMTSI terminals A, B and C
N = 6 A. [Encoder/send: AMR, AMR-WB, EVS]
[Decoder/recv: 1 AMR, 1 AMR-WB, 3 EVS]
B. [Encoder/send: AMR-WB, EVS]
[Decoder/recv: 1 AMR-WB, 4 EVS]
C. [Encoder/send: AMR, EVS]
[Decoder/recv: 5 EVS]
SDP offer 
m=audio 49152 RTP/AVP 96 97 98
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 send pt=96
a=rid:1 send pt=97
a=rid:2 send pt=98
a=rid:3 recv pt=96
a=rid:4 recv pt=97
a=rid:5 recv pt=98
a=simulcast:send 0;1;2 recv 3,4,5
m=audio 49154 RTP/AVP 101 102 103
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 recv pt=101
a=rid:7 recv pt=102
a=rid:8 recv pt=103
a=simulcast:recv 6,7,8
m=audio 49156 RTP/AVP 104 105 106
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:104 EVS/16000/1
a=fmtp:104 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:9 recv pt=104
a=rid:10 recv pt=105
a=rid:11 recv pt=106
a=simulcast:recv 9,10,11
m=audio 49158 RTP/AVP 107 108
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:107 AMR-WB/16000/1
a=fmtp:107 mode-change-capability=2; max-red=220
a=rtpmap:108 AMR/8000/1
a=fmtp:108 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:12 recv pt=107
a=rid:13 recv pt=108
a=simulcast:recv 12,13
m=audio 49160 RTP/AVP 109
b=AS:29
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:109 AMR/8000/1
a=fmtp:109 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240 
a=rid:14 recv pt=109
a=simulcast:recv 14
SDP answer 
m=audio 49152 RTP/AVPF 96 97 98
b=AS:113
a=acfg:1 t=1
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 recv pt=96
a=rid:1 recv pt=97
a=rid:2 recv pt=98
a=rid:3 send pt=96
a=rid:4 send pt=97
a=rid:5 send pt=98
a=simulcast: recv 0;1;2 send 3,4,5
m=audio 49154 RTP/AVPF 101 102 103
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 send pt=101
a=rid:7 send pt=102
a=rid:8 send pt=103
a=simulcast:send 6,7,8
m=audio 49156 RTP/AVPF 105 106
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:10 send pt=105
a=rid:11 send pt=106
a=simulcast:send 10,11
m=audio 49158 RTP/AVPF 108
b=AS:29
a=acfg:1 t=1
a=sendonly
a=rtpmap:108 AMR/8000/1
a=fmtp:108 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:13 send pt=108
a=simulcast:send 13
m=audio 49160 RTP/AVPF 109
b=AS:29
a=acfg:1 t=1
a=sendonly
a=rtpmap:109 AMR/8000/1
a=fmtp:109 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240 
a=rid:14 send pt=109
a=simulcast:send 14
Table T.10 shows an example, where the MSMTSI MRF identifies that there are only four participants in the conference and it therefore disables the two "m="lines.
SDP answer 
m=audio 49152 RTP/AVPF 96 97 98
b=AS:113
a=acfg:1 t=1
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 recv pt=96
a=rid:1 recv pt=97
a=rid:2 recv pt=98
a=rid:3 send pt=96
a=rid:4 send pt=97
a=rid:5 send pt=98
a=simulcast:recv 0;1;2 send 3,4,5
m=audio 49154 RTP/AVPF 101 102 103
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=5.9-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 send pt=101
a=rid:7 send pt=102
a=rid:8 send pt=103
a=simulcast:send 6,7,8
m=audio 49156 RTP/AVPF 105 106
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:10 send pt=105
a=rid:11 send pt=106
a=simulcast:send 10,11
m=audio 0 RTP/AVP 108
m=audio 0 RTP/AVP 109
Up

T.3.3a  MSMTSI offer/answer examples using the compact CCC SDP attribute |R14|  p. 449

Table T.3a1 shows an example SDP offer using the compact ccc_list SDP attribute to simultaneously describe the three media configurations listed for N=6 in Table T.7. Note that the media configuration for the codec is broader than all the concurrent codec configurations that can be supported by the offering MSMTSI terminal. Similar to Table T.8, all video is omitted in this example for brevity, but could be added according to any of the other examples in this annex.
SDP offer 
a = ccc_list:EVS;AMR-WB;AMR|ENC:1;1;1:DEC:3,1,1| \
  ENC:1;1;0:DEC:4,1,0|ENC:1;0;1:DEC:5,0,0
m=audio 49152 RTP/AVP 96 97 98
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 send pt=96
a=rid:1 send pt=97
a=rid:2 send pt=98
a=rid:3 recv pt=96
a=rid:4 recv pt=97
a=rid:5 recv pt=98
a=simulcast:send 0;1;2 recv 3,4,5
m=audio 49154 RTP/AVP 101 102 103
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 recv pt=101
a=rid:7 recv pt=102
a=rid:8 recv pt=103
a=simulcast:recv 6,7,8
m=audio 49156 RTP/AVP 104 105 106
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:104 EVS/16000/1
a=fmtp:104 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:9 recv pt=104
a=rid:10 recv pt=105
a=rid:11 recv pt=106
a=simulcast:recv 9,10,11
m=audio 49158 RTP/AVP 107 108 109
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:107 EVS/16000/1
a=fmtp:107 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:108 AMR-WB/16000/1
a=fmtp:108 mode-change-capability=2; max-red=220
a=rtpmap:109 AMR/8000/1
a=fmtp:109 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
a=rid:12 recv pt=107
a=rid:13 recv pt=108
a=rid:14 recv pt=109
a=simulcast:recv 12,13,14
m=audio 49160 RTP/AVP 110,111,112
b=AS:42
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=recvonly
a=rtpmap:110 EVS/16000/1
a=fmtp:110 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:111 AMR-WB/16000/1
a=fmtp:111 mode-change-capability=2; max-red=220
a=rtpmap:112 AMR/8000/1
a=fmtp:112 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240 
a=rid:15 recv pt=110
a=rid:16 recv pt=111
a=rid:17 recv pt=112
a=simulcast:recv 15,16,17
An answering MSMTSI MRF that supports the ccc_list attribute may then send an SDP answer as shown Table T.x2, including the ccc_list attribute and using the simulcast attribute and multiple m-lines to enable a multi-stream multiparty conference among 6 participants. The included ccc_list attribute indicates the full capabilities of the MRF to concurrently switch multiple audio streams (10 EVS, 5 AMR-WB, 5 AMR-NB, etc…) towards the offering MSMTSI terminal eventhough the selected media configurations in the answer are only using a subset of the MRF's capabilities.
SDP answer 
a = ccc_list:EVS;AMR-WB;AMR|ENC:10,5,5:DEC:1;1;1
m=audio 49152 RTP/AVPF 96 97 98
b=AS:113
a=acfg:1 t=1
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:0 recv pt=96
a=rid:1 recv pt=97
a=rid:2 recv pt=98
a=rid:3 send pt=96
a=rid:4 send pt=97
a=rid:5 send pt=98
a=simulcast: recv 0;1;2 send 3,4,5
m=audio 49154 RTP/AVPF 101 102 103
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:101 EVS/16000/1
a=fmtp:101 br=13.2-24.4; bw=nb-swb; max-red=220
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:103 AMR/8000/1
a=fmtp:103 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:6 send pt=101
a=rid:7 send pt=102
a=rid:8 send pt=103
a=simulcast:send 6,7,8
m=audio 49156 RTP/AVPF 105 106
b=AS:42
a=acfg:1 t=1
a=sendonly
a=rtpmap:105 AMR-WB/16000/1
a=fmtp:105 mode-change-capability=2; max-red=220
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:10 send pt=105
a=rid:11 send pt=106
a=simulcast:send 10,11
m=audio 49158 RTP/AVPF 108
b=AS:29
a=acfg:1 t=1
a=sendonly
a=rtpmap:108 AMR/8000/1
a=fmtp:108 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240
a=rid:13 send pt=108
a=simulcast:send 13
m=audio 49160 RTP/AVPF 109
b=AS:29
a=acfg:1 t=1
a=sendonly
a=rtpmap:109 AMR/8000/1
a=fmtp:109 mode-change-capability=2; mode-set=0,2,4,7; max-red=220
a=ptime:20
a=maxptime:240 
a=rid:14 send pt=109
a=simulcast:send 14
Up

T.3.4  SIP OPTIONS request for multi-stream audio support |R14|  p. 451

This offer includes multi-stream audio, sending simulcast with multiple codecs for the main audio, receiving two additional audio participants for local rendering, and receiving codec simulcast for all received audio streams. All video is omitted in this example, for brevity, but could be added according to any of the other examples in this annex.
Blank lines are here added in the SDP for improved readability, but are not included in an actual SDP. SDP lines specifically interesting to this example are highlighted in bold, which would also not be the case in an actual SDP.
Table T.11 shows an example SIP OPTIONS request from an MRF or a conference initiator. Table T.12 shows an example SIP OPTIONS response from a conference participant to the MRF or the initiator. The SIP OPTIONS response includes the SDP Offer of the conference participant. From Table T.12, the conference participant can allow for three concurrent encoding and three concurrent decoding of audio streams.
SIP OPTIONS request 
OPTIONS sip:cccEx@mmcmh.com SIP/2.0
To: <sip:cccEx@mmcmh.com>
From: P1 <sip:p1@msmtsi.com>;tag=TR26980
Call-ID: abcdefgh
CSeq: 16384 OPTIONS
Max-Forwards: 100
Via: SIP/2.0/UDP msmtsi.com; branch=z9hG4bKxxxxxx
Contact: <sip:p1@msmtsi.com>
Accept: application/cccex
SIP OPTIONS response 
SIP/2.0 200 OK
Via: SIP/2.0/UDP msmtsi.com; branch= z9hG4bKxxxxxx; received=10.10.10.10
To: <sip:cccEx@mmcmh.com>;tag= TR26980E
From: P1 <sip:p1@msmtsi.com>;tag=TR26980
Call-ID: abcdefgh
CSeq: 16384 OPTIONS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/cccex
Content-Type: application/cccex
a=ccc_list:EVS:AMR-WB:AMR|ENC:1;1;1:DEC:3,1,1
Up

Up   Top   ToC