Hello Asterisk Community,
I’m experiencing an issue with video calls between a SIP doorbell device and mobile apps through Asterisk 20.5.2. The strange part is that video works perfectly when the mobile app calls the doorbell, but fails when the doorbell calls the mobile app.
Environment:
- Asterisk 20.5.2 on Linux
- Doorbell: DnakeVoip v2.0 (local network, UDP, supports H264)
- Mobile apps: Using TLS/SRTP over public internet with NAT
- PBX has public IP configured
Problem Description:
- Mobile app (ext 100) → Doorbell (ext 165):
Audio + Video works perfectly (99% of the time after enabling ICE/STUN) - Doorbell (ext 165) → Extension 605 → Mobile app (ext 100):
Audio works, but NO video
Important call flow detail:
The doorbell doesn’t call extension 100 directly. Instead:
- Doorbell dials extension 605 (ring group)
- Extension 605 executes several actions including dialing
Local/mobilephones@default - The
mobilephonesextension waits 7 seconds for push notifications to wake up mobile apps - After the wait, it dials all registered contacts for extension 100
- This indirect call path through Local channels is where video fails
When examining the logs, I notice:
- Different call flows use different ICE/STUN behavior
- Working calls show proper ICE negotiation
- Failed calls show “ICE no RTCP candidates; skipping checklist”
- The Local channel bridge might be affecting media negotiation
- RTP packets are flowing in both directions
Working: Mobile App (100) ----INVITE----> Doorbell (165) [Direct SIP call with proper ICE/STUN]
Failing: Doorbell (165) ----INVITE----> Extension 605 | v Dial(…&Local/mobilephones@default) | v Wait(7) for push notifications | v Dial(${PJSIP_DIAL_CONTACTS(100)}) [ICE negotiation fails here]
Relevant Configurations:
Relevant extension 605 configuration:
; Doorbell ring group that fails video
exten => 605,1,NoOp(EXECUTING 605 call)
same => n,System(/usr/some_one_at_door.sh&)
same => n,Dial(&Local/mobilephones@default) ; there are some other sip extension being called that are in local n/w and they work ok
same => n,Hangup()
; Mobile phones handler with push notification wait
exten => mobilephones,1,Ringing()
same => n,Wait(7) ; Wait for devices to register via push
same => n,NoOp(First attempt to dial)
same => n,Dial(${PJSIP_DIAL_CONTACTS(100)})
same => n,Hangup()
**/etc/asterisk/pjsip_wizard.conf** (excerpt):
```ini
[default-template]
type = wizard
accepts_auth = yes
transport = transport-udp
aor/qualify_frequency = 90
endpoint/disallow = all
endpoint/allow = ulaw,alaw,gsm,g726,h264,mpeg4,vp8
endpoint/direct_media = yes
[nat-template](default-template)
transport = transport-tls
endpoint/direct_media = no
endpoint/rtp_symmetric = yes
endpoint/ice_support = yes
; Mobile endpoint
[100](nat-template)
inbound_auth/username = 100
inbound_auth/password = xxxxx
aor/max_contacts = 10
; Doorbell endpoint
[165](default-template)
inbound_auth/username = 165
inbound_auth/password = xxxxx
endpoint/callerid = 165 <DOORBELL>
/etc/asterisk/pjsip.conf (excerpt):
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5060
[transport-tls]
type = transport
protocol = tls
bind = 0.0.0.0:5061
cert_file = /etc/asterisk/keys/asterisk.crt
local_net = 192.168.1.0/24
external_media_address = X.X.X.X
external_signaling_address = X.X.X.X
/etc/asterisk/rtp.conf:
[general]
rtpstart=30000
rtpend=30048
stunaddr=stun.l.google.com:19302
icesupport=yes
strictrtp=yes
Log excerpts showing the issue:
Working call (mobile → doorbell):
-- PJSIP/100-0000003b is making progress passing it to PJSIP/165-0000003c
> 0xb4556770 -- Strict RTP learning after remote address set to: X.X.X.X:44930
> 0xb678c060 -- Strict RTP learning after remote address set to: X.X.X.X:41694
-- PJSIP/165-0000003c answered PJSIP/100-0000003b
[ICE negotiation successful]
Failed call (doorbell → mobile):
-- PJSIP/100-00000014 is ringing
> 0xb6656340 -- Strict RTP learning after remote address set to: X.X.X.X:38581
[WARNING] res_rtp_asterisk.c:1186 ast_rtp_ice_start: ICE no RTCP candidates; skipping checklist
> 0xb65f93e0 -- Strict RTP learning after remote address set to: X.X.X.X:48613
[No ICE negotiation occurs]
RTP debug shows packets flowing:
Got RTP packet from 192.168.1.165:6200 (type 102, seq 000510, ts 910080, len 001300)
Sent RTP packet to 192.168.1.169:42748 (type 99, seq 012481, ts 910080, len 001300)
What I’ve tried:
- Disabled ICE on doorbell endpoint
- Set direct_media = no
- Added rtp_symmetric = yes
- Configured STUN servers
Questions & Observations :
1.After enabling ICE/STUN on endpoint 100 and in rtp.conf, mobile→doorbell calls work reliably (99%)
2.Why does ICE/STUN behavior differ based on call direction?
3. Is there a way to force consistent media negotiation?
4. Could the H264→VP8 transcoding be related to the video issue?
5. The wait time for push notifications might affect ICE negotiation
6. Could the Local channel used in the ring group be affecting media negotiation?
I can provide full debug logs and packet captures if needed. Any insights would be greatly appreciated!
Thank you!
logs.txt (459.0 KB)