[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SDPCapNeg-06 Issue #1: Bandwidth parameter negotiation in core or not [Was Re: [MMUSIC] SDP CAP Neg example using it for media capabilities]
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=magnus.westerlund at ericsson.com (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
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic