Subject: SDPCapNeg-06 Issue #1: Bandwidth parameter negotiation in core or not [Was Re: [MMUSIC] SDP CAP Neg example using it for media capabilities]

From: Flemming Andreasen <[email-masked]>
Date: Tue, 11 Sep 2007 17:31:39 -0400

Thank you for the example SDP Magnus, which clearly shows the value of 
having support for bandwidth parameters as part of capability 
negotiation. The question we need to consider however is whether such 
added functionality is needed in the core SDP Capability Negotiation 
document, or whether it can be relegated to an extension.

Looking at transport protocol negotation only, which may imply different 
overheads and hence different bandwidth requirements, Magnus' example 
uses the Transport Independent bandwidth modifier [RFC3890] and that by 
itself provides a solution to different bandwidth requirements when 
negotiating different transport protocols (if supported of course).

Looking at the media format and parameter negotiation as done by Magnus 
example, this type of functionality is not part of the requirements for 
the core specification itself (which to some extent is part of the 
debate here), but it can obviously be done as shown by Magnus's example. 
Alternatively (and preferably, IMO) a more elaborate media capabilities 
negotiation scheme can be defined, which can include such bandwidth 
parameter negotiation. In the absence of doing so, the question is 
whether we are missing important functionality. One way to evaluate this 
is to determine if we are any worse off than we were before: Status quo 
would not use any of the SDP capability negotiation features, but 
instead rely on regular offer/answer procedures. In such a scenario, the 
offerer would have to offer all the alternatives while still providing a 
single bandwidth parameter. In other words, status quo would be using a 
single (worst case) bandwidth parameter - from that point of view we are 
no worse off if we don't support bandwidth parameter negotiation in the 
core. Note that it doesn't matter whether we provide alternatives using 
the SDP Capability Negotiation framework or as part of the normal "m=" 
line offer; the answerer may still pick the least bandwidth intensive 
codec while the bandwidth parameter needs to account for the worst case.

In summary, while I can see the value of and personally am not opposed 
to including bandwidth parameter negotiation in the core, I also don't 
find that lack of this feature causes any significant new problems when 
using the core SDP Capability Negotiation framework. In lieu of that and 
the low level of WG support for adding this feature to the core in 
Chicago, I'm inclined to leave this out of the core spec.

I'd appreciate feedback from people with respect to this path forward 
(both for and against).

Thanks

-- Flemming

Magnus Westerlund wrote:
> Hi,
>
> The below SDP example is using the core of the SDP capability 
> negotiation, or at least attempts to, to perform some media capability 
> negotiation. It is built on the 10k SDP example but here trimmed down 
> to just a simple video and audio stream. I use two different 
> configurations to indicate different media work points. In the case of 
> the video it is both H.264 but here for two different bit-rate work 
> points like a 10 mbit/s and a 512 kbit/s case. For example "streaming 
> quality" and HD quality. I do a similar thing on the audio where it is 
> either AMR-WB(+) or AC3 (dolby digital 5.1 channels). As this is offer 
> answer and I don't know about the RTP payload depacketizer capabilites 
> it includes several packetization modes to ensure that it works. In 
> the video case I also have retransmission support in case AVPF or 
> SAVPF is supported. Otherwise these and 3 of the Audio payload type 
> numbers neeeds to be dummied due to different number of payload 
> formats in different configuration.
>
> As can be see the bandwidth values are not possible to express on 
> configuration basis. Thus, one doesn't really know how much the lower 
> bit-rate media configuraiton really uses. One can probably derive a 
> maximum which is likely to be much larger than reality. Thus it is 
> really hidden that some configuration is inteded to use no more than 
> 500 (video) or 50 (audio) kb.
>
> You can also spot the downside of no delete function for attributes as 
> I am forced to use the "-m" option and thus need to acap all SDP 
> attributes basically.
>
> I havent' found anything that doesn't work in the exercise of creating 
> this SDP. However, I must say that it looks quite ugly. But I forsee 
> that this type of arrangement will start to pop up. And then I think 
> we can forsee even more complex cases.
>
> Warning SDP is hand-made and may contain large syntax errors. That is 
> definitely true for the H.264 parameterization.
>
> So please consider what this mechanism really means when you get into 
> a bit more serious usages. Also do not expect any replies from me 
> until after the 26th of August.
>
> /Magnus
>
>
> v=0
> o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
> s=A SDP CAP NEG example built on the 10k example I did a while ago
> i=Uses proxying for some payload typs and does media capability 
> negotiation with only core support
> u=http://www.example.com/seminars/sdp.pdf
> e=[email-masked] (Magnus Westerlund)
> t=2873397496 2873404696
> a=ice-pwd:speEc3QGZiNWpVLFJhQX
> m=video 49170 RTP/AVP 100 99 98 97 96 95
> c=IN IP4 192.0.2.56
> b=AS:10000
> b=TIAS:10000000
> b=RR:4000
> b=RS:3000
> a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
> a=pcfg:1 t=1 a=-m:1,2,3,4,5,6,7,11,12,13,30,31,32,33,34,35,36,37,38,39
> a=pcfg:2 t=1 
> a=-m:1,2,3,4,5,6,7,8,9,10,11,12,13,30,31,32,33,34,35,36,37,38,39
> a=pcfg:3 t=2 a=
> a=pcfg:4 t=2 a=8,9,10
> a=pcfg:4 t=3 a=1,2,3,4,5,6,7,11,12,13
> a=pcfg:5 t=3 a=1,2,3,4,5,6,7,8,9,10,11,12,13
> a=maxprate:1000
> a=acap:1 a=rtcp-fb:* nack
> a=rtpmap:98 H264/90000
> a=fmtp:98 profile-level-id=42A01E; packetization-mode=0; 
> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
> a=rtpmap:99 H264/90000
> a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; 
> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
> a=rtpmap:100 H264/90000
> a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; 
> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; 
> sprop-interleaving-depth=45; sprop-deint-buf-req=64000; 
> sprop-init-buf-time=102478; deint-buf-cap=128000
> a=rtpmap:97 H264/90000
> a=fmtp:97 profile-level-id=42A01E; packetization-mode=0; 
> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
> a=rtpmap:96 H264/90000
> a=fmtp:96 profile-level-id=42A01E; packetization-mode=0; 
> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
> a=rtpmap:95 H264/90000
> a=fmtp:95 profile-level-id=42A01E; packetization-mode=0; 
> sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
> a=acap:2 a=rtpmap:97 rtx/90000
> a=acap:3 a=fmtp:97 apt=100;rtx-time=3000
> a=acap:4 a=rtpmap:96 rtx/90000
> a=acap:5 a=fmtp:96 apt=99;rtx-time=3000
> a=acap:6 a=rtpmap:95 rtx/90000
> a=acap:7 a=fmtp:95 apt=98;rtx-time=3000
> a=acap:8 a=fmtp:98 profile-level-id=82A01E; packetization-mode=0; 
> sprop-parameter-sets=fetgasd,fleaS==
> a=acap:9 a=fmtp:99 profile-level-id=82A01E; packetization-mode=0; 
> sprop-parameter-sets=fetgasd,fleaS==
> a=acap:10 a=fmtp:100 profile-level-id=82A01E; packetization-mode=0; 
> sprop-parameter-sets=fetgasd,fleaS==; sprop-interleaving-depth=45; 
> sprop-deint-buf-req=64000; sprop-init-buf-time=102478; 
> deint-buf-cap=128000
> a=acap:11 a=rtpmap:98 H264/90000
> a=acap:12 a=rtpmap:99 H264/90000
> a=acap:13 a=rtpmap:100 H264/90000
> a=rtcp:51540
> a=sendonly
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 
> inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
> a=candidate 12345678 1 UDP 1.0 192.0.2.56 49170
> a=candidate 23456781 2 UDP 1.0 192.0.2.56 51540
> a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345
> a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567
> a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000
> a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001
> a=acap:30 a=rtcp:51540
> a=acap:31 a=sendonly
> a=acap:32 a=crypto:1 AES_CM_128_HMAC_SHA1_80 
> inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
> a=acap:33 a=candidate 12345678 1 UDP 1.0 192.0.2.56 49170
> a=acap:34 a=candidate 23456781 2 UDP 1.0 192.0.2.56 51540
> a=acap:35 a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345
> a=acap:36 a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567
> a=acap:37 a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000
> a=acap:38 a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001
> a=acap:39 a=maxprate:1000
> m=audio 49176 RTP/AVP 101 100 99 98
> c=IN IP4 192.0.2.56
> b=AS:512
> b=TIAS:512000
> b=RR:4000
> b=RS:3000
> a=tcap:4 RTP/SAVP
> a=pcfg:6 t=4 a=23
> a=pcfg:7 t=4 a=-m: 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29
> a=maxprate:120
> a=rtpmap:98 AMR-WB/16000
> a=fmtp:98 octet-align=1; mode-change-capability=2
> a=rtpmap:99 AMR-WB/16000
> a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
> a=rtpmap:100 AMR-WB/16000/2
> a=fmtp:100 octet-align=1; interleaving=30
> a=rtpmap:101 AMR-WB+/72000/2
> a=fmtp:101 interleaving=50; int-delay=160000;
> a=acap:14 a=rtpmap:98 ac3/48000/6
> a=acap:15 a=rtpmap:99 ac3/48000/6
> a=acap:16 a=rtpmap:100 ac3/48000/6
> a=acap:17 a=rtpmap:101 ac3/48000/6
> a=acap:18 a=ptime:32
> a=acap:19 a=maxprate:120
> a=acap:20 a=maxptime:200
> a=acap:21 a=rtcp:51534
> a=acap:22 a=sendonly
> a=acap:23 a=crypto:1 AES_CM_128_HMAC_SHA1_80 
> inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
> a=acap:24 a=candidate 12345678 1 UDP 1.0 192.0.2.56 49176
> a=acap:25 a=candidate 23456781 2 UDP 1.0 192.0.2.56 51534
> a=acap:26 a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345
> a=acap:27 a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567
> a=acap:28 a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000
> a=acap:29 a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001
> a=ptime:60
> a=maxptime:200
> a=rtcp:51534
> a=sendonly
> a=candidate 12345678 1 UDP 1.0 192.0.2.56 49176
> a=candidate 23456781 2 UDP 1.0 192.0.2.56 51534
> a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345
> a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567
> a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000
> a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 12 Sep 2007 11:37:39 +0200

Flemming,

thanks for your analysis.
I vote for specifying bandwidth parameter negotiation as part of the
media capability extension, 
since doing so is not worse than the status quo.
I would like to have the core spec as simple as possible in order to
have a low "activation energy" for initial implementation.

Regards
Thomas 

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 11:32 PM
> To: Magnus Westerlund
> Cc: mmusic (E-mail)
> Subject: SDPCapNeg-06 Issue #1: Bandwidth parameter 
> negotiation in core ornot [Was Re: [MMUSIC] SDP CAP Neg 
> example using it for mediacapabilities]
> 
> > a=pcfg:1 t=1 
> a=-m:1,2,3,4,5,6,7,11,12,13,30,31,32,33,34,35,36,37,38,39
> > a=pcfg:2 t=1

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Sep 2007 10:51:18 +0200

> negotiating different transport protocols (if supported of course).

No, it doesn't. Because in accordance with the TIAS parameter semantics
if one like to indicate that a session using retransmission will have a
higher bit-rate to allow for the retransmission in addition to the
primary transmission then the TIAS values for the transport will be
differnt. However, you are correct that it solves the issue between
considering RTP/UDP and RTP/TCP bandwidth differencies.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------