Unsupported Internally connecting a PortaDial door system.

[net-products]

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). .

 

[KyriacosS_3CX]

Hi,

If you share the OK/ACK SIP message that triggers the error (or the full registration with any passwords etc stripped), perhaps somebody could figure out how to remove the incompatibility, since if the call works I assume the main issue is resolved?

 

[net-products]

I've redacted a packet capture.

Since I've deleted the test phone, I shouldn't need to look for any SIP passwords. All IPs are local, I just had to remove domain name and personal names from any extensions involved.

In the hope that it may be useful, this is a packet capture of a failed attempt:

https://oc.net-products.nl/index.php/s/FzlismmV5XyApJA

After changing to 3CX provided config, the capture there won't provide you any information, so I haven't included the second one. There's a similar looking invite, then a ring, then... nothing. There's no SIP NOTIFY, because the grandstream no longer automatically picks up the phone with the new settings file.

 

[KyriacosS_3CX]

Hi,

Can you check the pcap download? My wireshark is complaining of a corruption somewhere. I can open it in a text editor, so some things are visible.

For reference, what machines are IPs .9, .11 & .13?

 

[net-products]

The .11 is the DHCP IP of the phone used to do the test call.
The .13 is the IP address of the HT801
The .9 is the IP address of the SBC gateway, and also the capturing host, so it should be either src/dst of every packet.

I just directly replaced things in the hex file, this may have mangled packet sizes.

 

[JohnS_3CX]

Hi @net-products

Might be a better idea to contact the doorphone hardware manufacturer instead and get them to help you because we cannot assist with custom hardware.

If you were to use the HT801 as intended, and the manufacturer tells you what stuff to change on it afterwards, then it's probably gonna work just fine (up to them to confirm).

While we do support the HT801, we do not support whatever custom stuff this device may or may not have. Also, the firmware on your HT801 is incredibly outdated, so if it were me I would start from that most likely and see where it takes me.

PS: You could always skip this jerry-rigged device and go for a proper SIP based supported doorphone from here if one happens to suit your specific needs https://www.3cx.com/sip-phones/

 

[net-products]

I found the solution.

After putting up a second test setup locally, I set it up in an hour after a day of comparing XML settings via a PHP script.

Turns out: All of the provisioning stuff is not necessary and it changes way more settings than it needs for things to at least function.

The instruction that worked:

1. Fill in the primary SIP server and
2. Outbound Proxy (SBC),
3. Copy the SIP userID/authID/authPassword/Name from the provision XML.

and that's all you need. In reality, the exact same procedure as with the external VOIP provider (without a whole bunch of port forwarding and VPN misery).

The actual mistake:

There was an extra regular space (0x20) behind the username. I didn't copy that trailing space before. Things work properly without having to painstakingly analyze which different settings work.