Directmedia=yes is not working since upgrade to Asterisk 13

Hi group

I have a large number of Asterisk systems in production and know that direct media has worked previously for me.
With recent development of my new release along with an upgrade to Asterisk 13, I cannot for the life of me get direct media to work. I am testing by just making a simple extension to extension call and doing an RTP debug from the Asterisk CLI.
The following is confirmed:

  1. There are no Dial options in use
  2. The codecs are the same as they use the same sip template
  3. sip.conf has directmedia=yes which is confirmed with sip show peer in the Asterisk CLI
  4. I have reloaded and in fact restarted Asterisk

Any more ideas?

Regards
Michael

As you re using the same codec and no options on the dial command, I readed a thread about the same issue and it was solved by setting directmedia option directly on peer section instead of the [general] section, Also I dont think it is related with the RTP but it also mentioned changing type to peer instead of friend

Hi thanks for the quick response.

Sorry I should have mentioned that it is already being done directly in the peer section with a type=peer

Thanks
Mike

when using directmedia=yes , Asterisk will attempt to send SIP reinvites in order to allow the endpoints to communicate directly. You can also try directrtpsetup=yes This sets up the call directly with media peer-2-peer without re-invites. This last option wont work for video and others conditions, so read the asterisk documentation http://svn.digium.com/svn/asterisk/trunk/configs/samples/sip.conf.sample

directrtpsetup=yes is still experimental from sip.conf and its not what I want anyway and yes I have read the documentation thanks.

Its just not working for some reason and I dont know what it is.

Thanks
Mike

Enabling debug to the console in logger.conf and doing “core set debug 2” will cause a message to get output amongst everything which tells you why it didn’t do it.

Yes awesome thanks Josh.
Im learning about the new bridging architecture and local and remote Native RTP bridge.
Im not getting either as it comes up with:
‘can not use native RTP bridge as two channels are required’

What does this mean?
PS Debug is attached.

Regards
Mike

Debug Call between 1401 and 1402.txt (56.6 KB)

Channels are added individually to the bridge, so the real reason is further down:

[Jul 21 12:14:08] DEBUG[11955][C-00000009]: bridge_native_rtp.c:334 native_rtp_bridge_compatible_check: Bridge ‘b25a204f-aea7-4cd1-abed-d7b38693970d’ can not use native RTP bridge as channel ‘SIP/1402-00000013’ has features which prevent it

Which will occur if there is something on one of the channels which needs to get access to the audio stream. WIth chan_sip I’m not sure what that would be.

Yes thanks Josh for that.
Unfortunately I don’t know what it is either as codecs are the same and I have no Dial options configured.

Regards
Michael Knill

Does anyone have any other ideas? I would really like to get this working!

Please say whether it only works with directmedia or only works without it.

Please provide the SDP traces requested.

Please try without the unsupported directmeidasetup option.

Hi David

Im a little unsure of your first question. The call is always successful, but never natively bridged which will be an issue for some of my systems that are remotely hosted.
I have attached a file containing debugs and SDP of a call from 1403 to 1402.
I have directmedia=yes and directrtpsetup=no in the [general] section of sip.conf

Thanks so much for your help.
Regards
Mike

Asterisk and SDP debug 1403 to 1402.txt (65.6 KB)

I think the first question was the result of confusing two threads.

Your log is saying that the channel has incompatible features, which suggests you have something requiring DTMF to be detected, (e.g. TtXx, etc. on DIal) or media to be intercepted or recorded (Monitor, ChanSpy, etc.).

Thanks David but I dont have these things you mentioned configured.
I am not passing ANY Dial options for this call and I do not have any Monitoring or ChanSpy activated.
Can you think of anything else that could be doing it? I think from the logs, it appears it does not like something configured on the destination peer?

Thanks for your help.
Mike

Does anyone have any further ideas on this? Please, please!
Mike

Wow I cant believe with all the research, posting on this forum and eventually using Digium support that I eventually find the problem myself.

jbenable=no in sip.conf

Obviously if you enable a jitter buffer, you cant do native bridging. So simple yet not found anywhere.
Well I hope this can help someone else.

Thanks
Mike

Why do you feel surprised, you are also capable to produce effective knowledge and find answers to your own problem and share the answer with others as a good member