| Summary: | ASTERISK-26736: PJSIP: one way audio | ||||
| Reporter: | Michael Maier (micha) | Labels: | |||
| Date Opened: | 2017-01-20 06:08:11.000-0600 | Date Closed: | 2017-01-20 07:40:10.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_pjsip | ||
| Versions: | 13.13.1 14.2.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Centos 6 64bit FreePBX 13.0.190.7 | Attachments: | |||
| Description: | Given is the following incoming call:
caller via trunk from ISP: INVITE: g722/alaw/ulaw trunk definition: g722/alaw/ulaw/... Asterisk def. for extension: INVITE alaw/ulaw/... (g722 is not allowed) Gigaset C610IP: g722/alaw/ulaw g722 is allowed Result: one way audio! What's happening (I've got a trace!) Between C610IP and Asterisk: alaw. Asterisk tells to ISP via 200 OK SDP: g722/alaw/ulaw but does send alaw rtp! ISP sends g722 (as advertised by 200 OK). Effect: Caller couldn't hear me, but I could hear him. No reinvite from caller appears! Quick fix was to allow g722 for the extension C610IP in asterisk: change from alaw/ulaw/... to g722/alaw/ulaw/... Internally I easily can reproduce this special behavior between two extensions every time: Gigaset C610IP: g722/alaw/ulaw extension 1 def. in Asterisk: g722/alaw/ulaw extension 2 def. in Asterisk: g722/alaw/gsm extension 2/Zoiper: gsm/alaw Now, lets call C610IP to Zoiper: C610IP INVITE: g722/alaw/ulaw Asterisk INVITE to Zoiper: g722/alaw/gsm Zoiper 200 OK SDP: g711/gsm Asterisk 200 OK SDP to C610IP: g722/alaw/ulaw RTP-streams between Asterisk and Zoiper: both alaw. RTP-streams between Asterisk and C610IP: from Asterisk to C610IP: alaw from C610IP to Asterisk: g722 => C610IP can't handle two different RTP-types at the same time, therefore it sends a reinvite to force Asterisk to send g722, two. Which is done subsequently by Asterisk to "repair" the situation. What's the problem? Pjsip on the one hand advertises codecs which aren't reflected by asterisk on the other hand (or vice versa): advertising g722 but sending alaw isn't a good idea, because obviously not each UA is able to cover this situation. Besides that, it isn't a good idea to use 2 different codecs between two UAs, if there is a common codec both UAs know off and which would prevent unnecessary transcoding. Shouldn't it be like this: Asterisk never should advertise a codec that is known to be not a common codec? This means related to the second example above: Asterisk shouldn't advertise g722 in the 200 OK because it correctly does not want to have g722 but alaw to prevent transcoding. Related to the first example (real one way audio situation), the problem most probably wouldn't have occurred if Asterisk wouldn't have sent g722/alaw/ulaw in the 200 OK to the ISP but alaw/ulaw or just alaw. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-01-20 06:08:12.471-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: Joshua C. Colp (jcolp) 2017-01-20 07:40:10.206-0600 A change has gone into the 13 and 14 branches which should resolve this issue already. You can test using those branches or wait for the next release. If the problem is still not resolved on those please provide new log information including console output, SIP traffic (pjsip set logger on), RTP (rtp set debug on), and configuration. By: Michael Maier (micha) 2017-01-20 08:58:28.323-0600 Thanks for the patch. The patch fixes the above described problem partly: Fixed is the difference between PJSIP on the one hand and Asterisks own rtp-part sending on the other hand. This means: Asterisk now uses the codec accordingly the primary codec in the 200 OK SDP sent to the caller: Now, Asterisk uses the same codec as the caller (g722). The second part of the bug report is not addressed by this patch: Asterisk / PJSIP should not send g722 in the 200 OK SDP to the caller as codec at all, because callee doesn't support it. Asterisk now has to transcode between them although there is a common codec (alaw), which both UAs support w/o transcoding. The patch unfortunately went the wrong way to resolve the "difference" problem: Asterisks decision without this change to use alaw to C610IP was correct. But the 200 OK SDP w/o removing g722 was wrong. The 200 OK SDP from Asterisk to 610IP should contain as codecs alaw/ulaw and not g722/alaw/ulaw - because alaw is the preferred codec in this case, if one of the UAs doesn't support g722 to prevent transcoding. By: Asterisk Team (asteriskteam) 2017-01-20 08:58:28.564-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Joshua C. Colp (jcolp) 2017-01-20 09:03:55.206-0600 The behavior you are asking for has been asked for a few times in the past, and it is not something to be done in PJSIP. It is a core change required to convey that information across upon answer. Right now the caller doesn't know what the callee actually negotiated. Each side is done independently. If you'd like to discuss how to implement it that can be done on the asterisk-dev mailing list. We currently don't accept feature requests such as that on the issue tracker though. | ||||