Hi team, I tried in asterisk 18.23 / 20.9, direct media using opus codec call between pjsip endpoints has no audio, but when i change codec to ulaw it works fine and also when i change chan_pjsip.so to chan_sip.so, direct media using opus works fine. only when i start using chan_pjsip.so with opus codec i am having issue. i wanted to deploy direct media with opus codec. please help me to fix it.
There is no team; this is a peer support forum.
You will need to provide the full log, with verbosity at least 3, and with “pjsip set logger on” in effect.
Hi @david551
Thank you for your guidance. I’ve attached the logs as requested. Could you please review them and offer your suggestions for resolving the issue?
ast_verbose_full_PJSIPendpoints.txt (59.8 KB)
Does this work without direct media?
The log shows a successful set up of direct media, meaning that Asterisk is no longer involved. The call is cleared by one of the phones.
Although not all the parameters given by the phones are being passed through, the same is true before the switch to direct media, so, if the phones don’t like being told to send without the options, that would also break non-direct media.
I would note that you are using FreePBX. Answers here will assume bare Asterisk and might not be possible with FreePBX. Also it is unusual to use direct media with FreePBX, as you lose a lot of its features if you do.
@david551
Yes, it works fine when called without direct media.
I have used plain asterisk also but getting same result. If i change codec to ulaw or g722, direct media works fine.
if i use chan_sip, direct media using opus codec works fine, only when i use chan_pjsip with opus codec direct media there’s no audio in both sides. I can share you the logs with pjsip direct media ulaw codec (works fine) and chan_sip direct media opus codec (works fine) if you wanted to verify.
As I said the phone are accepting the switch to direct media, which puts at least some of the blame on the phone. You would need to sue “sip set debug on”, to get the log from chan_sip, and compare the SDP.
What may have upset it is that the dynamic payload type number for the two legs is different. I don’t know if that should be a problem, however there are scenarios where the PABX could be forced into using different values,
Looking more closely, I don’t think what Asterisk is doing will work. It is telling each side to accept traffic with the payload type that was agreed, for that side, and also to send traffic with that type, but the types are different on both sides.
Whilst one solution, in this case, would be for the payload type to be passed to the outgoing leg, but as noted above there are cases where this wouldn’t be possible. Some research would be needed to find what, if anything, is legal and possible when the same underlying type gets two different type numbers.
ulaw has a standardised payload type number, so wouldn’t have this problem.
@david551
Yes, payload type is different for both legs. I have tried a few combinations with codecs.conf also but no luck. I am attaching chan_sip full log for your reference, please share your suggestions.
ast_verbose_full_SIPendpoints.txt (42.4 KB)
It seems to be the same on both legs for chan_sip.
You need to research whether it is permitted to change the payload number assignments on a re-INVITE. If not there may not be a general solution to the problem.
I think I would raise an issue, but the easier answer (trying to use the same numbers on the B leg of a simple, two party. one in, one out, call), would only justify a feature request, as there are cases where one could bridge two calls that didn’t have a causal connection.
If it is permissible to change allocations on a re-INVITE, one could raise it as a bug (solution re-INVITE brings one into line with the other).
@david551
thank you for your guidance. I will try to register it as bug.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.