Summary:	ASTERISK-09979: [patch] PCMA/16000 and PCMU/16000 support (hd telephony)
Reporter:	Guido R. (guido-r)	Labels:
Date Opened:	2007-07-30 04:34:14	Date Closed:	2011-06-07 14:02:56
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) hd_telephony.diff ( 1) pcma_16000.eth
Description:	With this patch PCMA/16000 and PCMU/16000 will be accepted during the SDP negotiation. Prior asterisk ignored the sample rate in the rtpmap lines of the SDP body and changed the 16000 to 8000.. and so the negotiation between the UAs failed. Now the sample rate is parsed too, and for now PCMA/16000 and PCMU/16000 are supported by the new option flag AST_OPT_16000. ****** ADDITIONAL INFORMATION ****** The data structure rtpPayloadType has been extended by a sample_rate attribute. The list of available codecs is extended by the sample rate attribute. For now only G722 has a sample rate of 16000. A new codec implemented in asterisk for the PCMA/16000 and PCMU/16000 is not needed. An asterisk test server is running in our company with this new feature enabled. Our tests with hd telephony equipment work fine.
Comments:	By: Guido R. (guido-r) 2007-07-30 05:23:09 pcma_16000.eth: Wireshark trace of a PCMA/16000 call with Asterisk as SIP Registrar. By: Guido R. (guido-r) 2007-08-06 01:53:02 Sorry for pushing this up. But are there any comments on this? By: Andrew Lindh (andrew) 2007-08-08 22:48:16 You have to be careful about data rate vs. sample rate. G.722 has a sample rate of 16Khz but a data rate (in RTP) of 8Khz (64kbit/sec)...also because of the confusion G.722 is still listed as an 8Khz codec. Look at the RFC: Section 4.5 lists sample rate at 16Khz: http://tools.ietf.org/html/rfc3551#section-4.5 Section 4.5.2 says why 8Khz is still listed: http://tools.ietf.org/html/rfc3551#section-4.5.2 By: Guido R. (guido-r) 2007-08-09 05:30:52 I left G.722 untouched. According to the RFC different sampling rates for PCMA and PCMU are possible. With this patch not only PCMA/8000, but also PCMA/16000 can be negotiated, when both sides support it. Till now Asterisk simply ignores the sample rate, given in a SDP Header. A negotiation with PCMA/16000 fails, because Asterisk changes the 16000 to 8000. By: Olle Johansson (oej) 2007-11-05 15:41:45.000-0600 Well, there's more than SIP and RTP in Asterisk. You have to make sure all of asterisk can handle another sample rate before we change SIP/RTP. Or? By: Olle Johansson (oej) 2007-12-11 01:34:41.000-0600 Any feedback? By: Guido R. (guido-r) 2007-12-11 02:53:16.000-0600 If the end devices can handle these codecs, Asterisk does not have to fully support these codecs internally, as the RTP session is set up between the endpoints. My patch is no internal support, but makes a successful sdp negotiation possible between two devices, if both are able to speak PCMA/16000 or PCMU/16000. By: Olle Johansson (oej) 2007-12-11 02:57:58.000-0600 You are wrong. Asterisk sets up the call between each phone and asterisk and needs to be able to handle the call in the case of hold, transfers and other situations. After we have a call setup, we can reinvite the call directly between the end points. There are ways to handle codecs in passthrough mode, but then we need to be able to declare them as frame types too. By: Andrew Lindh (andrew) 2008-01-18 20:10:41.000-0600 Now that trunk (1.6) supports 16Khz audio, it should not be too hard to build a translator... By: Russell Bryant (russell) 2008-01-19 03:43:23.000-0600 I'm just curious, what SIP devices or other types of SIP servers currently support this format? By: Guido R. (guido-r) 2008-01-21 07:59:11.000-0600 One of the first devices is the AVM Fritz!Mini SIP Servers are for example dus.net or servers that do not touch the sdp body and leave the negotiation to the end devices. Nice to hear that asterisk now supports 16khz audio. Maybe this thing can be redone. By: jmls (jmls) 2008-02-17 12:47:12.000-0600 any luck on the translator ? By: Leif Madsen (lmadsen) 2008-10-07 13:20:41 Just for fun, I'm pushing this to the top of the stack since it is now one of the last updated bugs :) If someone can give an update on this, then that'd be great. Thanks! By: dovid (dovid) 2008-10-07 13:22:57 If anyone knows of a soft phone that can support this I would be glad to test the patch. By: Leif Madsen (lmadsen) 2008-10-07 14:43:55 The only phone I know that uses those codecs are the Polycom's that use G.722 By: Tilghman Lesher (tilghman) 2008-10-07 16:14:32 What is holding this up is the lack of available codec bits in the current bitmask.  This is waiting on the media negotiation work discussed at Astricon 2008. By: Tilghman Lesher (tilghman) 2008-10-09 19:05:16 Unassigning, as this is waiting on the media negotiation changes.  The codec_bits branch has been abandoned in favor of the new approach. By: Joshua C. Colp (jcolp) 2009-04-27 14:41:28 I am suspending this issue until such time as our new media architecture is complete. Once this is done this issue will be revisited, updated, and added. I urge you to participate in the media architecture discussion once it is brought to the development list so that you can help it become the best architecture it can be. Thank you for your contribution. By: Alexander Traud (traud) 2017-04-03 02:33:47.759-0500 Short answer: I implemented this audio format at http://github.com/traud/asterisk-alaw16 Long answer: A bit late, but for other reasons, I had to implement what was discussed here, now ten years ago. This report was about ignoring the sample rate in SIP/SDP and therefore using PCMU/8000 instead of PCMU/xxxxx. Furthermore, when this report was created, several wide-band audio formats competed. The original reporter was employed at AVM Germany who create the Internet access devices (IAD) FRITZ!Box. Furthermore, at that time, AVM still used Wi-Fi instead of DECT to attach phones and therefore created a product called FRITZ!Mini – a Wi-Fi enabled SIP phone. That device did not use G.722 but PCMU/16000 for HD voice. To avoid transcoding, jitter, and echo, AVM used that PCMU/16000 even between their FRITZ!Box. Some SIP providers simply forward the SDP and therefore, the endpoints are able to negotiate directly. Because G.722 won the race, I am not adding this format to the core of Asterisk but provide it as external module. For those, who stumble across this report via an Internet search, please, have a look at the above hyperlink. It contains even further background information.