Setting up Andrews and Arnold VOIP with a Grandstream HT802 v2 and Plusnet Hub One

[#1]

Perhaps leave that voltage unchanged because ....

If the limit is 55v that field is more like the constant line operating voltage ( 48 - 50v DC is the norm )

The Voltage for ringing the bell of the phone at the start of a new call is usually much higher 60 or 70 up to  85 or 90v AC.

[#2]

A&A have test numbers:  https://support.aa.net.uk/VoIP_-_Special_Codes

Even calling to the A&A Voice Message service would allow making repeated calls
to test the stability of the in-bound voice stream.

[#3]

---

@PhilipHeyes wrote:

The Voltage for ringing the bell of the phone at the start of a new call is usually much higher 60 or 70 up to  85 or 90v AC.

---

I can believe that this is the voltage at the exchange end of the line.

However, surely the voltage at the consumer end depends on the impedance/length of the line and the REN load on the line? I would assume that this is less than 55V. 

[#4]

@Baldrick1 

For our Cisco ATA the Ringing Voltage is 85v AC this is the default.

The Grandstream's 55v DC line voltage option is perfect match for emulating a New Zealand phone exchange.

VoIP often exceeds BT exchange performance because long telephone line losses have been minimised.

[#5]

---

@PhilipHeyes wrote:

@Baldrick1 
VoIP often exceeds BT exchange performance because long telephone line losses have been minimised.

---

That’s precisely my point. The ATA only needs to emulate the voltage at the property end of a long line with maximum REN loading, not the exchange end sending voltage.

[#6]

@Baldrick1 

So perhaps at 4KM line from the BT exchange, with initial exchange end voltages of 48DC  and a 75AC Ringer Voltage we might expect to see the on hook DC voltage measure almost 48v as there is no DC load on the line and during Ringing 50 to 65v AC as the telephone's ringer is energised.

@daniellam 

I'm curious to know if the in-bound ringing and call set up  ( SIP ) and in bound voice issues ( RTP ) have been resolved by moving both the local SIP and the local RTP ports well out of the SIP/ALG range.

[#7]

Hi @PhilipHeyes - unfortunately, inbound voice issues haven't... I can see from the CDR data on the A&A control pages that we had a family member call (I was out and someone else took the call), and they had to call twice. The same thing happened yesterday. This is despite:

• STUN server set to stun.aa.net.uk and NAT Traversal set to STUN
• SIP port set to 15060
• RTP port set to 15004
• Symmetric RTP enabled
• ...as well as all the other keep-alive settings posted earlier

I know that A&A are sending the SIP traffic to the correct port (15060) because here is what they have registered at their end:

Registered devices: 1

22:03:17

B.Voiceless

22:13:17

31.125.xx.xxx

Grandstream HT802V2 1.0.5.4

[email protected]

Inbound ringing works OK (always has) - it's just that we cannot hear the caller once the call is answered. Second time around, everything works fine.

Unless you or anyone else has got some suggestions for other things to try (other than swapping the Hub One for something else), then I might just have to live with it. To be honest, the setup works - just not at the first call

[#8]

Hi @Baldrick1 - just wanted to add a bit more detail. So, what I have connected to the ATA (on the same FXS port via a splitter) are:

• A BT Viscount with a REN of 1.0, about 2m away from the ATA
• A Gigaset A420A base station with a REN of about 0.1, no more than 10m away from the ATA

Google Gemini reckons that the "Ring Power" setting of 50Vrms is more than enough to ring both these devices at the same time but advised against using 45Vrms (which is the default setting on the Grandstream HT802 v2). I can confirm both do indeed ring simultaneously.

[#9]

@PhilipHeyes - the only other thing I can think of (actually was suggested by Google Gemini) is to randomise the RTP port chosen (the Grandstream ATA allows this). Not sure if the Plusnet Hub One's firewall is stateful and "remembers" certain port number requests (and tries to block where there are multiple inbound requests), but that's about the only thing I haven't tried.