And apparently, yes, it seems so -->
Any IP-based doorbell working only in LAN without requiring "cloud" services?
- Thread starter Mauro70
- Start date
user8963
Known around here
maybe maybe not.
group ringing has nothing to do with early media.
just ask them via mail
Sometimes they only support these features when using their OWN hardware/app, but lack the function if using 3rd party app
but as you pointed out, such lack of capability is on SIP server side. From the documents I found, the SIP server embedded into the indoor station seems to support group ringing with the early video delivery. So, actually, if you use a third-party SIP server which the FANVIL (or dahua/hikvision) connects to, it must have such capability.
user8963
Known around here
Unsupported - Early Video Preview in Ring Group
I have a system using a Fanvil i10v video door station as well as some Fanvil i53w video screens that are connected through 3cx. The system works perfectly when video preview is turned off on the i53ws. When you press the doorbell button on the i10v, both i53ws ring through the ring group and...
www.3cx.com
well, basically that thread is saying that the group video preview capability mentioned into release notes of firmware 2.8.13 is basically not working as one might expect... that's a pity...
user8963
Known around here
i have no idea if you understand what the problem is??
It works fine if you are using dahua/hikvision hardware AND their app. why should it not work ?
the problem ... dahua/hikvision apps are unreliable. sometimes you get a notification, sometimes not. also everything goes through their cloud (which is free to use, but they will save all your data).
everything have to be connected to the internet directly.
if you dont want that all, you need an own sip server. but if you use your own sip server, you cannot use early media on your devices, if you have more than 1 i.e. ringgroup.
own sip server gives you freedom, privacy and working notifications, but you will lose some features, which you have if you use their cloud/sip server.
also if you want to connect third party hardware like sip phones, you are unable to connect them if using hik/dahua protocol.
if you dont need any remote calls on your phone, then you dont need internet at all...
they work 100% on your local network with their displays and early media
Last edited:
Well, dauha/hikvision firmware unreliable? fine, it can be, but it was not one of the points I was mainly concerned about. By the way all these devices come from China and have the same kind of bugs, unreliability etc etc. it is a matter to see which vendor is more inclined to release new versions of their firmware. Dauha and Hik normally are good players in such market.
They use the cloud: well, looking at the video there, it does not seem to me that the cloud is mentioned at all. It seems that it is sufficient to setup each device with its own IP address in the same LAN, and that's all. As I said in my first message, I need something not requiring cloud. This configuraiton seems like that. But even in the remote situation that they still keep sending data in the cloud despite the p2p connection in the same lan, I have to simply block them in the firewall.
Then at least for me, I do not need a my own SIP server, their embedded one is sufficient for my needs.
Last but not least: I perfectly understand all concerns and thank you for raising any red flag, I was simply sharing with you (and whoelse might be interested) what I found digging on internet, seen that you said "good question, never tested".
They use the cloud: well, looking at the video there, it does not seem to me that the cloud is mentioned at all. It seems that it is sufficient to setup each device with its own IP address in the same LAN, and that's all. As I said in my first message, I need something not requiring cloud. This configuraiton seems like that. But even in the remote situation that they still keep sending data in the cloud despite the p2p connection in the same lan, I have to simply block them in the firewall.
Then at least for me, I do not need a my own SIP server, their embedded one is sufficient for my needs.
Last but not least: I perfectly understand all concerns and thank you for raising any red flag, I was simply sharing with you (and whoelse might be interested) what I found digging on internet, seen that you said "good question, never tested".
user8963
Known around here
again: no ! !
The systems are working 100% with their indoor stations, you will not miss a call on their indoor station.
you dont need internet when having a closed system. you not even have to put them into your network. you can just connect them together with a single cat5 cable, power them with 12v and they will work 100%.
or you use a dumb poe switch.
the only thing what is unreliable is the forward to your phone.
doorbells are not compatible with indoor stations, only the intercom systems.
so a doorbell relies on app and maybe chime.
if you want to use their app on your phone, you have to use their cloud servers (which are located on amazon datacenter/cloud) to get push notifications. they made some updates a month ago ... before that it was possible to get notifications local (but need connection to google/apple push server).
also if you want to use your existing SIP hardware (phone, pc, whatever) it might not work like their indoor station.
Last edited:
And with some of these cloud based doorbells, if you deny it internet access in the router, then it won't work as the "SIP server" isn't embedded in the device, but rather is only accessible from their cloud service...it is how they hook you...
I was hoping to attach my phone to the embedded SIP server by means of a SIP client mobile app running on the phone... who never knows, maybe it is somehow compatible... to be still investigated actually.
user8963
Known around here
this will never work without internet.
any smartphone needs internet to receive a push notification and any device needs internet to contact the push server.
you are mixing too many things up or you are talking about something else
an old fashion house telephone with sip compatibility or connected to a gateway will work local .. it is working different than a sip softphone on smartphone !
Last edited:
user8963, my requirement is having video doorbell capabilities working on all those different devices (smartphone, new generation video doorbells, indoor stations etc etc) by means of "some interconnection" which does not require cloud services in china or whatever else country.
Further, it was implicit in my mind that group-ringing and group-video preview had to work in this "some interconnection", otherwise it does not make sense to have a video door bell. Maybe I had to clarify better my requirements since the beginning.
That's why this post. These are my requirements on the table. Got all your experiences, looked at the docs and videos around internet.
In the end, it seemed to me that this "some interconnection" could be achieved by means of a "SIP server" (embedded or external). And then the discussion continued from there.
My expectation was "being SIP a standard, I expect that who claims to be SIP compatible works either if it is a mobile app or if it is an old-fashion phone or if it is a new-generation video door bell".
Looking what you said, clearly it is a false expectation, and I thank you for opening my eyes. So I have simply to redefine (and maybe lower) my requirements.
So please, don't say that I'm mixing things or else. What I'm trying to achieve is basically putting together several devices, nothing different from who is trying (or tried) to interconnect via 3CX, asterisks and so on. Is it impossible? ok, I can give up.
Thanks
riogrande75
Pulling my weight
Don't want to drag this thread out, but there is a (very) technical aspect that I want to state because it fits here.
@user8963
I did some more testing on what you said.
My VTO2000A running latest FW from this years july, is capable of handling 4 rtsp streams in parallel.
This makes possible to use at least 4 devices (who has more indoor stn. for a single door?) that show the visitors video BEFORE the call gets answered when running on asterisk/any sip server. The destination devices establishes a RTSP connection as soon as a call (INVITE) from the preconfigured VTO number gets received - dahua's VTH displays as well. So as already mentioned from my side, this has nothing to do with SIP nor the used 3rd pty server, it's a "end device to VTO" thing.
So I was curious how dahuas built in SIP server handles this.
Hooking up a VTH1660 on my VTO's internal SIP server with group call enabled and starting wireshark revealed the secret: It's a multicast/IGMP group!
The VTO creates a IGMP group, VTH joins this multicast group.
When a call get's set up, the INVITE to the VTH includes a proprietary sip header element called "Group-Call" with the multicast stream's address.
The VTH then simply picks up this stream. Off course, this can be done by any device in the same network and do not put any more load on the VTO.
As the IGMP group is set up by the VTO even when hooked up on a 3rd pty server (saw that in my traces), you can manually add the header to let the VTO pick up the multicast stream.
With asterisk pjsip this looks like that:
So dahua's and any other device is able to make use of this multicast group and does not need rtsp.
Dunno if linphone or other sip softclients have IGMP functions built in, but would be at least desirable.
@user8963
I did some more testing on what you said.
My VTO2000A running latest FW from this years july, is capable of handling 4 rtsp streams in parallel.
This makes possible to use at least 4 devices (who has more indoor stn. for a single door?) that show the visitors video BEFORE the call gets answered when running on asterisk/any sip server. The destination devices establishes a RTSP connection as soon as a call (INVITE) from the preconfigured VTO number gets received - dahua's VTH displays as well. So as already mentioned from my side, this has nothing to do with SIP nor the used 3rd pty server, it's a "end device to VTO" thing.
So I was curious how dahuas built in SIP server handles this.
Hooking up a VTH1660 on my VTO's internal SIP server with group call enabled and starting wireshark revealed the secret: It's a multicast/IGMP group!
The VTO creates a IGMP group, VTH joins this multicast group.
When a call get's set up, the INVITE to the VTH includes a proprietary sip header element called "Group-Call" with the multicast stream's address.
The VTH then simply picks up this stream. Off course, this can be done by any device in the same network and do not put any more load on the VTO.
As the IGMP group is set up by the VTO even when hooked up on a 3rd pty server (saw that in my traces), you can manually add the header to let the VTO pick up the multicast stream.
With asterisk pjsip this looks like that:
Code:
same => n,Set(PJSIP_HEADER(add,Group-Call)=224.0.2.14\;30001\;30000);So dahua's and any other device is able to make use of this multicast group and does not need rtsp.
Dunno if linphone or other sip softclients have IGMP functions built in, but would be at least desirable.
Last edited:
user8963
Known around here
Thanks for that, i will look tomorrow into it.
In theory linphone is able to use earlymedia multicast and multicast video.
Maybe its related to this "modded" implementation by dahua.
I look at my dahua log, but cannot find anything like this .
maybe only available if connectiong display(s)?
are u connecting the dahua intercom and displays as clients to the asterisk server? do the intercom send out the "modded" header through the server by default or did you made changes to the dialplan?
Hi all, back again to share my experience to whom might be interested: 2 VTOs, 2 VTHs and my mobile.
The main VTO configured also a SIP server.
On the mobile phone, I have installed SIP clients (linphone, mizudroid), successfully connected to the VTO SIP server.
Tested the group call with early preview: it works in all VTHs. The mobile phone is also included into the group call and rings (and can answer), but without early preview.
But then the new obstacle: the network where VTOs and VTHs are connected is separated by the home network (for security reasons of course), and connected to the home network with a dedicated SOHO router/firewall with very limited allowed traffic (especially not towards internet).
Multicast traffic (which is the one initiated in a group call) does not traverse the router.
So, when at home, either I keep the mobile connected to the "DAHUA" network and try to achieve the full integration (but in that case my mobile would remain isolated like VTOs and VTHs), or I keep it attached to the home network and it does not receive the SIP multicast traffic.
A decision which I have not taken yet
.
Cheers
The main VTO configured also a SIP server.
On the mobile phone, I have installed SIP clients (linphone, mizudroid), successfully connected to the VTO SIP server.
Tested the group call with early preview: it works in all VTHs. The mobile phone is also included into the group call and rings (and can answer), but without early preview.
But then the new obstacle: the network where VTOs and VTHs are connected is separated by the home network (for security reasons of course), and connected to the home network with a dedicated SOHO router/firewall with very limited allowed traffic (especially not towards internet).
Multicast traffic (which is the one initiated in a group call) does not traverse the router.
So, when at home, either I keep the mobile connected to the "DAHUA" network and try to achieve the full integration (but in that case my mobile would remain isolated like VTOs and VTHs), or I keep it attached to the home network and it does not receive the SIP multicast traffic.
A decision which I have not taken yet
.Cheers
