Subject: [MMUSIC] SDP media capabilities and nightmare SDP

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 21 Mar 2007 16:26:16 +0100

Hi

Thanks to Louis Alexander for a primer on the line-break properties of the most wide-spread email-client (lets call the client "lookout" :-).

Anyway 
Below is a "nightmare SDP offer" from a VoIP client that says that it can support everything that 3GPP TS 28.062 and 3GPP TS 26.103 specifies in terms of codec mode configurations for AMR and AMR-WB. Further down my effort to encode the same SDP according to draft-ietf-mmusic-spd-media-capabilities-01.txt. I hope I got everything right in the "reencoding". My humble question is whether or not it is possible to do things more smart or simply put if I have missed some crucial feature that makes it possible to compress the whole shebang a little better.

Comments welcome.

===========================
Good old SDP

m=audio 49152 RTP/AVP xx xx xx
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,4,7; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=2; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=3; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=4; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=5; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=6; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=7; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,3; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,3,4; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,3,6; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,5,7; mode-change-capability=2;
  max-red=220
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,4,7; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=2; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=3; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=4; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=5; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=6; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=7; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,3; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,3,4; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,3,6; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:xx AMR/8000/1
a=fmtp:xx mode-set=0,2,5,7; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:yy AMR-WB/16000/1
a=fmtp:yy mode-set=0,1,2; mode-change-capability=2;
  max-red=220
a=rtpmap:yy AMR-WB/16000/1
a=fmtp:yy mode-set=0,1,2,5; mode-change-capability=2;
  max-red=220
a=rtpmap:yy AMR-WB/16000/1
a=fmtp:yy mode-set=0,1,2,9; mode-change-capability=2;
  max-red=220
a=rtpmap:yy AMR-WB/16000/1
a=fmtp:yy mode-set=0,1,2; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:yy AMR-WB/16000/1
a=fmtp:yy mode-set=0,1,2,5; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:yy AMR-WB/16000/1
a=fmtp:yy mode-set=0,1,2,9; mode-change-capability=2;
  max-red=220; octet-align=1
a=rtpmap:yy AMR-WB/16000/1
a=maxptime:240
a=ptime:20
===========================

According to SDP media cap. Draft:

a=creq:v1

a=tcap:1 RTP/AVP
m=cmed:1 audio AMR AMR AMR AMR AMR
m=cmed:6 audio AMR AMR AMR AMR AMR
m=cmed:11 audio AMR AMR AMR AMR AMR
m=cmed:16 audio AMR AMR AMR AMR AMR	
m=cmed:21 audio AMR AMR AMR AMR AMR
m=cmed:26 audio AMR-WB AMR-WB AMR-WB AMR-WB AMR-WB AMR-WB

m=audio 49152 RTP/AVP AMR
a=rtpmap:100 AMR/8000/1 mode-set=0; mode-change-capability=2; max-red=220

a=cenc:1 8000/1 mode-set=0; mode-change-capability=2; max-red=220
a=cenc:2 8000/1 mode-set=0,2,4,7; mode-change-capability=2; max-red=220
a=cenc:3 8000/1 mode-set=2; mode-change-capability=2; max-red=220
a=cenc:4 8000/1 mode-set=3; mode-change-capability=2; max-red=220
a=cenc:5 8000/1 mode-set=4; mode-change-capability=2; max-red=220
a=cenc:6 8000/1 mode-set=5; mode-change-capability=2; max-red=220
a=cenc:7 8000/1 mode-set=6; mode-change-capability=2; max-red=220
a=cenc:8 8000/1 mode-set=7; mode-change-capability=2; max-red=220
a=cenc:9 8000/1 mode-set=0,2; mode-change-capability=2; max-red=220 
a=cenc:10 8000/1 mode-set=0,2,3; mode-change-capability=2; max-red=220
a=cenc:11 8000/1 mode-set=0,2,3,4; mode-change-capability=2; max-red=220
a=cenc:12 8000/1 mode-set=0,2,3,6; mode-change-capability=2; max-red=220
a=cenc:13 8000/1 mode-set=0,2,5,7; mode-change-capability=2; max-red=220
a=cenc:14 8000/1 mode-set=0; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:15 8000/1 mode-set=0,2,4,7; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:16 8000/1 mode-set=2; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:17 8000/1 mode-set=3; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:18 8000/1 mode-set=4; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:19 8000/1 mode-set=5; mode-change-capability=2; max-red=220; octet-align=1 
a=cenc:20 8000/1 mode-set=6; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:21 8000/1 mode-set=7; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:22 8000/1 mode-set=0,2; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:23 8000/1 mode-set=0,2,3; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:24 8000/1 mode-set=0,2,3,4; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:25 8000/1 mode-set=0,2,3,6; mode-change-capability=2; max-red=220; octet-align=1

