Summary:	ASTERISK-25197: asterisk 13.4.0 fails to transcode calls to/from g729 with TCE400P
Reporter:	Tom Parker (tparker)	Labels:
Date Opened:	2015-06-24 18:05:28	Date Closed:	2020-01-14 11:13:55.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:	13.4.0	Frequency of Occurrence
Related Issues:
Environment:	SLES 11 SP3 (3.0.101-0.47.52-default x86_64)	Attachments:	( 0) aruast.pcap ( 1) asterisk-config.tar ( 2) core_show_translation.txt ( 3) dahdi.txt ( 4) myDebugLog.txt
Description:	With the TCE400P installed a call placed from a Polycom SIP phone using ulaw to a SIP trunk using g729 succeeds but audio is only one way.  The caller does not hear any audio but the callee can.   This also happens between two phones on the same asterisk pbx if one phone is forced to use ulaw and the other g729.  In this scenario the caller does not receive any audio from the callee. Downgrading asterisk to 11.13 has fixed the problem for me with no change at all in my configuration or sip setup for my telephones.
Comments:	By: Rusty Newton (rnewton) 2015-06-24 18:09:53.431-0500 Tom, since a Digium card is involved have you already contacted Digium technical support? They may be able to first help you determine if the card or drivers are at fault or the if issue lies within Asterisk. If you have contacted them already then please provide a case number so that we can reference the information they have so far. If you haven't then I recommend you contact Digium technical support and re-open a ticket here after you have worked with them to confirm there is no fault with the card or driver. By: Tom Parker (tparker) 2015-06-27 00:03:56.652-0500 I have not opened a case with Digium as it works perfectly with asterisk 11.13.  I feel that this means that the card and drivers are working as designed as the only difference between a working system and a broken on is the version of asterisk.   Thanks Tom By: Rusty Newton (rnewton) 2015-06-29 09:45:08.877-0500 We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2015-06-29 09:45:24.084-0500 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2015-06-29 09:48:54.759-0500 You are probably right, but technical support can help verify everything and walk you through gathering the appropriate debug a little more personally than we can. Regardless, I've posted comments requesting what we need. That is an Asterisk full log gathered by following the instructions above, including verbose and debug log channels both set to 5 or above. As well as a protocol trace inline with that debug. In addition we need to know the exact DAHDI driver version and will need all of your relevant configuration files to reproduce the issue. Thanks! By: Rusty Newton (rnewton) 2015-06-29 13:46:47.644-0500 I thought of one more thing. Please provide the output of "core show translation" so that we can see the available translation paths. By: Tom Parker (tparker) 2015-06-30 10:43:44.027-0500 Thanks Rusty I will see when I can collect this data.  It's a production system so upgrading to the broken version to collect logs has to be done after hours. Hope to have something to you this week. By: Tom Parker (tparker) 2015-07-02 21:08:51.835-0500 tcpdump while the calls are in progress. By: Tom Parker (tparker) 2015-07-02 21:09:15.945-0500 Asterisk Config By: Tom Parker (tparker) 2015-07-02 21:09:38.551-0500 core show translations By: Tom Parker (tparker) 2015-07-02 21:10:00.166-0500 dahdi driver info By: Tom Parker (tparker) 2015-07-02 21:10:21.777-0500 Debug logs By: Tom Parker (tparker) 2015-07-02 21:11:50.713-0500 I have attached the requested debug info.   By: Rusty Newton (rnewton) 2015-07-08 17:50:21.918-0500 Hmm, the current log is only so helpful. Can you get the same log again but with "rtp set debug on" ? By: dant (dant) 2015-07-16 10:11:13.329-0500 Seeing the same behaviour with Asterisk 13.3.0 going alaw<->ulaw Call starts with one end, the source, using ulaw, the other end, the destination, using alaw, as the call comes up, bridge looks to set up native_rtp, checks the read/write codecs, finds both sides have ulaw and gets the native_rtp bridge running. As RTP starts flowing, each packet from the destination, using alaw results in the following being logged: [Jul 16 21:01:40] DEBUG[16971][C-00002340] res_rtp_asterisk.c: Unsupported payload type received No Got  RTP packet debug messages are logged. The first packet going out to the alaw host has the following: [Jul 16 21:01:40] DEBUG[16972][C-00002340] res_rtp_asterisk.c: Ooh, format changed from none to alaw followed by Send RTP packet debug messages. One way audio is ulaw to alaw, no audio from alaw to ulaw. core show channel on the outgoing (alaw) leg shows:  NativeFormats: (alaw)    WriteFormat: ulaw     ReadFormat: ulaw WriteTranscode: Yes (ulaw@8000)->(alaw@8000)  ReadTranscode: Yes (alaw@8000)->(ulaw@8000) and on the incoming (ulaw) leg:  NativeFormats: (ulaw)    WriteFormat: ulaw     ReadFormat: ulaw WriteTranscode: No  ReadTranscode: No I was able to work around it by adding a VOLUME function call in dialplan to attach an audiohook to prevent the bridge being eligible for native_rtp. e.g. same => n,Set(VOLUME(RX)=1) Looking at res_rtp_asterisk.c I can't see how the packet could be triggering the message "Unsupported payload type" in bridge_p2p_rtp_write without a "Got  RTP packet" debug message. By: Asterisk Team (asteriskteam) 2015-07-30 12:00:19.688-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines