A.8 SDP example with QoS negotiation
26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS
This clause gives an example of an SDP interchange with negotiated QoS parameters.
Table A.8.1: SDP example with QoS negotiation
|
SDP offer from MTSI client in terminal A to B in SIP INVITE message |
|
v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of using AS to indicate negotiated QoS in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:345 t=0 0 a=tcap:1 RTP/AVPF m=audio 49152 RTP/AVP 97 98 a=pcfg:1 t=1 b=AS:30 b=RS:0 b=RR:2000 a=rtpmap:97 AMR/8000/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; octet-align=1 a=ptime:20 a=maxptime:240 m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== 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 |
|
SDP answer from UE B to A in 200/OK message |
|
v=0 o=Example_SERVER2 34135268010 IN IP4 server2.example.com s=Example of using AS to indicate negotiated QoS in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:344 t=0 0 m=audio 49152 RTP/AVPF 97 a=pcfg:1 t=1 b=AS:29 b=RS:0 b=RR:2000 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 m=video 49154 RTP/AVPF 99 a=acfg:1 t=1 b=AS:315 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== 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 |
|
SDP offer from MTSI client in terminal B to A in SIP UPDATE message |
|
v=0 o=Example_SERVER2 34135268010 IN IP4 server2.example.com s=Example of using AS to indicate negotiated QoS in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:59 t=0 0 m=audio 49252 RTP/AVPF 97 b=AS:29 b=RS:0 b=RR:2000 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 m=video 49254 RTP/AVPF 99 b=AS:30 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa 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 |
|
SDP answer from MTSI client in terminal A to B in 200/OK RESPONSE to UPDATE message |
|
v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of using AS to indicate negotiated QoS in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:77 t=0 0 m=audio 49152 RTP/AVPF 97 b=AS:29 b=RS:0 b=RR:2000 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 m=video 49154 RTP/AVPF 99 b=AS:48 b=RS:0 b=RR:2500 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa 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 |
The example in table A.8.1 shows an SDP exchange that reflects the signalling of negotiated QoS during initial session setup when there is only one PDP context or EPS bearer for the whole session. The first offer-answer procedure is initiated by the MTSI client in terminal A at session setup. The responding MTSI client chose the bandwidth-efficient payload format, by excluding the octet-align parameter, and reduced the bandwidth in b=AS to 29. The second offer-answer procedure is initiated by the MTSI client in terminal B when it receives a different negotiated QoS, only 30 kbps for video, than what was indicated in the first SDP offer from A. To notify A, B sends a new SDP offer, in this case embedded in an UPDATE message, to A indicating the lower negotiated QoS bit rate. The MTSI client in terminal A responds with its negotiated QoS value to B.
NOTE: The bit rate in the second SDP answer, 48 kbps, was deliberately chosen to show that this is a fully valid SDP answer even though the second SDP offer only defines 30 kbps. It is however recommended that the UEs choose the same bandwidths whenever possible.
The SDP offer in the SIP UPDATE message contains only one encoding format since the answerer has already removed all but one encoding format in the SDP answer to the initial SDP offer.
In this example it is assumed that the SDPCapNeg framework is not needed in the UPDATE since the RTP profile has already been chosen in the initial invitation.