Direct Media not working when using TLS

Hi there

Need some help please.

I have 2 systems and the one is using non-TLS with just TCP transport and the other is setup with TLS transport.

Everything is working in both systems. (The TLS certificates have been applied in the TLS system)

The problem I have is that both systems must use the “announcement” Dial() feature, e.g.

Dial(PJSIP/${EXTEN},300,aA(call-recorded:call-recorded))

This is actually also working in both systems as well, all good so far.
But both systems must also make use of Direct Media which is where I’m seeing an issue on my TLS system.

What I’m seeing in the TCP transport system is that it works exactly as I expect it to.
The call is answered and the initial RTP is setup with the Asterisk server since the announcement is played from there, and once the announcement is complete the Asterisk then sends out Re-Invites to both sides with new SDP connection information and the rest of the call then flows directly between endpoints. This is exactly what I want and works perfectly in the TCP transport system.

For the TLS system however, the RTP is always setup directly with the Asterisk and it never moves to Direct Media between endpoints after the announcement is played (successfully). The RTP remains flowing through the Asterisk.

I’m pretty new to TLS and secure setup in general, but as stated I have it all working accept for this one issue of the Direct media.

Is Direct Media supported in a TLS setup?

I have enabled verbose sip logging and debug 1 on both systems and in the debug output on the TCP system, you can clearly see it play the “call-recorded” announcement and you can then see the Asterisk sends out New Re-Invites to both ends with conneciton info to change the RTP directly between them.

But in the TLS system I don’t see this happen at all, after the “call-recorded” is played it then keeps the RTP on the Asterisk server until I end the entire call where you next see a SIP BYE.

I have compared the two debugs side by side and do see some differences between the two systems and can only guess its due to the TLS and encrypted SRTP where the change comes in.

In the TCP system it seems to eventually state that it is choosing the “technology native_rtp

DEBUG[30364][C-0000001d] bridge.c: Chose bridge technology native_rtp

In the TLS system at around the same time during the call, it however traces “can not use native RTP bridge as it was forbidden while getting details” and ultimately ends up choosing “Chose bridge technology simple_bridge” which is then where it stays for the entire call and NO Re-Invites are seen.

[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3010-00000076 setting write format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3000-00000077 setting read format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3010-00000076 setting write format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3010-00000076 setting read format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3000-00000077 setting write format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] stasis.c: Topic 'bridge:all/bridge:73c14173-e67e-415c-8f23-682946be3649': 0x7f28e800dbe0 created
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge_native_rtp.c: Bridge '73c14173-e67e-415c-8f23-682946be3649' can not use native RTP bridge as two channels are required
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge technology softmix has less preference than simple_bridge (10 <= 50). Skipping.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Chose bridge technology simple_bridge
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: calling simple_bridge technology constructor
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: calling simple_bridge technology start
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge_channel.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: 0x7f28e80139c0(PJSIP/3000-00000077) is joining
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge_channel.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: pushing 0x7f28e80139c0(PJSIP/3000-00000077)
[Mar 28 01:20:01] VERBOSE[60310][C-00000048] bridge_channel.c: Channel PJSIP/3000-00000077 joined 'simple_bridge' basic-bridge <73c14173-e67e-415c-8f23-682946be3649>
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge_native_rtp.c: Bridge '73c14173-e67e-415c-8f23-682946be3649' can not use native RTP bridge as two channels are required
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge.c: Bridge technology softmix does not have any capabilities we want.
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge.c: Chose bridge technology simple_bridge
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge.c: Bridge 73c14173-e67e-415c-8f23-682946be3649 is already using the new technology.
[Mar 28 01:20:01] DEBUG[60310][C-00000048] bridge.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: 0x7f28e80139c0(PJSIP/3000-00000077) is joining simple_bridge technology
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge_channel.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: 0x7f28e8010660(PJSIP/3010-00000076) is joining
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge_channel.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: pushing 0x7f28e8010660(PJSIP/3010-00000076)
[Mar 28 01:20:01] VERBOSE[60307][C-00000048] bridge_channel.c: Channel PJSIP/3010-00000076 joined 'simple_bridge' basic-bridge <73c14173-e67e-415c-8f23-682946be3649>
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge_native_rtp.c: Bridge '73c14173-e67e-415c-8f23-682946be3649'.  Checking compatability for channels 'PJSIP/3000-00000077' and 'PJSIP/3010-00000076'
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge_native_rtp.c: Bridge '73c14173-e67e-415c-8f23-682946be3649' can not use native RTP bridge as it was forbidden while getting details
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge technology softmix does not have any capabilities we want.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Chose bridge technology simple_bridge
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge 73c14173-e67e-415c-8f23-682946be3649 is already using the new technology.
[Mar 28 01:20:01] DEBUG[60307][C-00000048] bridge.c: Bridge 73c14173-e67e-415c-8f23-682946be3649: 0x7f28e8010660(PJSIP/3010-00000076) is joining simple_bridge technology
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3010-00000076 setting read format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3000-00000077 setting write format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3000-00000077 setting read format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[60307][C-00000048] channel.c: Channel PJSIP/3010-00000076 setting write format path: alaw -> alaw
[Mar 28 01:20:01] DEBUG[3279] cdr.c: Finalized CDR for PJSIP/3000-00000077 - start 1711588796.513386 answer 1711588799.619826 end 1711588801.751573 dur 5.238 bill 2.131 dispo ANSWERED
[Mar 28 01:20:08] VERBOSE[3283] res_pjsip_logger.c: <--- Received SIP request (569 bytes) from TLS:10.58.130.4:62474 --->
BYE sip:asterisk@10.57.138.181:5061;transport=TLS SIP/2.0

The setup of the two system are very similar and I can’t see any difference or why it would be failing, apart from the one using TLS and the other not.

The config used in the TCP system:

[extension-defaults](!)
type = wizard
accepts_auth = yes
accepts_registrations = yes
transport = transport-tcp
endpoint/allow = !all,alaw,ulaw
endpoint/context = outbound
endpoint/dtmf_mode = auto
endpoint/direct_media = yes
aor/qualify_frequency = 30
aor/max_contacts = 1
aor/remove_existing = yes

[1000](extension-defaults)
inbound_auth/username = 1000
inbound_auth/password = 123456
endpoint/callerid = <1000>

[2002](extension-defaults)
inbound_auth/username = 2002
inbound_auth/password = 123456
endpoint/callerid = <2002>

[transport-tcp]
type=transport
protocol=tcp
bind=0.0.0.0:5060

Config used in the TLS system

[extension-defaults-tls](!)
type = wizard
accepts_auth = yes
accepts_registrations = yes
transport = transport-tls
endpoint/allow = !all,alaw,ulaw
endpoint/context = outbound
endpoint/dtmf_mode = auto
endpoint/direct_media = yes
endpoint/media_encryption = sdes
aor/qualify_frequency = 30
aor/max_contacts = 1
aor/remove_existing = yes

[3000](extension-defaults-tls)
inbound_auth/username = 3000
inbound_auth/password = 123456
endpoint/callerid = <3000>
endpoint/rewrite_contact = yes

[3010](extension-defaults-tls)
inbound_auth/username = 3010
inbound_auth/password = 123456
endpoint/callerid = <3010>
endpoint/rewrite_contact = yes

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
method=tlsv1_2
ca_list_file=/pathtocerts/ca.pem
cert_file=/pathtocerts/server-cert.pem
priv_key_file=/pathtocerts/private.key

Would very much appreciate any help or assistance here.

Brad

Direct media is not possible when SRTP is in use.

Thank you for confirming, at least I know now.

Many thanks