I want to set 2 extensions to make audio and video connection by Direct Media RTP Transport.
Extensions are behind NAT and use STUN. I have Enabled Direct media but I see that Asterisk is transforming INVITE messages and SDP headers inside it and forcing RTP streams to pass through Asterisk. Call is established and user can cancel it but RTP is passing always through Asterisk.
What are configuration options which can influence this behavior in Asterisk ? Is there something special in extensions configuration to make this fail ?
Conditions have to be exactly right. Same codecs, same DTMF, no special features enabled. Getting a debug log[1] and looking for bridge_native_rtp will show log messages for its decision.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] res_rtp_asterisk.c: (0x7ff1d405f5c0) RTP 0x7ff1d40c1d10 -- Received packet from 86.33.88.196:29309, dropping due to strict RTP protection. Qua$
[[2024-11-18 13:06:05] DEBUG[1341][C-00000008] res_rtp_asterisk.c: (0x7ff1d405f5c0) RTP 0x7ff1d40c1d10 -- Received packet from 86.33.88.196:29309, dropping due to strict RTP protection. Qu$
[2024-11-18 13:06:05] VERBOSE[1341][C-00000008] res_rtp_asterisk.c: 0x7ff1d40c1d10 -- Strict RTP qualifying stream type: audio
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] res_rtp_asterisk.c: (0x7ff1d405f5c0) RTP 0x7ff1d40c1d10 -- Received packet from 86.33.88.196:29309, dropping due to strict RTP protection. Wil$
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] res_rtp_asterisk.c: (0x7ff1d405f5c0) RTP 0x7ff1d40c1d10 -- Received packet from 86.33.88.196:29309, dropping due to strict RTP protection. Wil$
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] res_rtp_asterisk.c: (0x7ff1d405f5c0) RTP 0x7ff1d40c1d10 -- Received packet from 86.33.88.196:29309, dropping due to strict RTP protection. Wil$
[2024-11-18 13:06:05] VERBOSE[1341][C-00000008] res_rtp_asterisk.c: 0x7ff1d40c1d10 -- Strict RTP switching source address to 86.33.88.196:29309
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] acl.c: For destination '86.33.88.196', our source address is '10.2.0.4'.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] res_rtp_asterisk.c: (0x7ff1d405f5c0) RTCP setting address on RTP instance
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] chan_pjsip.c: Oooh, got a frame with format of g722 on channel 'PJSIP/601-0000000d' when we're sending 'ulaw', switching to match
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] channel.c: Channel PJSIP/601-0000000d setting write format path: ulaw -> g722
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] channel.c: Channel PJSIP/601-0000000d setting read format path: ulaw -> g722
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge_native_rtp.c: Bridge '20f3abbc-dbf4-4d06-a687-702d7e544228'. Checking compatability for channels 'PJSIP/601-0000000d' and 'PJSIP/602-0$
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge_native_rtp.c: Bridge '20f3abbc-dbf4-4d06-a687-702d7e544228' can not use native RTP bridge as channel 'PJSIP/601-0000000d' has DTMF hooks
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] dahdi/bridge_native_dahdi.c: Channel 'PJSIP/601-0000000d' has DTMF hooks.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] dahdi/bridge_native_dahdi.c: Bridge 20f3abbc-dbf4-4d06-a687-702d7e544228: Cannot use native DAHDI. Channel 'PJSIP/601-0000000d' not compatibl$
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge.c: Bridge technology native_dahdi is not compatible with properties of existing bridge.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge.c: Bridge technology softmix does not have any capabilities we want.
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge.c: Chose bridge technology simple_bridge
[2024-11-18 13:06:05] DEBUG[1341][C-00000008] bridge.c: Bridge 20f3abbc-dbf4-4d06-a687-702d7e544228 is already using the new technology.
[2024-11-18 13:06:05] DEBUG[27177] manager.c: Examining AMI event:
2024-11-18 13:06:05] VERBOSE[1341][C-00000008] res_rtp_asterisk.c: 0x7ff1d40c1d10 -- Strict RTP qualifying stream type: audio
This is log around bridge_native_rtp.c Sims like Bridge native has not been chosen because of DTMF hooks. In the and it chooses simple bridge technology. Is this correct? Which bridge is needed for DirectMedia Setup? Do I need to make configuration changes on extensions side or on Asterisk side or both ?
The bridge_native_rtp module is needed for direct media. Configuration would need to change on the Asterisk side, specifically disabling any DTMF related features to Dial.
1 Like
Can you pinpoint which Dial features are likely causing this issue? Or more specifically in which config files or parts of it to look for solution?
It would be part of dialplan, commonly in extensions.conf. The documentation for Dial[1] states what options involve DTMF.
I have managed to setup Asterisk to work for p2p connection. But now I have silence in RTP stream. After watching tcpdump from both sides seems like RTP is not symmetric as it should be.
Both IP stations are behind NAT and have STUN enabled. Asterisk is behind NAT too but with 1:1 mapping from internal to external IP address.
Call is establishing and you can cancel it with no problem. So SIP is working. RTP stream is going from each station out but not coming in. Is this problem with Asterisk or IP stations ?
If NAT is involved, even with STUN, there is no guarantee that the equipment doing NAT will allow such traffic to flow.
You can only use symmetric RTP on one side. It relies on receiving RTP to learn the address of the other side.
Is there an easy way to test NAT functionality with STUN to verify if equipment is allowing it or not ? Is there some tool available to put in in same network where are IT stations to verify if traffic is going in and out ?
I see there is Symmetric RTP checbox in IT stations config. Does this mean that such config option mast be enabled only on one side?
You can enable symmetric media on both sides, but only one side can rely on it. One side must include the correct, external, address in its SDP. For Asterisk that would normally be achieved by specifying the media address in the configuration.
Note I don’t know how Asterisk handles direct media when it has to use symmetric RTP to find the peer media address. It would need to wait for some non-direct media to learn the other sides’ addresses, before re-INVITING to direct media.
My feeling is that, if you want to use direct media between two parties inside different NATs, you should only use devices that don’t need to rely on symmetric media at the other end.
-- Executing [602@itsv-phones:1] Dial("PJSIP/601-00000006", "PJSIP/602,20") in new stack
-- Called PJSIP/602
-- PJSIP/602-00000007 is ringing
> 0x7a13800b6400 -- Strict RTP learning after remote address set to: 95.168.120.11:12522
-- PJSIP/602-00000007 answered PJSIP/601-00000006
> 0x7a1380069230 -- Strict RTP learning after remote address set to: 86.33.93.153:59461
-- Channel PJSIP/602-00000007 joined 'simple_bridge' basic-bridge <d2c11b62-9289-430a-9da2-04eeb3c4eb90>
-- Channel PJSIP/601-00000006 joined 'simple_bridge' basic-bridge <d2c11b62-9289-430a-9da2-04eeb3c4eb90>
> Bridge d2c11b62-9289-430a-9da2-04eeb3c4eb90: switching from simple_bridge technology to native_rtp
> Remotely bridged 'PJSIP/601-00000006' and 'PJSIP/602-00000007' - media will flow directly between them
> 0x7a13800b6400 -- Strict RTP learning after remote address set to: 95.168.121.45:12522
> 0x7a1380069230 -- Strict RTP learning after remote address set to: 86.33.93.153:59461
What does this Strict RTP mean ? Is this normal when changing from SIMPLE bridge to NATIVE bridge that one side changes IP address ? From 95.168.120.11:12522 to 95.168.121.45:12522 ? Why is this happening ?
This isn’t under Asterisk’s control. I’d suggest it was unusual, but it isn’t forbidden.
But in the contest of STUN/NAT handling IP address changing could be problem because each change must be renegotiated with SIP first and STUN binding mast be correct to work it properly. In my current configuration I am using pjsip driver with p2p configuration for Asterisk. Each station is behind NAT in different local network and uses STUN. In theory this could work if symmetric RTP is used on both stations and correct external IP addresses and ports are in SDP header. Do you think that such setup could work over Asterisk?
Assuming “header” was an error in “SDP header”, if the correct address is present in all the SDP c lines, and correct port in all the m lines, there is no need for symmetric media.