a=cenc:26 16000/1 mode-set=0,2,5,7; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:27 16000/1 mode-set=0,1,2; mode-change-capability=2; max-red=220
a=cenc:28 16000/1 mode-set=0,1,2,5; mode-change-capability=2; max-red=220
a=cenc:29 16000/1 mode-set=0,1,2,9; mode-change-capability=2; max-red=220 
a=cenc:30 16000/1 mode-set=0,1,2; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:31 16000/1 mode-set=0,1,2,5; mode-change-capability=2; max-red=220; octet-align=1
a=cenc:32 16000/1 mode-set=0,1,2,9; mode-change-capability=2; max-red=220; octet-align=1
a=pcfg:1 t=1 m=1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|28|29|30|31|32 pt=1:100,2:100,3:100,4:100,5:100,6:100,7:100,8:100,9:100,10:100,11:100,12:100, 13:100,14:100,15:100,16:100,17:100,18:100,19:100,20:100,21:100,22:100,23:100, 24:100,25:100,26:100,27:100,28:100,29:100,30:100,31:100,32:100

a=maxptime:240
a=ptime:20
===========================

Regards
Ingemar

*******************************************
Ingemar Johansson
Senior Research Engineer
EAB/TVP - Multimedia Technologies Ericsson Research
Ericsson AB
Box 920
S-971 28 Luleå, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
Mobile: +46 (0)730 783289
*******************************************

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 21 Mar 2007 18:49:20 +0100

Hi,

If you call this "nightmare offer", what would you call an offer from a client which does both audio and video? :)

Regards,

Christer 

> -----Original Message-----
> From: Ingemar Johansson S (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: 21. maaliskuuta 2007 17:26
> To: [email-masked]
> Subject: [MMUSIC] SDP media capabilities and nightmare SDP
> 
> Hi
> 
> Thanks to Louis Alexander for a primer on the line-break 
> properties of the most wide-spread email-client (lets call 
> the client "lookout" :-).
> 
> Anyway
> Below is a "nightmare SDP offer" from a VoIP client that says 
> that it can support everything that 3GPP TS 28.062 and 3GPP 
> TS 26.103 specifies in terms of codec mode configurations for 
> AMR and AMR-WB. Further down my effort to encode the same SDP 
> according to draft-ietf-mmusic-spd-media-capabilities-01.txt. 
> I hope I got everything right in the "reencoding". My humble 
> question is whether or not it is possible to do things more 
> smart or simply put if I have missed some crucial feature 
> that makes it possible to compress the whole shebang a little better.
> 
> Comments welcome.
> 
> a=cenc:9 8000/1 mode-set=0,2; mode-change-capability=2; 
> max-red=220 a=cenc:10 8000/1 mode-set=0,2,3; 
> mode-change-capability=2; max-red=220
> a=cenc:19 8000/1 mode-set=5; mode-change-capability=2; 
> max-red=220; octet-align=1 a=cenc:20 8000/1 mode-set=6; 
> mode-change-capability=2; max-red=220; octet-align=1
> a=cenc:29 16000/1 mode-set=0,1,2,9; mode-change-capability=2; 
> max-red=220 a=cenc:30 16000/1 mode-set=0,1,2; 
> mode-change-capability=2; max-red=220; octet-align=1
> a=pcfg:1 t=1 
> m=1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|
> 24|25|26|27|28|29|30|31|32 
> pt=1:100,2:100,3:100,4:100,5:100,6:100,7:100,8:100,9:100,10:10
> 0,11:100,12:100, 
> 13:100,14:100,15:100,16:100,17:100,18:100,19:100,20:100,21:100
> ,22:100,23:100, 
> 24:100,25:100,26:100,27:100,28:100,29:100,30:100,31:100,32:100
> 
> a=maxptime:240
> a=ptime:20
> EAB/TVP - Multimedia Technologies Ericsson Research Ericsson 
> AB Box 920
> S-971 28 Luleå, Sweden
> Tel: +46 (0)8 4043042
> ECN: 850-43042

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 21 Mar 2007 19:40:51 +0100

Mother of all nightmares ?
:-) 

Ingemar
> From: Christer Holmberg (JO/LMF) 
> Sent: den 21 mars 2007 18:49
> To: Ingemar Johansson S (LU/EAB); [email-masked]
> Subject: RE: [MMUSIC] SDP media capabilities and nightmare SDP
> 
> 
> Hi,
> 
> If you call this "nightmare offer", what would you call an 
> offer from a client which does both audio and video? :)
> 
> Regards,
> 
> Christer 
>

---

From: "Robert R. Gilman" <[email-masked]>
Date: Wed, 21 Mar 2007 14:32:16 -0600

Ingemar-
Nightmare indeed!  I think you wanted to define 26 AMR codecs and 6 AMR-WB
codecs (I'm not sure.)  Try this (I've folded the cmed: line and the cenc: line):

a=creq:v1
m=audio 49152 RTP/AVP 100
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-set=0; mode-change-capability=2; max-red=220
a=maxptime:240
a=ptime:20
a=cmed:2 audio AMR AMR AMR AMR AMR AMR AMR AMR AMR AMR AMR AMR
     AMR ARM AMR AMR AMR AMR AMR AMR AMR AMR AMR AMR AMR AMR
     AMR-WB AMR-WB AMR-WB AMR-WB AMR-WB AMR-WB AMR-WB
a=cenc:2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
     8000/1
a=cenc:27,28,29,30,31 16000/2
a=cfmt:14 mode-set=0;
a=cfmt:2,15 mode-set=0,2,4,7;
a=cfmt:3,16 mode-set=2;
a=cfmt:4,17 mode-set=3;
a=cfmt:5,18 mode-set=4;
a=cfmt:6,19 mode-set=5;
a=cfmt:7,20 mode-set=6;
a=cfmt:8,21 mode-set=7;
a=cfmt:9,22 mode-set=0,2;
a=cfmt:10,23 mode-set=0,2,3;
a=cfmt:11,24 mode-set=0,2,3,4;
a=cfmt:12,25 mode-set==0,2,3,6;
a=cfmt:13,26 mode-set=0,2,5,7;
a=cfmt:27,30 mode-set=0,1,2;
a=cfmt:28,31 mode-set=0,1,2,5;
a=cfmt:29,32 mode-set=0,1,2,9;
a=cfmt:2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,
     27,28,29,30,31,32 mode-change-capability=2; max-red=220;
a=cfmt:14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 octet-align=1
pcfg:1 m=2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|
     27|28|29|30|31|32 pt=2:100,3:100,4:100,5:100,6:100,7:100,8:100,9:100,10:100,
     11:100,12:100,13:100,14:100,15:100,16:100,17:100,18:100,19:100,20:100,
     21:100,22:100,23:100,24:100,25:100,26:100,27:100,28:100,29:100,30:100,
     31:100,32:100

We've assumed the default (media line) transport.  Looking at this example,
I wonder if we don't want to implement some ranging on the media capability
numbers - something like:

a=cenc:2-26 8000/1
a=cenc:27-32 16000/1
a=cfmt:2-32 mode-change-capability=2; max-red=220;

and

pcfg:1 m=2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|
     27|28|29|30|31|32 pt=100:2-32

Of course, the long form of the pt parameter would be used if the offeror wanted
to distinguish the answerer's choice via the payload type received prior to
receiving the answer.  Do you have a suggestion for how to say "pick one codec
from this range" that's better than the 2|3|4|... ad nauseum?
Does this more-or-less fit with what you wanted to express?
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 21 Mar 2007 21:49:59 +0100

Hi

I believe that slept over a few lessons, 1000 thanks for the help!. 
This squeezed down the whole thing quite a bit. 
Only thing that I find odd is that I regard the mode-set as an encoding
parameter and not a format parameter but I am not 100% sure here.

If the ranging option is possible I believe that it would help up things
even more, especially it would be less tedious to read.

