Hello Rick, I don't have any firm ideas on SDP profiles, but I do thank you for progressing some formats.
Several people have suggested that Codec 2 shouldn't be the final name for the code, once again I don't have any strong feelings here. The original name came from Bruce Peren's Codec 2 site that started the whole project. Only idea for a name that I had was "vader". In other news I have been steadily working on splitting the combined c2sim simulation version of 1400 bit/s into a separate encoder & decoder that can support 2500 and 1400. Making the separate encoder and decoder exactly match the simulation has exposed and allowed me fix a few small bugs. The new version of 2500 is now working, now debugging the separate enc/dec versions of 1400. Thanks, David On Fri, 2011-11-25 at 09:37 +0000, Rick van Rein wrote: > Hello, > > Has an SDP profile been established for Codec2 yet? Since I am > trying to build it (experimentally) into my open source firmware > for SIP phones ( http://devel.0cpm.org/firmerware/ ) I would like > to know how to describe the codec in negotiations. > > If nothing exists yet, would the following be suitable? > > m=audio 1234 RTP/AVP 80 81 > a=rtpmap:80 PCMA/8000 > a=rtpmap:81 x-codec2/8000 > a=fmtp:81 bps=2550,2400,2000 > > The PCMA is just here to show how alternatives would look > around Codec2, if any are available. > > The "/8000" refers to the sample rate, not the bitrate. > (Even if G.722 was mistakingly set to 8000 in the past.) > Only a wideband version of Codec2 would change that value. > > The payload-format-specific parameter "bps=" contains a > comma-separated list of bitrates that can be synthesised into > speech. > > The actual format used can be derived from the packet size, > even under audio/red that is still the case. There may be > problems due to ptime= however; if 2 packets of bitrate N > would have the same size of 1 packet of bitrate M it may > not be possible to distinguish what was sent. > > 2550 = 17 * 5^2 * 3^1 * 2^1 > 2400 = 5^2 * 3^1 * 2^5 > 2000 = 5^3 * 2^4 > 1200 = 5^2 * 2^4 > > The most likely problem would be that 2 packets at 1200 > have the same size as one packet at 2400. This could be > solved in SDP in two ways. First, by setting a maximum > to ptime to avoid that, along the lines of: > > m=audio 1234 RTP/AVP 80 81 > a=rtpmap:80 PCMA/8000 > a=rtpmap:81 x-codec2/8000 > a=maxptime:20 > a=fmtp:81 bps=2550,2400,2000 > > This would be subject to RFC 3267 support and with ptime > scaled in milliseconds it may not completely solve the > matter. The second solution would be to split the > description into individual offers: > > m=audio 1234 RTP/AVP 80 81 82 83 > a=rtpmap:80 PCMA/8000 > a=rtpmap:81 x-codec2/8000 > a=fmtp:81 bps=2000 > a=rtpmap:82 x-codec2/8000 > a=fmtp:82 bps=2400 > a=rtpmap:83 x-codec2/8000 > a=fmtp:83 bps=2550 > > I feel the latter to be the best option, as it cannot > cause problems when five packets at one rate could > never match seventeen of another, etc. An SDP profile > could formalise on this approach by requiring a single > entry only in the bps= section. > > Even if this is a bit bulky SDP, it evades a need to > include tags and/or lenghts in all packets in the > RTP stream. > > > I used MIME subtype "x-codec2" because there is no > standardised name yet. Is Codec2 a working name, or > is it the final name for the codec? To me, David > appears to be fighting a giant, so I could imagine > Goliath as a codec name... which would be ironic, > given the packet sizes ;-) Anyhow, that's not for > me to decide, merely to ask about. > > > > I hope this is helpful. > > > Cheers, > > Rick van Rein > OpenFortres / 0cpm > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
