I wonder if anyone else has tried doing this.
Currently, I'm running into an issue of settings incompatibility.
First, if it's configured as a 'generic phone' this will not work. It will make a SIP connection, but 3CX refuses to start the voice RTP with a '406 incompatible' SIP error code. I'm seeing proper SIP Register messages, but after an Invite/Ring, the OK/ACK from the device is answered by the SBC with a 'not acceptible' error.
I know the SIP account data is correct, because by deliberately setting a wrong password or extension number, the registration will fail. I know it's not a network issue, because by using a different provider, things function, and because I can see traffic over all the relevant ports, and because all this is captured on the local LAN, with no firewall bertween SBC and the 'phone'. As the SBC is a generic linux device, I can do packet captures there and inspect unencrypted SIP traffic between it and the doorbell.
I found that this doorbell system internally uses a GrandStream HT801, which has a web-interface that can be used to configure it, and there is also a 3CX help page for giving that system a pre-generated deployed configuration file and settings within 3CX that allows it to function like a typical extension: https://www.3cx.com/voip-gateways/grandstream-ht-fxs/
However, this configuration method assumes that what's behind the HT801 is a phone, not a doorbell. So it also destroys (via overwriting because it takes control over all the settings) a bunch of the extra configuration programming that was originally present inside the grandstream. The result is that the device will no longer automatically pick up calls (which is configured via the GrandStream, which sits in front of the analog device).
Unfortunately, some of that configuration is not present in the HTML config page. So for example, settings P24601 = 16, P694 = 97, P730 = 0, those are all defined in the config.xml from factory settings, but are obviously not sent by 3CX. There are over a thousand of such values, with no information about what each 'P number' means. Hence, what I have to do is somehow merge the two configurations.
As far as help is concerned, what would be amazing is if I knew which settings I'd have to change manually to make the HT801 compatible with 3CX, and do so, rather than try to work out which of the 1,250 opaque XML values that make up the factory settings XML are the important ones by hand, testing them one by one (this would be a rather large amount of trouble to put it mildly, trying to look them up in the HTML sources of the GrandStream's three configuration pages or even doing actual reverse engineering). .
Currently, I'm running into an issue of settings incompatibility.
First, if it's configured as a 'generic phone' this will not work. It will make a SIP connection, but 3CX refuses to start the voice RTP with a '406 incompatible' SIP error code. I'm seeing proper SIP Register messages, but after an Invite/Ring, the OK/ACK from the device is answered by the SBC with a 'not acceptible' error.
I know the SIP account data is correct, because by deliberately setting a wrong password or extension number, the registration will fail. I know it's not a network issue, because by using a different provider, things function, and because I can see traffic over all the relevant ports, and because all this is captured on the local LAN, with no firewall bertween SBC and the 'phone'. As the SBC is a generic linux device, I can do packet captures there and inspect unencrypted SIP traffic between it and the doorbell.
I found that this doorbell system internally uses a GrandStream HT801, which has a web-interface that can be used to configure it, and there is also a 3CX help page for giving that system a pre-generated deployed configuration file and settings within 3CX that allows it to function like a typical extension: https://www.3cx.com/voip-gateways/grandstream-ht-fxs/
However, this configuration method assumes that what's behind the HT801 is a phone, not a doorbell. So it also destroys (via overwriting because it takes control over all the settings) a bunch of the extra configuration programming that was originally present inside the grandstream. The result is that the device will no longer automatically pick up calls (which is configured via the GrandStream, which sits in front of the analog device).
Unfortunately, some of that configuration is not present in the HTML config page. So for example, settings P24601 = 16, P694 = 97, P730 = 0, those are all defined in the config.xml from factory settings, but are obviously not sent by 3CX. There are over a thousand of such values, with no information about what each 'P number' means. Hence, what I have to do is somehow merge the two configurations.
As far as help is concerned, what would be amazing is if I knew which settings I'd have to change manually to make the HT801 compatible with 3CX, and do so, rather than try to work out which of the 1,250 opaque XML values that make up the factory settings XML are the important ones by hand, testing them one by one (this would be a rather large amount of trouble to put it mildly, trying to look them up in the HTML sources of the GrandStream's three configuration pages or even doing actual reverse engineering). .