Regards
Ingemar
> From: Robert R. Gilman [mailto:[email-masked]] 
> Sent: den 21 mars 2007 21:32
> To: Ingemar Johansson S (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] SDP media capabilities and nightmare SDP
> 
> Ingemar-
> Nightmare indeed!  I think you wanted to define 26 AMR codecs 
> and 6 AMR-WB codecs (I'm not sure.)  Try this (I've folded 
> the cmed: line and the cenc: line):
> 
> a=creq:v1
> a=maxptime:240 a=ptime:20
> pcfg:1 
> m=2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|
>      27|28|29|30|31|32 
> pt=2:100,3:100,4:100,5:100,6:100,7:100,8:100,9:100,10:100,
>      
> We've assumed the default (media line) transport.  Looking at 
> this example, I wonder if we don't want to implement some 
> ranging on the media capability numbers - something like:
> 
> a=cenc:2-26 8000/1
> a=cenc:27-32 16000/1
> pcfg:1 
> m=2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|
> Of course, the long form of the pt parameter would be used if 
> the offeror wanted to distinguish the answerer's choice via 
> the payload type received prior to receiving the answer.  Do 
> you have a suggestion for how to say "pick one codec from 
> this range" that's better than the 2|3|4|... ad nauseum?

---

From: "Robert R. Gilman" <[email-masked]>
Date: Wed, 21 Mar 2007 15:19:55 -0600

Ingemar-
I checked draft-ietf-avt-rtp-amr-bis-06.txt, and it seems to say the
fmtp: line is the place for mode-set - but it doesn't matter - we play
the same list-the-codecs game with the cenc: attributes.

Roni, Flemming-
Shall we add the range option to the media-capabilities draft?

-Bob

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 22 Mar 2007 00:57:39 +0200

Hi,
Just note that in the old SDP the m line should have 26 payload types and not 3.
If you add video you may run into the problem of not having enough dynamic payload type numbers

Roni

> Sent: Wednesday, March 21, 2007 5:26 PM
> To: [email-masked]
> Thanks to Louis Alexander for a primer on the line-break properties of the
> most wide-spread email-client (lets call the client "lookout" :-).
> 
> Anyway
> Below is a "nightmare SDP offer" from a VoIP client that says that it can
> support everything that 3GPP TS 28.062 and 3GPP TS 26.103 specifies in
> terms of codec mode configurations for AMR and AMR-WB. Further down my
> effort to encode the same SDP according to draft-ietf-mmusic-spd-media-
> capabilities-01.txt. I hope I got everything right in the "reencoding". My
> humble question is whether or not it is possible to do things more smart
> or simply put if I have missed some crucial feature that makes it possible
> to compress the whole shebang a little better.
> 
> Comments welcome.
> 
> m=1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|
> 28|29|30|31|32
> pt=1:100,2:100,3:100,4:100,5:100,6:100,7:100,8:100,9:100,10:100,11:100,12:
> 100,
> 13:100,14:100,15:100,16:100,17:100,18:100,19:100,20:100,21:100,22:100,23:1
> 00, 24:100,25:100,26:100,27:100,28:100,29:100,30:100,31:100,32:100
> 
> a=maxptime:240
> a=ptime:20

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 08:56:20 -0400

It's a good example, however instead of focusing on the syntactical 
encoding at this point, we should rather take a step back and look at 
requirements here. What seems to imply is the need for having a way of 
constructing media capabilities where there is a large number of 
possible fmtp values for a given codec, and you would like to have a way 
to express that somewhat efficiently (from an overall message size point 
of view). Does that capture the issue here ?

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 08:58:15 -0400

> If you add video you may run into the problem of not having enough dynamic payload type numbers
Note that each media stream has its own payload type number space, so 
additional media streams should not make this any worse.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 08:59:42 -0400

> Shall we add the range option to the media-capabilities draft?
Quite possible, but more importantly at this point, we should understand 
the underlying requirements better first.

-- Flemming
>> This squeezed down the whole thing quite a bit. Only thing that I 
>> find odd is that I regard the mode-set as an encoding
>>> From: Robert R. Gilman [mailto:[email-masked]] Sent: den 21 mars 2007 
>>> 21:32
>>> Nightmare indeed!  I think you wanted to define 26 AMR codecs and 6 
>>> AMR-WB codecs (I'm not sure.)  Try this (I've folded the cmed: line 
>>> and the cenc: line):
>>>
>>> a=creq:v1
>>> We've assumed the default (media line) transport.  Looking at this 
>>> example, I wonder if we don't want to implement some ranging on the 
>>> media capability numbers - something like:
>>>
>>> a=cenc:2-26 8000/1
>>> a=cenc:27-32 16000/1
>>> Of course, the long form of the pt parameter would be used if the 
>>> offeror wanted to distinguish the answerer's choice via the payload 
>>> type received prior to receiving the answer.  Do you have a 
>>> suggestion for how to say "pick one codec from this range" that's 
>>> better than the 2|3|4|... ad nauseum?

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Thu, 22 Mar 2007 14:26:32 +0100

