[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SDPCapNeg-06 Issue #1: Bandwidth parameter negotiation in core ornot [Was Re: [MMUSIC] SDP CAP Neg example using it for mediacapabilities]
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:fandreas at cisco.com]
> 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]
>
> 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
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic