Hello, I just got a Hikvision Doorbell, model DS-KB8113-IME1(B), and have it registered to an Asterisk server running on my LAN. I am using just the doorbell > Asterisk > Linphone App, and do not have a Hikvision Indoor Station. I was able to get the following scenarios partially working, but was hoping to iron out the kinks.
Doorbell Button to call single phone
By using Progress(), and enabling early media on the linphone app, I get a video and audio preview before answering the call.
But, the doorbell seems to hangup after ~32 seconds into the call, which is much shorter than the “Max Call Duration” I have in the doorbells settings.
Doorbell Button to call multiple phones
Works as expected. No early media when calling multiple extensions at once.
The doorbell seems to hangup after ~32 seconds like the above scenario.
Videocall Doorbell from phone
Doorbell automatically answers and I get 2-way audio, but no video from the doorbell.
I just learned the basics of asterisk this week lol, going to try to also setup a FS system just to see if I get the same issues. I cannot attach the logs since I am a new user, but I’ll see if there is another way I can share them. Thanks for the help!
Which channel driver are you using (should be chan_pjsip)?
Assuming that, what appears in the logs when you enable “pjsip set logger on”, from the CLI.
A 32 second timeout will generally produce a log message, even without the above protocol logging enabled. What is that message?
32 second timeouts happen when a SIP response, or a SIP ACK is not received, and are usually the result of NAT or firewall misconfiguration, particularly in routers.
For the final scenario, are you sure that the doorbell is actually answering, and not just handling the call as early media?
I just setup Asterisk 20 and used PJSIP. I was actually going to try chan_sip just to see if that made a difference but haven’t done that yet.
I still cannot attach logs, but have linked to them. Let me know if this does not include what you need from “pjsip set logger on” and I can try that as well.
I don’t think NAT should be a problem. At the moment Asterisk, doorbell, and phone are all on the same internal subnet. Though in the future I will have things configured differently.
No I am not sure what is going on. It acutally seems like video is on, but the result is a black screen only. Log is linked.
You’ve provided the debug log. These are too noisy to use. You should provide the full log, with debug level 0, but with verbose enabled, verbosity at least 5, and with the set logger on command in effect.
If you can’t find the string “INVITE SIP” in the log, it is not going to be any use to me.
Ok I ‘enabled verbose = 5’ in asterisk.conf, set ‘pjsip set logger on’, and uploaded full.log instead of debug.log. Let me know if these logs are any more helpful, or if I am still missing something. Thanks!
On the first one, Asterisk is issuing a re-INVITE to the …92 device for an answered call that isn’t the current incoming call (which is unanswered). The …92 should, at the very least, respond that the session doesn’t exist. I think you will have to find out what went wrong with the previous answered session.
For the second one, I think you will need to enable RTP debugging, but the doorbell is answering with a=sendonly, so there should only be one way video, from the doorbell. You need to see whether that video is arriving at Asterisk.
The 92 IP is the doorbell. I’ll read the logs and try to understand things, might take me a while, lol.
I will also repost the no_video situation with RTP debuging enabled.
Finally, here is a response from Grandstream for a somewhat similar situation. Hikvision Doorbell + Indoor Station > UCM, dropping the call after 14 seconds. Not sure if it is relevant to my issues though.
The issue is not related to our UCM. When you make a call using our UCM, you can see a video preview when the call is received, but with FreePBX, you can’t because FreePBX sends a 180 Ringing response.
Our UCM sends a 183 Ringing, which allows the receiving device to show a video preview. However, when this happens, the device that initiated the call ends it because it doesn’t receive RTP. But it doesn’t receive RTP because the receiving device sends the RecvOnly parameter and doesn’t transmit audio.
In summary, the UCM isn’t doing anything wrong — it’s the device initiating the call that ends it when 183 Ringing is used.
which seems to be missing both responses and BYEs.
There is, actually a response to the BYE for the first call ID, which indicates that the router is passing traffic correctly, I’d therefore have to assume that the YATE/5.5.0 device has a broken implementation of SIP re-INVITEs. If you can’t handle them, you should reject them, not ignore them.
I think the re-INVITE is for session timers, so you be able to work round the broken device by disabling them.
I guess the second call ID is left over from a previous call that got stuck on re-INVITEs, but I don’t understand why there is no BYE for that.
Thanks for the feedback. I don’t have time at the moment to understand what your have provided but will try to soon.
For now, I’m wondering why you say different Call-ID’s? The numbers you posted (700378988) are identical, but maybe what you are referring to is in the log. I’ll try to read that deeper this weekend.
As for the no video situation, attached is a log with RTP debug logging. Thank you again for your help! no_video_rtp_debug.txt (76.2 KB)
I set timers=no for the doorbell, but still get the cutoff at 32 seconds. Is this what you suggested to disable re-INVITEs, or is there another setting I should be changing?
It looks like it is trying to set the video stream to one way, because the LinPhone has told it that it cannot send video. I wasn’t aware that it would do that. You could try disabling direct media, but, if that works, it would be a side effect of direct media, as it isn’t actually setting up direct media, and I don’t think it can do so for video, so unless such updates are disabled, as a side effect of disabling direct video, that might not work.
As I’ve already said, the doorphone is broken, if it doesn’t respond to re-INVITEs; it should, at the very least, explicitly reject them.
I have direct_media=no for the doorbell and my user. Didn’t make a difference either way.
This doorbell model originally only worked with a Hikvision “Indoor Station”, which is an Android Tablet with its own priority PBX. You can then register that Indoor Station to a standard SIP provider.
A few years ago, Hikvision made a software update to allow these doorbells to call their proprietary app without needing to own an Indoor Stations. And then they added SIP functionality, but it seems like the SIP implementation is not well tested and buggy, since most people use it with an Indoor Station.
Anyway thank you for the help thus far. I will read over your posts, and see if I can make sense of the logs. Will also try FreeSwitch and see if I hit the same issues.
I read the log_timersoff file, and tried to follow along with the diagram I linked earlier and was able to make some sense of it, lol.
I was actually able to get video call from the Doorbell to work for more than 32 seconds! But it seems to be very inconsistent. Calls only go longer if I am lucky. Is seems like adding Ringing(), Answer(), and removing Hangup() helps me get calls past 32 seconds. And using the ‘Dialer’ on Linphone, can guarantee the call will will drop at 32 seconds.
Was your theory, that my Doorbell is not responding to reINVITEs properly, so Asterisk sends BYE at 32 seconds? If so, I am not surprised the doorbell is not fully SIP compliant. It was designed to be used with their proprietary tablet, and only through a firmware update got standalone SIP settings. I think my best strategy is to have Asterisk not send reINVITEs, or not drop the call even if they are not handled correctly.
Also, I found a similar thread you responded on in 2021, also related to Hikvision Doorbells!
I guess what I am wondering… In my particular situation, is Asterisk dropping the call or the Doorbell at 32 seconds? If Asterisk is the one hanging up, can I just tell it to ignore the doorbell’s buggy behavior?