Summary:	ASTERISK-25517: PCMA codec negotiated.. Asterisk unexpectedly uses G722 for first second or so of call before sending PCMA
Reporter:	hristo (hristo)	Labels:
Date Opened:	2015-11-03 04:29:32.000-0600	Date Closed:	2018-01-02 08:44:21.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling Core/RTP
Versions:	11.20.0	Frequency of Occurrence
Related Issues:
Environment:	Debian 7.8, x64	Attachments:	( 0) debug.log ( 1) sending-g722-instead-of-g711.pcap
Description:	Asterisk starts sending G722 even though in SDP from Asterisk as well as in SDP from the endpoint the first priority codec is set to PCMA. This only happens for about a second before Asterisk switches to PCMA, but it seems to be a problem for some IP phones and as a result the calls end up having one way audio. I'd expect that when Asterisk offers PCMA as primary codec in INVITE SDP and when it receives PCMA as primary codec in 200 OK from telephone, that it will only send PCMA, but this isn't the case. The problem can be reproduced with a default Asterisk installation by simply adding two sip.conf endpoints: {code} [Alice] host=dynamic type=friend secret=1000 nat=no directmedia=no disallow=all allow=alaw [Bob] host=dynamic type=friend secret=2000 nat=no directmedia=no disallow=all allow=g722 allow=alaw allow=ulaw {code} and by adding a single line in extensions.conf in the \[public\] context: {code} exten => 2000,1,Dial(SIP/Bob) {code} What then happens when Alice calls 2000 (Bob) is: # Alice is configured with PCMA only, so she sends only PCMA in INVITE SDP # Asterisk sends an INVITE to Bob with the following codec order in SDP: PCMA, G722, PCMU. Which is presumably done so in order to try to avoid transcoding. # Bob replies with 200 OK with codec order of PCMA, G722, which results in 200 OK with PCMA in SDP being sent to Alice. At this point all devices and Asterisk have expressed preference for PCMA. Asterisk however, starts sending G722 RTP to Bob for about a second, before it switches to PCMA. A workaround is to set the codec order in sip.conf so that the primary codec of Bob matches the codec sent by Alice in INVITE SDP. Attached: - sending-g722-instead-of-g711.pcap - packet capture done on the Asterisk server - debug.log - Asterisk debug log for the same call, with rtp and sip debugging enabled.
Comments:	By: Asterisk Team (asteriskteam) 2015-11-03 04:29:34.333-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: hristo (hristo) 2016-01-25 03:38:39.113-0600 Please let me know if there is anything I can do to help resolve this problem. By: Joshua C. Colp (jcolp) 2017-12-18 08:54:27.237-0600 The resulting SDP negotiation of this shows that the endpoint accepted both alaw and g722, but preferred alaw. It's technically fine for us to send g722 in that scenario. Did you try the "preferred_codec_only" option that chan_sip provides and if so did it change the result? By: Asterisk Team (asteriskteam) 2018-01-02 08:44:21.816-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