Any IP-based doorbell working only in LAN without requiring "cloud" services?

[Mauro70]

Hi All
I would like to mount an IP-based doorbell at home, however I have a constraint: the doorbell shall communicate with the indoor station (preferebly to my smartphone, alternatively to a dedicated display) only via internal LAN, so not requiring any access to internet.
The reason of this is very simple: on top of the security concerns, the real truth is that I live in a place with poor telco infrastructures, and do not have a stable ADSL connection (quite difficult to believe in 2021, but it is so).
So I would avoid that somebody rings at my doorbell and I do not receive the alarm in my smartphone simply because internet/ADSL is down at that moment.
Any suggestion?
Many thanks in advance.
Cheers
Mauro

 

[riogrande75]

Have a look at the dahua VDP devices. They work without internet as well.

 

[pete_c]

Welcome to the forum @Mauro70

Here utilize a generic LTE (to T-Mobile) cellular combo modem / router / firewall / wireless AP as my back up to the internet in case the main internet doesn't function.

I am suggesting an alternative transport to your ADSL internet transport.

You can purchase an older used 3G style modem today for less than $50 USD. For years here (by Chicago) used the Ericsson W25 combo modem with a battery.

My network connected Hikvision Doorbell talks to the house network and if I am at home I can see this with the at home connected smart phone.

Via automation software if someone rings the doorbell I get a text or email message on my phone.

I use an OpenVPN client on my phone, tablet, laptop to get to my home CCTV. Works great. I am not using any cloud based connectivity for my doorbell today.

 

[Mauro70]

Have a look at the dahua VDP devices. They work without internet as well.

Gesendet von meinem SM-T875 mit Tapatalk

Thanks, I'll have a look at these.

Welcome to the forum @Mauro70

Here utilize a generic LTE (to T-Mobile) cellular combo modem / router / firewall / wireless AP as my back up to the internet in case the main internet doesn't function.

I am suggesting an alternative transport to your ADSL internet transport.

You can purchase an older used 3G style modem today for less than $50 USD. For years here (by Chicago) used the Ericsson W25 combo modem with a battery.

My network connected Hikvision Doorbell talks to the house network and if I am at home I can see this with the at home connected smart phone.

Via automation software if someone rings the doorbell I get a text or email message on my phone.

I use an OpenVPN client on my phone, tablet, laptop to get to my home CCTV. Works great. I am not using any cloud based connectivity for my doorbell today.

Thanks Pete. Actually it is not a matter of having a backup "connection". The ADSL goes up and down intermittently, sometimes for few seconds, other times for minutes, other times for hours. So, it is practical difficult to manually switch the connection from ADSL to the LTE modem/router.
I should put in place something a bit more "intelligent", a sort of automatic failover from one line to the other. To be honest, I'm thinking to some alternatives (for example, totally replacing the ADLS with a LTE-based one, or via satellite) but there are other things to take into account and evaluate, so for the time being I do not want to waste time in this activity, I can live without streaming for now, but I would instead solve the doorbell issue.

Which hikvision model are you referring to?
Thanks

 

[pete_c]

Yes an intermittent connection to your doorbell would be sufficient to send out a text or email to your cell phone via automation software like Homeseer or Home Assistant.

Which hikvision model are you referring to?

I purchased the Nelly DB over a year ago and then upgraded it to Hikvision firmware (as posted in my signature).

It works fine wirelessly connected to my Ruckus WAP, Leviton OmniPro 2 alarm panel, Zoneminder and Blue Iris and Homeseer and Home Assistant.

For a bit a few years ago helped a start up company in Italy (Fing - IoT). They moved their HQ to London and built their product in Taiwan. Not sure what Internet transport they used in Italy. For a time a long time ago worked on the new MSP (Milan) airport when it was rebuilt across the runway from the old MSP airport and well vacationed there a few times.

 

[Mauro70]

Yes an intermittent connection to your doorbell would be sufficient to send out a text or email to your cell phone via automation software like Homeseer or Home Assistant.

Totally right, my bad, I had to be more specific: I'm trying to setup an ip-based video doorbell, so I would like to see who is at the door, not only having a text message.

cheers

 

[riogrande75]

I have a dahua VTO at my front door. As soon as someone rings the bell, I get a signal message with the visitor's pic. I also get a snapshot and even name of the user if the door was opened with the fingerprint. This is all non cloud based and runs 100% on my home server.

You could also run the whole thing via SIP. Your VTO@your local asterisk calls a public SIP number where your smartphone's sip client is logged into. This works for dahua VTO's as they are all SIP based. Off course, video and audio. It was pretty complex but I got it working once. Anyhow I'm more happy with the solution mentioned above.

 

[Mauro70]

I have a dahua VTO at my front door. As soon as someone rings the bell, I get a signal message with the visitor's pic. I also get a snapshot and even name of the user if the door was opened with the fingerprint. This is all non cloud based and runs 100% on my home server.

You could also run the whole thing via SIP. Your VTO@your local asterisk calls a public SIP number where your smartphone's sip client is logged into. This works for dahua VTO's as they are all SIP based. Off course, video and audio. It was pretty complex but I got it working once. Anyhow I'm more happy with the solution mentioned above.

Yes, I was looking at the dauha features... Indeed I was thinking to setup a simple SIP server on a raspberry then to take benefit of such capabilities... ok, some homeworks for the christmas holidays
thanks

 

[user8963]

You could also run the whole thing via SIP. Your VTO@your local asterisk calls a public SIP number where your smartphone's sip client is logged into. This works for dahua VTO's as they are all SIP based. Off course, video and audio. It was pretty complex but I got it working once. Anyhow I'm more happy with the solution mentioned above.

were you able to get ring groups working ? which means show early media video on any called device (indoor monitors, smartphone etc.) at the same time ?

 

[riogrande75]

If you run a RPi anyway, have a look at this script: DahuaEventHandler

 

[user8963]

If you run a RPi anyway, have a look at this script: DahuaEventHandler

yes but this has nothing to do with SIP right ?

all these things have no video/audio.
if using own sip server with dahua/hik devices you lose many functions which works with their own sip implementation. to my knowledge there is no solution for ring groups with early media.

but someone started an integration of asterisk into home assistant. finally. maybe some things could work better.

 

[riogrande75]

You mean, you want the video of the visitor in ringing state on the devices?

Dahua's own indoor stations (VTH) can do that also with asterisk as their sip server. Off course "ring groups" can be easily configured with asterisk (that's what I do at home as well).

Even showing the video on a tv set is pretty easy (rtsp stream as a tv channel) and switch tv station as soon as someone rings the bell (script).

Some SIP devices support "showing a preconfigured rtsp stream on call of a specific number", just like my unfiy CP600. I described it here (german only).

I did not find a device/client that supports SIP early media for video 100% according to rfc3960. Even dahua's own devices do the rtsp trick instead.

 

[user8963]

I did not find a device/client that supports SIP early media for video 100% according to rfc3960. Even dahua's own devices do the rtsp trick instead.

according to my logs, any dahua and hikvision intercom device is using SIP early media, no "rtsp trick".
early media works fine with fusionpbx and linhome or other sip clients for mobile phones...

but it seems impossible to have ring groups with early media, which means show all called devices the early media...
if you use their sip server it works. but with own sip server its impossible, because there is no sip server which support ringgroups and early media. not sure if someone can modify it, some claim it was possible with 3cx, but 3cx does not support hik devices because they use a blacklisted sip client exosip.

Unsupported - Allow: User-Agent: eXosip/3.6.0

Hi, we are using Hikvision intercoms, we can use the indoor panels as sip clients, but they use exosip as agent... Seems User-Agent: eXosip/3.6.0, are being blocked by 3CX... Is it possible to override the config so we can connect our intercoms? Thnx , appreciated

www.3cx.com

3cx support dont want exosip on their systems, they say its unsecure. its blocked hardcoded, so no whitelist possible.

Group video calling in asterisk

Hi all, I have been struggling with asterisk from last few weeks. There are certain features which are supported in 3CX but looks like asterisk is not supporting it. Previously I was trying to get the video from the monitor before answering the call (3cx support this feature by default), I...

community.asterisk.org

i have no idea what dahua and hikvision did, but it seems that they got it to work. you can connect 5 displays to it and have early media on all devices.
rtsp has too much delay, sip video is better.

 

[Mauro70]

so, let me try to summarize your inputs:

(-) dahua VTOs can act as SIP servers as well

(-) by using dahua devices only (outdoor and indoor stations) and the SIP server embedded into dahua VTOs, ring-groups with early-media on all dahua client devices works. It works also on non-dahua clients (i.e. smartphone with the fusionpbx and linhome or other sip clients).

(-) apparently, ring-groups with early-media on all client devices does not work when using an own SIP server (with all the due exceptions about somebody who was able to manage it to work on asterisk)

is my understading of your inputs correct?

 

[riogrande75]

@user8963
I did a lot of investigation on this some time ago but didn't use dahua's own builtin sip server because of the lack of opportunities.
I remeber that on asterisk VTH's connected VTO's RTSP stream after the SIP/INVITE and after 200/OK it switched over to SIP video from SDP.
Would be very interresting if you still have a pcap trace of a working SIP early media with dahua devices you mentioned.
Off course I'm even more curious on a trace with early media and linphone.

 

[user8963]

me and @NoFate were unable to get it to work.
early media just means that you see the video on your device (phone, display...) without accepting the call.
it does work if you have only ONE called device (display or phone)

if you have more than one device (two phones, one display and phone... ) you dont see any video feed ONLY after you accept the call.
this is NOT related to the connected devices. its on the sip-server side... they only can send media 1:1 , no one knows how 3cx got it to work, but some claim it works with 3cx. sadly 3cx blocks old devices and all hikvision/dahua intercoms uses old sip-client sources.

Off course I'm even more curious on a trace with early media and linphone.

all intercom device send everything what is needed in the header. see asterisk log below.
you can search for "h264"


have to search a bit got a sad data loss last week,

you have to add

[from-internal-custom]
exten => 2002,1,Progress()
same => n,Dial(SIP/2002)
same => n,Hangup

something like this to the dialplan of asterisk to get early media to work. but again, no ringgroups.. fusionpbx is maybe a better choice, there are many settings how early media is handled by the server




but here are some snippets
linhome:

Spoiler: Linhome LOG

Via: SIP/2.0/UDP 10.0.1.3:5065;rport;branch=z9hG4bK526958865
From: "OUTDOOR STATION" <sip:10010100000@10.0.1.3>;tag=3500379343
To: <sip:10010110001@10.0.1.4:49722>;tag=PBEzh7A
Call-ID: 369027232@10.0.1.3
CSeq: 40 INVITE
User-Agent: Linhome/5.0.0 (ELE-L29) LinphoneSDK/4.5.0 (tags/4.5.0^0)
Supported: replaces, outbound, gruu
Content-Type: application/sdp
Content-Length: 239


v=0
o=10010110001 228 1798 IN IP4 10.0.1.4
s=Talk
c=IN IP4 10.0.1.4
t=0 0
m=audio 50477 RTP/AVP 0
a=rtcp:36716
m=video 41089 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801F; packetization-mode=1
a=rtcp:36145


2021-09-16 23:18:32:361 [org.linhome/belle-sip] MESSAGE Dialog [0x720957aa00]: now updated by transaction [0x722db73640].
2021-09-16 23:18:32:361 [org.linhome/liblinphone] MESSAGE CallSession [0x720955a438] moving from state LinphoneCallIncomingReceived to LinphoneCallIncomingEarlyMedia
2021-09-16 23:18:32:361 [org.linhome/linphone-android] MESSAGE [Notifications Manager] Call state changed [IncomingEarlyMedia]
2021-09-16 23:18:32:368 [org.linhome/linphone-android] WARNING [Platform Helper] Found an existing video TextureView, let's destroy it first
2021-09-16 23:18:32:368 [org.linhome/mediastreamer] MESSAGE [Context] Call state changed [IncomingEarlyMedia]
2021-09-16 23:18:32:369 [org.linhome/liblinphone] MESSAGE Linphone core [0x722da1f400] notified [call_state_changed]
2021-09-16 23:18:32:369 [org.linhome/liblinphone] MESSAGE StreamsGroup 0x720957ab00 rendering stream#0 [audio] in state [Stopped]
2021-09-16 23:18:32:369 [org.linhome/liblinphone] MESSAGE Audio bandwidth for StreamsGroup [0x720957ab00] is 80
2021-09-16 23:18:32:369 [org.linhome/liblinphone] MESSAGE Equalizer location: hp

here are some parts of asterisk

Spoiler: Asterisk Log

Via: SIP/2.0/UDP 10.0.1.8:5060;rport;branch=z9hG4bK1587609963
From: "102" <sip:102@10.0.1.8>;tag=1868506277
To: <sip:101@10.0.1.24:5060>
Call-ID: 284249919@10.0.1.8
User-Agent: YATE/5.5.0
Contact: <sip:102@10.0.1.8:5060>
Allow: ACK, INVITE, BYE, CANCEL, MESSAGE, OPTIONS, INFO
CSeq: 20 INVITE
Authorization: Digest username="102", realm="asterisk", nonce="1630060591/c5f76b0113e45c08864ef351f93eca1b", uri="sip:101@10.0.1.24:5060", response="01213f3ef1beca0382092cb7b85e7830", algorithm=MD5, opaque="2592fffd3012db1d", qop=auth, nc=0000000a, cnonce="c33e2884640b9a6c96e99d127bf6bc0b"
Content-Type: application/sdp
Content-Length: 280

v=0
o=yate 1630064195 1630064195 IN IP4 10.0.1.8
s=SIP Call
c=IN IP4 10.0.1.8
t=0 0
m=audio 9654 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
m=video 9856 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4D001F; packetization-mode=1

[2021-08-27 12:36:31] DEBUG[2278] res_pjsip/pjsip_distributor.c: Could not find matching transaction for Request msg INVITE/cseq=20 (rdata0x7f309c000f88)
[2021-08-27 12:36:31] DEBUG[2278] res_pjsip/pjsip_distributor.c: Calculated serializer pjsip/distributor-00000039 to use for Request msg INVITE/cseq=20 (rdata0x7f309c000f88)
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.8' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.8' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_endpoint_identifier_ip.c: No identify sections to match against
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_endpoint_identifier_user.c: Attempting identify by From username '102' domain '10.0.1.8'
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_endpoint_identifier_user.c: Identified by From username '102' domain '10.0.1.8'
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_authenticator_digest.c: Using default realm 'asterisk' on incoming auth '102-auth'.
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_authenticator_digest.c: Calculated nonce 1630060591/c5f76b0113e45c08864ef351f93eca1b. Actual nonce is 1630060591/c5f76b0113e45c08864ef351f93eca1b
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.24' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.24' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.8' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.8' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip/pjsip_distributor.c: Calculated serializer pjsip/distributor-00000039 to use for Request msg INVITE/cseq=20 (rdata0x7f309c030d68)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102
[2021-08-27 12:36:31] VERBOSE[2279] pbx_variables.c: Setting global variable 'SIPDOMAIN' to '10.0.1.24'
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Call (UDP:10.0.1.8:5060) to extension '101' sending 100 Trying
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Method is INVITE, Response is 100 Trying
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.8' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.8' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_nat.c: Request is being sent to local address, skipping NAT manipulation
[2021-08-27 12:36:31] VERBOSE[2279] res_pjsip_logger.c: <--- Transmitting SIP response (276 bytes) to UDP:10.0.1.8:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.1.8:5060;rport=5060;received=10.0.1.8;branch=z9hG4bK1587609963
Call-ID: 284249919@10.0.1.8
From: "102" <sip:102@10.0.1.8>;tag=1868506277
To: <sip:101@10.0.1.24>
CSeq: 20 INVITE
Server: Asterisk PBX 16.15.1
Content-Length:  0


[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: Function session_inv_on_state_changed called on event TSX_STATE
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The state change pertains to the endpoint '102()'
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The inv session still has an invite_tsx (0x7f30a00859a8)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: There is no transaction involved in this state change
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The current inv state is INCOMING
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: 102: Source of transaction state change is TX_MSG
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: Function session_inv_on_tsx_state_changed called on event TSX_STATE
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The state change pertains to the endpoint '102()'
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The inv session still has an invite_tsx (0x7f30a00859a8)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The UAS INVITE transaction involved in this state change is 0x7f30a00859a8
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The current transaction state is Proceeding
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The transaction state change event is TX_MSG
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c: The current inv state is INCOMING
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Media count: 2
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing stream 0
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Using audio-0 for new stream name
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Using new stream 0:audio-0:audio:sendrecv (nothing)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102 Adding position 0
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Creating new media session
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Setting media session as default for audio
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Done
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Negotiating incoming SDP media stream 0:audio-0:audio:sendrecv (nothing) using audio SDP handler
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.8' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.8' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Using engine 'asterisk' for RTP instance '0x7f30a005c340'
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) RTP allocated port 18916
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) ICE creating session [::]:18916 (18916)
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) ICE create
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) ICE add system candidates
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.24' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.24' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) ICE add candidate: 10.0.1.24:18916, 2130706431
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting 'fe80::20d:b9ff:fe40:2194' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host 'fe80::20d:b9ff:fe40:2194' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) ICE add candidate: [fe80::20d:b9ff:fe40:2194]:18916, 2130706431
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: RTP instance '0x7f30a005c340' is setup and ready to go
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) ICE stopped
[2021-08-27 12:36:31] VERBOSE[2279] netsock2.c: Using SIP RTP Audio TOS bits 184
[2021-08-27 12:36:31] VERBOSE[2279] netsock2.c: Using SIP RTP Audio TOS bits 184 in TCLASS field.
[2021-08-27 12:36:31] VERBOSE[2279] netsock2.c: Using SIP RTP Audio CoS mark 5
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting 'pbx.tm.local' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host 'pbx.tm.local' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] acl.c: Multiple addresses. Using the first only
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) RTCP setup on RTP instance
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Setting tx payload type 0 based on m type on 0x7f3061ed2f10
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Crossover copying tx to rx payload mapping 0 (0x7f30a004d698) from 0x7f3061ed2f10 to 0x7f3061ed2f10
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Crossover copying tx to rx payload mapping 101 (0x7f30a005b248) from 0x7f3061ed2f10 to 0x7f3061ed2f10
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Copying rx payload mapping 0 (0x7f30a004d698) from 0x7f3061ed2f10 to 0x7f30a005c518
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Copying rx payload mapping 101 (0x7f30a005b248) from 0x7f3061ed2f10 to 0x7f30a005c518
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Copying tx payload mapping 0 (0x7f30a004d698) from 0x7f3061ed2f10 to 0x7f30a005c518
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Copying tx payload mapping 101 (0x7f30a005b248) from 0x7f3061ed2f10 to 0x7f30a005c518
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Media stream 0:audio-0:audio:sendrecv (ulaw) handled by audio
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Done with stream 0:audio-0:audio:sendrecv (ulaw)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing stream 1
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Using video-1 for new stream name
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Using new stream 1:video-1:video:sendrecv (nothing)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102 Adding position 1
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Creating new media session
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Setting media session as default for video
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Done
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Negotiating incoming SDP media stream 1:video-1:video:sendrecv (nothing) using video SDP handler
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.8' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.8' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Using engine 'asterisk' for RTP instance '0x7f30a0085200'
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) RTP allocated port 11798
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) ICE creating session [::]:11798 (11798)
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) ICE create
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) ICE add system candidates
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting '10.0.1.24' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host '10.0.1.24' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) ICE add candidate: 10.0.1.24:11798, 2130706431
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting 'fe80::20d:b9ff:fe40:2194' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host 'fe80::20d:b9ff:fe40:2194' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) ICE add candidate: [fe80::20d:b9ff:fe40:2194]:11798, 2130706431
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: RTP instance '0x7f30a0085200' is setup and ready to go
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) ICE stopped
[2021-08-27 12:36:31] VERBOSE[2279] netsock2.c: Using SIP RTP Video TOS bits 136
[2021-08-27 12:36:31] VERBOSE[2279] netsock2.c: Using SIP RTP Video TOS bits 136 in TCLASS field.
[2021-08-27 12:36:31] VERBOSE[2279] netsock2.c: Using SIP RTP Video CoS mark 4
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: Splitting 'pbx.tm.local' into...
[2021-08-27 12:36:31] DEBUG[2279] netsock2.c: ...host 'pbx.tm.local' and port ''.
[2021-08-27 12:36:31] DEBUG[2279] acl.c: Multiple addresses. Using the first only
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) RTCP setup on RTP instance
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Crossover copying tx to rx payload mapping 96 (0x7f30a007df68) from 0x7f3061ed2e30 to 0x7f3061ed2e30
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Copying rx payload mapping 96 (0x7f30a007df68) from 0x7f3061ed2e30 to 0x7f30a00853d8
[2021-08-27 12:36:31] DEBUG[2279] rtp_engine.c: Copying tx payload mapping 96 (0x7f30a007df68) from 0x7f3061ed2e30 to 0x7f30a00853d8
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Media stream 1:video-1:video:sendrecv (h264) handled by video
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Done with stream 1:video-1:video:sendrecv (h264)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Handled? yes
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing streams
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing stream 0:audio-0:audio:sendrecv (ulaw)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102 Adding position 0
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Using existing media_session
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a005c340) RTCP ignoring duplicate property
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Stream 0:audio-0:audio:sendrecv (ulaw) added
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Done with 0:audio-0:audio:sendrecv (ulaw)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing stream 1:video-1:video:sendrecv (h264)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102 Adding position 1
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  Using existing media_session
[2021-08-27 12:36:31] DEBUG[2279] res_rtp_asterisk.c: (0x7f30a0085200) RTCP ignoring duplicate property
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Stream 1:video-1:video:sendrecv (h264) added
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Done with 1:video-1:video:sendrecv (h264)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Adding bundle groups (if available)
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Copying connection details
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing media 0
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Media 0 reset
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Processing media 1
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Media 1 has good existing connection info
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  102: Method is INVITE
[2021-08-27 12:36:31] DEBUG[2279] chan_pjsip.c:  102
[2021-08-27 12:36:31] DEBUG[2279] stasis.c: Creating topic. name: channel:1630060591.15, detail:
[2021-08-27 12:36:31] DEBUG[2279] stasis.c: Topic 'channel:1630060591.15': 0x7f30a00809c0 created
[2021-08-27 12:36:31] DEBUG[2279] stasis.c: Creating topic. name: cache:27/channel:1630060591.15, detail:
[2021-08-27 12:36:31] DEBUG[2279] stasis.c: Topic 'cache:27/channel:1630060591.15': 0x7f30a005a090 created
[2021-08-27 12:36:31] DEBUG[2279] channel.c: Channel 0x7f30a0057ea0 'PJSIP/102-0000000f' allocated
[2021-08-27 12:36:31] DEBUG[2279] chan_pjsip.c:  PJSIP/102-0000000f
[2021-08-27 12:36:31] DEBUG[2279] chan_pjsip.c: Started PBX on new PJSIP channel PJSIP/102-0000000f
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  PJSIP/102-0000000f
[2021-08-27 12:36:31] DEBUG[2279] res_pjsip_session.c:  PJSIP/102-0000000f
[2021-08-27 12:36:31] DEBUG[2284] manager.c: Examining AMI event:
Event: VarSet
Privilege: dialplan,all
Channel: none
Uniqueid: none
Variable: SIPDOMAIN
Value: 10.0.1.24

 

[Mauro70]

its on the sip-server side...

even if the SIP server is the Dahua VTO itsef the 1:many early-media does not work?

 

[user8963]

even if the SIP server is the Dahua VTO itsef the 1:many early-media does not work?

good question...
never tested, try it

 

[Mauro70]

ah, ok, I misunderstood your statement then... from "if you use their sip server it works. " I understood it was working, and for me it could be sufficient, as I have no other needs to justify a dedicated SIP server like asterisk or anything else.
to test I have to buy it maybe I can place a question to DAHUA support and hope for a reply

 

[Mauro70]

Hey, I found this --> i16S/i16SV Audio/Video Intercom-Fanvil Technology Co., Ltd to be coupled with one of its indoor stations i51W, i52W, i53W and i56A acting as SIP Server: apparently it seem that the indoor station can be configured as SIP hotspot and allow group ringing. Not yet clear if also the video is included during the ringing, but it seems quite promising...