This is to me a very weird one.

Components: Axxess w/ 10.003, 5200 w/ 3.0.6.171, 8662 IP Phones. Mixed environment


Ports currently set to open:

TCP: 5566, 5570
UDP: 5567, 5004-5070
UDP: 6004-7039 (8662/5200)


ISSUE: We have an office in the US (Axxess) and in the UK (5200). The UK Office is entirely IP.

All Corporate Office locations (3 in US, 1 in UK, 1 in France, 1 in India) work fine, any office can call any office.


We have a REMOTE User in Holland homed off the IPRC in Bristol.

I can call him from my US Office w/my digital ext., all works well. Same in reverse (he can call me).

I have set up a test IP phone homed on the UK IPRC, same as his - that also works.

HE CAN NOT TALK TO THE UK!! Phones ring, either way, but no sound, either direction.

Almost CAN'T be a blocked port, or how could I talk to him?

The 'bang head' icon in this case quite literal! Anyone got a clue?

:bang: :bang: :bang:

So there is a 5000 in the UK, right? And the Holland fone is connected to it?

Go to System\Devices and Feature Codes\Network Groups. Check which group the Holland fone is in and whether it is a Peer-to-Peer group. Also check if the UK fones are setup for P2P. If that is the case, yer NAT translations could be broke b\c the audio stream would shift from the PBX internal IP address to the IP of the called\calling UK IP fone. Yer router\firewall will then not allow the RTP voice to route correctly at that time.

Showing two (2) Network Groups, one labeled as 'Default Network GRP', the other no label.

The no-label group has the most entries (39), INCLUDING The 'Problem Phone'! It is also showing 'Use P2P Audio' as 'Yes'.

The 'Default' Net GRP has WAY fewer entries (12), including my 'Test Phone', and P2P set to 'No'.

Can and Should I just drag-drop the offender, or is there another way to move him, if that's the problem?

TIA

Put the Holland fone into the default group and test.
Peer-to-Peer IP audio is the preferred method of UDP IP audio transport b\c it removes one node from the IP route during an IP to IP call. However it also can complicate things like NAT rules b\c all internal VOIP devices have to able to use your NAT rules, and that is not a common way to do NAT.

SUPERPHONEGUY Lives Up To Name!

First report in from our Malaysia office is successful. Same setup as Holland, (out today), but s/b same result.

Our local Inter-Tel had us checking for 'split routes' on our firewalls/routers.

Thank You Sir!

:bow: :dance: