go2rtc

go2rtc copied to clipboard

Apparently some Dahua doorbells uses this codec by default for SIP communication, and changing it (somehow) breaks SIP communication.

Originally reported by @oNaiPs here.

According to @alexxit (here), it would be possible to support L16 for backchannel in go2rtc itself.

This separate issue is open for specific discussions about supporting L16 in backchannel in go2rtc, and upvoting. @alexxit, please don't change your priorities just because I opened this issue. And thanks as always.

It's better just to use full RTSP link to Dahua cameras. That support many codecs for backchannel.

But according to the screenshot here https://github.com/AlexxIT/go2rtc/issues/49#issuecomment-1763463491, he is using the full URL (you can see at the top).

@onaips are you in the latest firmware?

But according to the screenshot here #49 (comment), he is using the full URL (you can see at the top).

I am using the URL rtsp://admin:pass@ip_addr/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif

@oNaiPs are you in the latest firmware? yes "2021-05-14 V4.500.115A000.0.R"

What is your camera/doorbell model?

@felipecrs I have VTO2211G. According to this I should have a newer FW update, trying to update now.

I usually check updates from the official Dahua website. But apparently they are pointing to the same version anyway (220523).

https://www.dahuasecurity.com/en/products/All-Products/Video-Intercoms/IP-Series/Villa-Door-Station/Pro-Series/VTO2211G-WP

@felipecrs I am now on "2022-05-23 V4.511.0000000.0.R" updated the VTO with the ConfigTool (only works on Windows), firmware from here. EDIT: this link has the same version as the link you sent above.

Right. But what about the backchannel codec? How does the "sendonly" track looks like now? Mine looks like this:

"audio, sendonly, MPEG4-GENERIC/16000, MPEG4-GENERIC/8000, PCMU/16000, PCMU/8000, PCMA/16000, PCMA/8000, L16/8000, L16/16000"

@felipecrs I think that might be the webrtc leg. You want to look at what the RTSP camera is providing. Can you check the lots from go2rtc? That would be clicking on "info":

And you can see:

Ok, that's weird. Maybe one alternative solution for you would be:

• https://github.com/AlexxIT/go2rtc/issues/52

@AlexxIT, if that one gets implemented someday we can then probably just close this one. It is unlikely that someone else will ever need L16 audio in backchannel if they can use CGI instead.

@AlexxIT if you can provide me with the sample code and some points on where to place the code for this task, I can attempt to implement it (go developer here, I already setup go2rtc dev environment)

Check ISAPI source. I think it's most similar

I've been following this and related threads and experience similar issues with a VTO2201 so thought I'd pass on the info.

My setup is using frigate docker with go2rtc v1.7.1 installed into it, and I've been experimenting without a VTH setup. I'm just trying to get the mic working via webrtc so I can use from Home Assistant at this stage. FYI I have mkcert (self-signed) SSL setup so chrome asks permission for mic usage.

I'm 100% certain my setup works (desktop mic received audio is output on VTO) so long as the VTO codec is G.711A with frequency 8000. The VTO defaults to PCM/16000 after every power recycle as confirmed by cgi getConfig action.

I've been setting the required parameters using the echo script approach but I get inconsistent rtsp setup (via go2rtc info links). Sometimes the sender is there, sometimes not. If I check current config via cgi the settings are correct. Not sure if it's the VTO unable to initialize before go2rtc restreams or not. I do not know enough about how that works.

Putting the inconsistent setup aside, I thought I'd check what happens if the VTH is in the mix. I setup the VTO for the G711/8000 and confirm set with getConfig. I then make a SIP call from VTO to VTH and the VTO has reset itself back to its default PCM/16000. So it seems I've no way of getting away from L16 (PCM).

Hi @oNaiPs have you managed to get 2-way audio on your VTO2211G?

Is there anyone here who can use two way audio via go2rtc with their intercom? I have tried but the delay is too high. Is there a solution? I am currently using a SIP server, but I would like to get rid of it.

Is there anyone here who can use two way audio via go2rtc with their intercom? I have tried but the delay is too high. Is there a solution? I am currently using a SIP server, but I would like to get rid of it.

If it's a Dahua doorbell, I believe your best option will be https://github.com/AlexxIT/go2rtc/issues/52.

I'm sorry, I can't see how I have to configure it so that it works via cgi. Can you explain how I have to configure it?

lol, sorry. I meant that when that gets implemented, it should be the best option.

Well then, I hope it will be implemented soon 😉.

@felipecrs I think I played too much with DAHUA VTO CGI commands, and now my VTHs don't play the video feed when VTO button is pressed. I can see the video feed manually on the VTHs and also from RTSP.

I tried factory resey, without success. Any clue?

Factory reset should resolve all issues like these. Maybe factory reset both the VTO and VTH?

I don't use VTH though. I only use VTO with my own SIP server.

Up for this feature 👍 this will be great to have Dahua doorbell support in HA.

@felipecrs I also have a Dahua VTO and a 3 VHT, I tried the CGI workaround, but when I change the coding on the VTO the audio on the VTHs became crappy till I restart them. I suppose that the VTH query configuration to VTO at startup only, so if coding is changed in the middle, something broke up.