| Summary: | ASTERISK-26874: chan_sip: SIP_CODEC Without Early Media Causes Odd Transcoding | ||
| Reporter: | LTCtech (LTCtech) | Labels: | |
| Date Opened: | 2017-03-14 18:56:38 | Date Closed: | 2020-01-14 11:13:44.000-0600 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling |
| Versions: | 13.14.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) console-output.txt ( 1) sip-trace-em.txt ( 2) sip-trace-no-em.txt | |
| Description: | Our office phones are configured to prefer G722 for intercom. Our ITSP completes calls using G711u. Without forcing a codec it will transcode from G722 to G711u when placing an outbound call, this is expected behavior.
To avoid transcoding we have added the following dialplan to the oubound context: {noformat} exten => s,n,Set(SIP_CODEC_INBOUND=ulaw) exten => s,n,Set(SIP_CODEC_OUTBOUND=ulaw) ... exten => s,n,Dial(...) {noformat} This works for most outbound calls. Resulting in the following output for "core show channel" on both legs: {noformat} NativeFormats: (ulaw) WriteFormat: ulaw ReadFormat: ulaw WriteTranscode: No ReadTranscode: No {noformat} On some outbound calls, specifically an auto answering join.me conference line (860) 970-0010 we get this output on both legs: {noformat} NativeFormats: (ulaw) WriteFormat: slin16 ReadFormat: slin16 WriteTranscode: Yes (slin@16000)->(slin@8000)->(ulaw@8000) ReadTranscode: Yes (ulaw@8000)->(slin@8000)->(slin@16000) {noformat} It's almost as if the bridge itself remained in slin16 mode, while both endpoints switched to G711u. The call that doesn't transcode the ITSP indicated "183 Session Progress" and early media in SDP. While the call that does transcode the ITSP only indicated "200 OK" and the actual media for the call in SDP. I was able to work around this issue by forcing early media to occur locally instead of on the remote side: {noformat} exten => s,n,Set(SIP_CODEC_INBOUND=ulaw) exten => s,n,Set(SIP_CODEC_OUTBOUND=ulaw) exten => s,n,Progress() ;force early media ... exten => s,n,Dial(...) {noformat} This fixed the issue. Another quirk to note is that Progress() has to be put after the SIP_CODEC statements, putting them before the statements did not help. The media has to change after the statements. Is this a bug or an inherent limitation? | ||
| Comments: | By: Asterisk Team (asteriskteam) 2017-03-14 18:56:38.890-0500 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: Joshua C. Colp (jcolp) 2017-03-15 09:16:24.811-0500 Please provide the SIP trace (sip set debug on) as well as the complete console output. By: LTCtech (LTCtech) 2017-03-15 18:46:51.977-0500 Attached console output while dialing none early media call with SIP_CODEC being set. Attached sip traces with early media and without early media. By: Rusty Newton (rnewton) 2017-03-17 11:26:45.663-0500 Hmm, I'm a little confused about your debug/trace. Can you follow the instructions here: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information To gather an Asterisk log with warning,error,notice,verbose,debug channels, with verbose and debug both turned up to 5. Make sure the "sip set debug on" output is captured simultaneously in the same log so we can see the timing of the SIP messages related to log messages. By: Asterisk Team (asteriskteam) 2017-03-31 12:00:02.140-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 | ||