Hi

I probably stand corrected regarding the fmtp line. 
Regarding the usecase I listed "nightmare SDP" this is the result of
interworking with legacy circuit switched AMR which has a whole bunch of
mode sets depending on the underlying access network (GSM, UMTS...) but
I have heard that one can easily end up in the same situation with video
codecs that could be configured in many different ways depending on
terminal properties.

Regards

> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: den 22 mars 2007 14:00
> To: Robert R. Gilman
> Cc: Ingemar Johansson S (LU/EAB); Even, Roni; [email-masked]
> Quite possible, but more importantly at this point, we should 
> understand the underlying requirements better first.
> 
> -- Flemming
> >
> > -Bob
> parameter and 
> >> not a format parameter but I am not 100% sure here.
> >>
> >> If the ranging option is possible I believe that it would help up 
> >> things even more, especially it would be less tedious to read.
> >>
> >> Regards
> >> Ingemar
> >>

---

From: "Robert R. Gilman" <[email-masked]>
Date: Thu, 22 Mar 2007 09:20:36 -0600

Roni-
That raises an interesting question: is there any reason why we can't reassign
a "fixed" payload number to something other than the default codec via an
rtpmap: attribute?
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Robert R. Gilman" <[email-masked]>
Date: Thu, 22 Mar 2007 10:56:52 -0600

Flemming-
That's the primary issue.  I'd thought about "compacting" the list of
alternative media capabilities and/or the payload type list in a pcfg
attribute, but maybe it's not worth the trouble.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

Flemming Andreasen wrote:
>> AMR-WB
>> example,
>> offeror wanted

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Thu, 22 Mar 2007 18:40:14 +0100

Hi

I would welcome the more compact version below. I don't belive that it
will cause any ambiguities as it reminds pretty much about the options
you see in eg. a printout dialog, there you can select to print a number
of pages separated by ',' or a range of pages separated by '-'. I know,
pretty far fetched comparison, but just to point out that the
interpretation is quite easy to understand. There are of course sequels
to this , should one perhaps allow things like

a=cenc:2-12,20-26 8000/1
???
This is also easy to understand but I can also understand if somebody
objects...

Ingemar

> Sent: den 22 mars 2007 17:57
> To: Flemming Andreasen
> Cc: Ingemar Johansson S (LU/EAB); [email-masked]
> That's the primary issue.  I'd thought about "compacting" the 
> list of alternative media capabilities and/or the payload 
> type list in a pcfg attribute, but maybe it's not worth the trouble.
> -Bob
> > possible fmtp values for a given codec, and you would like 
> to have a 
> > way to express that somewhat efficiently (from an overall 
> message size 
> > point of view). Does that capture the issue here ?
> > 
> > -- Flemming
> > 
> > 
> > Robert R. Gilman wrote:
> > 
> >> Ingemar-
> >> and the
> >> cenc: line):

---

From: "Robert R. Gilman" <[email-masked]>
Date: Thu, 22 Mar 2007 14:38:36 -0600

Ingemar-
That would work for me.

Ingemar Johansson S (LU/EAB) wrote:
>>>encoding at this point, we should rather take a step back 
>>
>>and look at 
>>
>>>requirements here. What seems to imply is the need for 
>>
>>having a way of 
>>
>>>>Nightmare indeed!  I think you wanted to define 26 AMR 
>>
>>codecs and 6 
>>
>>>>AMR-WB codecs (I'm not sure.)  Try this (I've folded the 
>>
>>cmed: line 
>>
>>>>and the
>>>>cenc: line):
>>>>
>>>>a=creq:v1
>>a=cfmt:2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,2
>>
>>>>5,26,
>>>>
>>11:100,12:100,13:100,14:100,15:100,16:100,17:100,18:100,19:100,20:100
>>
>>>>,
>>>>    
>>>>
>>
>>>>example, I wonder if we don't want to implement some 
>>
>>ranging on the 
>>
>>>>offeror wanted to distinguish the answerer's choice via 
>>
>>the payload 
>>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Mar 2007 17:33:35 -0400

>a "fixed" payload number to something other than the default codec via an

You can.  Some endpoints/midboxes might not like it, but you can.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)