| Summary: | ASTERISK-24868: Bad audio with silk if connection is bridged over third server and g722 on one side | ||||
| Reporter: | Peter Katzmann (pk16208) | Labels: | |||
| Date Opened: | 2015-03-12 04:56:13 | Date Closed: | 2018-01-02 08:44:24.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Codecs/codec_g722 | ||
| Versions: | 11.16.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | ubuntu 12 | Attachments: | ( 0) h261.tar.bz2 ( 1) silk-bridge-err.tar.bz2 | ||
| Description: | We experience distorted audio in the following scenario:
3 Servers, Phone 1 g722 Phone 2 alaw The call is over wan from server 1 over server 2 to server 3 If the call is direct between server 1 and server 2 audio is ok. If i force speex (server 2 silk codec disabled) audio is ok. It seems that server 2 does some transcoding when we use silk, because the media path says that audio goes in from silk to slin and out from slin to silk. In opposition, when i force speex no transcoding occurs. media path in is speex and out also. So the question is, why does serer 2 transcode to silk instead of transparently connecting the in and out path between server 1 and server 3. | ||||
| Comments: | By: Peter Katzmann (pk16208) 2015-03-12 07:48:38.547-0500 This is not a direct duplicate, because in this special case no translation at all should happen on the in between server. By: Joshua C. Colp (jcolp) 2015-03-12 08:01:03.065-0500 I'll reopen this but please provide logs showing that it's different. As it is it sounds the same, a translation path occurring that shouldn't. By: Matt Jordan (mjordan) 2015-03-12 08:02:14.082-0500 I'm not sure what you're looking for on this issue. Without evidence (re: logs) showing Asterisk setting up the translation paths along with the negotiation of the formats between the various endpoints, a bug marshal would have to just guess as to what is happening. By: Peter Katzmann (pk16208) 2015-03-12 08:34:50.684-0500 What kind of logs ? Sip log ? Wireshark log ? Core Set Debug ? Any hint what lead to a solution will be great. By: Joshua C. Colp (jcolp) 2015-03-12 08:40:03.559-0500 SIP log, configuration for everything involved, complete topology of the setup, core set debug. Everything possible. By: Peter Katzmann (pk16208) 2015-03-17 07:56:00.474-0500 Erronous silk to slin conversion during bridging By: Peter Katzmann (pk16208) 2015-03-17 08:11:47.386-0500 Call in reverse direction leads to h261 as codec ??!?!?? By: Peter Katzmann (pk16208) 2015-03-17 08:16:55.834-0500 Szenario 3 Server : lnx06-asteriskdev1, lnx06-asteriskdev2, 10.0.0.50 2 Users: 2203 (on lnx06-asteriskdev2), 1000 (on 10.0.0.50) lnx06-asteriskdev1 know lnx06-asteriskdev2 and 10.0.0.50 and can talk with each other. lnx06-asteriskdev2 and 10.0.0.50 can't talk with each other directly, only over lnx06-asteriskdev1 Codecs allowed from to lnx06-asteriskdev1: lnx06-asteriskdev2 allow=g722, alaw, silk16, silk8, speex 10.0.0.50 allow=silk16,silk8, speex 2203 uses a OpenStage 60 with g722 enabled 1000 uses a Snom 370 with alaw enabled When i make a call from 1000 to 2203 over lnx06-asteriskdev1 transcoding in the bridging server is done despite the fact that write through is enough. I attach also a trace of a call in from 2203 to 1000 because in this case lnx06-asteriskdev1 chooses h261 as codec. By: Sean Bright (seanbright) 2017-05-24 13:44:51.216-0500 [~pk16208], is this still a problem with Asterisk 13 or newer? If so, I can take a look. By: Asterisk Team (asteriskteam) 2018-01-02 08:44:24.993-0600 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 | ||||