ha-plugins
ha-plugins copied to clipboard
arnonym
Sending DTMF not working, Inconsistent responses
Using FritzBox 7590 on OS version 7.57, Addon on Version 3.2, HA Core 2023.11.3, Supervisor 2023.11.6, OS 11.2
I have an automation (and script) set up to first, dial a number (script) then wait until a webhook is called, then sending a DTMF job to press #1. Lastly the automation ends the call.
Now the problem is that if I am using the addon to call my mobile phone internally (via the **620) it just works. You may recognize that that is indeed not a problem. And you would be correct. My phone rings, the timeout is set to 15s, if I answer in those 15s I can hear how the caller (homeassistant) is pressing both buttons and then ending the call. The Problem arrises however when I change the internal call number to the **2 (my intercom). The logs don't show any errors (at least I think) but the intercom station is still not able to open the door. (I tested and the exact same prosedure is working when calling internally from my mobile phone via the Fritz!FON app or using a telephone.)
Here is my HA-SIP config:
sip:
enabled: true
registrar_uri: sip:fritz.box
id_uri: sip:[email protected]
realm: "*"
user_name: homeassistant
password: password
answer_mode: listen
settle_time: 1
incoming_call_file: ""
My script for dialing the call:
alias: DialDoorOpenener
sequence:
- service: hassio.addon_stdin
data:
addon: c7744bff_ha-sip
input:
command: dial
number: sip:**[email protected]
ring_timeout: 15
sip_account: 1
webhook_to_call:
call_established: "-huv8wswQGAIDUwLNPy3j14pK"
mode: single
icon: mdi:key-chain
My automation for reacting to the sent webhook, pressing the buttons and ending the call:
alias: React to open door call
description: ""
trigger:
- platform: webhook
allowed_methods:
- POST
- PUT
local_only: true
webhook_id: "-huv8wswQGAIDUwLNPy3j14pK"
id: webhook
condition: []
action:
- choose:
- conditions:
- condition: trigger
id:
- webhook
sequence:
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 0
- service: hassio.addon_stdin
data:
addon: c7744bff_ha-sip
input:
command: send_dtmf
number: sip:**[email protected]
digits: "#1"
method: sip_info
- service: hassio.addon_stdin
data:
addon: c7744bff_ha-sip
input:
command: hangup
number: sip:**[email protected]
sip_account: 1
default:
- service: notify.mobile_app_nothing_phone_1
data:
message: Nope
mode: single
Here are the logs after running the first script (all that I could export at least since HA doesnt keep them for long):
Signal=1
Duration=180
--end msg--
00:10:28.725 pjsua_core.c .RX 441 bytes Response msg 200/INFO/cseq=29815 (rdata0x7fa8aa7088) from UDP 192.168.2.1:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.13:5060;rport=5060;branch=z9hG4bKPjnGra0cUdsXb7YeaHeol94nRjb-W4VAxT
From: <sip:[email protected]>;tag=cOOSp.K-dRWkeMw7FR8eWMp3uei3Un1l
To: <sip:**[email protected]>;tag=82576A769B7CB897
Call-ID: KpsWo5BMNAw54BGJT8Mep7MEN6Y0PaXk
CSeq: 29815 INFO
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep 2 2023)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0
--end msg--
00:10:28.725 pjsua_call.c .....Call 2: DTMF sent successfully with INFO
00:10:28.727 pjsua_core.c .RX 441 bytes Response msg 200/INFO/cseq=29816 (rdata0x7fa8aa7098) from UDP 192.168.2.1:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.13:5060;rport=5060;branch=z9hG4bKPj63uINkZymrG9czKsx0AO.oFb2fPzbUjw
From: <sip:[email protected]>;tag=cOOSp.K-dRWkeMw7FR8eWMp3uei3Un1l
To: <sip:**[email protected]>;tag=82576A769B7CB897
Call-ID: KpsWo5BMNAw54BGJT8Mep7MEN6Y0PaXk
CSeq: 29816 INFO
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep 2 2023)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0
--end msg--
00:10:28.727 pjsua_call.c .....Call 2: DTMF sent successfully with INFO
| 00:10:28.760978 [ ] Got "hangup" command for sip:**[email protected]
| 00:10:28.761258 [1] Hang-up.
00:10:28.761 pjsua_call.c Call 2 hanging up: code=0..
00:10:28.761 pjsua_media.c .Call 2: deinitializing media..
00:10:28.761 pjsua_media.c ..
[CONFIRMED] To: sip:**[email protected];tag=82576A769B7CB897
Call time: 00h:00m:03s, 1st res in 86 ms, conn in 851ms
#0 audio iLBC @8kHz, sendrecv, peer=192.168.2.1:7082
SRTP status: Not active Crypto-suite:
ICE role: Unknown, state: Candidate Gathering, comp_cnt: 2
RX pt=99, last update:00h:00m:02.733s ago
total 103pkt 5.1KB (9.2KB +IP hdr) @avg=13.2Kbps/23.8Kbps
pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 0.125 1.646 4.125 3.875 0.694
TX pt=99, ptime=30, last update:00h:00m:01.388s ago
total 21pkt 1.0KB (1.8KB +IP hdr) @avg=2.7Kbps/4.8Kbps
pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 0.000 0.000 0.000 0.000 0.000
jitter : 7.500 7.500 7.500 7.500 0.000
RTT msec : 0.000 0.000 0.000 0.000 0.000
00:10:28.762 pjsua_media.c ...Media stream call02:0 is destroyed
00:10:28.762 icetp00 ..Stopping ICE, reason=media stop requested
00:10:28.762 srtp0x7fa7c5e830 ..Destroying SRTP transport
00:10:28.762 icetp00 ..Destroying ICE transport
00:10:28.762 ice_session.c ..ICE session 0x7fa7eac5d8 destroyed
00:10:28.762 icetp00 ..ICE stream transport 0x7fa7c2d268 destroyed
00:10:28.763 icetp00 ..ICE transport destroyed
00:10:28.763 srtp0x7fa7c5e830 ..SRTP transport destroyed
| 00:10:28.763252 [1] Call disconnected
| 00:10:28.763508 [ ] Calling webhook sip_call_webhook_id with data {'event': 'call_disconnected', 'caller': 'sip:**[email protected]', 'parsed_caller': '**2', 'sip_account': 1}
| 00:10:28.784424 [ ] Webhook response 200 b''
| 00:10:28.785529 [ ] Remove from state: sip:**[email protected]
00:10:28.785 pjsua_core.c ....TX 368 bytes Request msg BYE/cseq=29817 (tdta0x7fa7c307e8) to UDP 192.168.2.1:5060:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.13:5060;rport;branch=z9hG4bKPjW2ySd.WGXf2Yx1WiaLnou4TjgSX.ta9y
Max-Forwards: 70
From: sip:[email protected];tag=cOOSp.K-dRWkeMw7FR8eWMp3uei3Un1l
To: sip:**[email protected];tag=82576A769B7CB897
Call-ID: KpsWo5BMNAw54BGJT8Mep7MEN6Y0PaXk
CSeq: 29817 BYE
Content-Length: 0
--end msg--
00:10:28.792 pjsua_core.c .RX 724 bytes Response msg 200/BYE/cseq=29817 (rdata0x7fa8aa70a8) from UDP 192.168.2.1:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.13:5060;rport=5060;branch=z9hG4bKPjW2ySd.WGXf2Yx1WiaLnou4TjgSX.ta9y
From: <sip:[email protected]>;tag=cOOSp.K-dRWkeMw7FR8eWMp3uei3Un1l
To: <sip:**[email protected]>;tag=82576A769B7CB897
Call-ID: KpsWo5BMNAw54BGJT8Mep7MEN6Y0PaXk
CSeq: 29817 BYE
X-RTP-Stat: CS=0;PS=56;ES=195;OS=2800;SP=0/0;SO=0;QS=-;PR=52;ER=195;OR=6010;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=-/-;EN=iLBC-30,G722;DE=iLBC-30,G722;JI=60,31;DL=1,1,1;IP=192.168.2.1:7082,192.168.2.13:4030
X-RTP-Stat-Add: DQ=4;DSS=0;DS=0;PLCS=8704;JS=64
X-SIP-Stat: DRT=0;IR=0
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep 2 2023)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0
--end msg--
00:10:29.763 pjsua_aud.c Closing sound device after idle for 1 second(s)
00:10:29.763 pjsua_aud.c .Closing null sound device..
Hi @Pytonballoon810,
did I understand correctly, that the Intercom does not react to the dialtones? Did you try the other methods of sending DTMF via SIP, namely "in_band" and "rfc2833"?
The intercom is supposed to activate the door opener upon typing #1. It works when typing manually but not with the SIP client. I already tried all three methods. I also think it worked about 6-10 months ago. Then it stopped working without making any changes... No idea why.
Did you try with a longer delay?
I originally had a 3 sec delay between both typing the digits and ending the call. Still didnt work
Ok so I fixed it now. I put each character in one by one in two seperate stdin calls with a 500ms delay between each digit. Maybe you wanna fix that in your code (or I find the time to fix it myself.) Thanks for the help anyways :)
Nice you figured that out! ha-sip is only calling the send DTMF function of pjsip, and for rfc2833 and sip_info methods it's not possible to set a delay between tones. You can only set the duration of each tone. For in_band you can control both. It would be interesting if increasing the tone length would also work with your intercom. In the code you would just need to increase the value of DEFAULT_DTMF_ON, if you're able to test that yourself.