DECT ver 2

[nappyshock]

Can anyone confirm the Mitel IP DECT version 2 solution can work across IP trunks.
The reason i ask is i've been asked to look at a job where there is a three site cluster setup with two of the sites having mainly DECT phones, this has been setup previously but they have never been able to get the DECT phones communicating over the IP trunks so at present they have all site to site communication going via PSTN.
I had a quick look yesterday and the cluster looks like it is all setup ok, i temporarily setup a 5212 at each site to communicate via the IP trunk and they work no problem, however as the client says when i temporarily setup a 5212 at one site and DECT at another to utilise the IP trunk one way audio resulted with the DECT user able to hear the 5212 but not vice versa.
The Cluster operates over an MPLS backbone and this is at present were my suspicions lie, i'm thinking it must be blocking some traffic.
With regard to the DECT phones setup i've no experience but for internal and PSTN calls they are working fine.
I checked out the tech documentation and they fuction by communicating via a OpenMobility Manager device (OMM) so i'm assuming as all DECT communication is via the OMM then the OMM IP address is used in communication over the IP trunk. One concern i have is in the documentation describing the DECT call process for a IP phone dialling a DECT, the 3300 is supposed to supply the IP address of the DECT phone to the IP phone which then broadcasts the address and the OMM replies with it’s MAC address. However in the 3300 under programmed phones the DECT extension numbers show an IP address of 0.0.0.0 0.0.0.0 (although they have an IP via DHCP on the 3300 and can be pinged) so maybe this is the problem.
Maybe if someone has a working setup they could check their setup to see if this is normal.
However as i said, at present the MPLS is the number one suspect.

 

[slapin]

I don't think it is MPLS itself. One-way audio it is 99% routing issue. I have no experience with this specific product, so can you tell me with 100% confedence what is the voice circuit path is? It is starting at mic and ending at a speaker on other end. So, signal from the phone set arriving to the DECT base station. What is happening next?

 

[nappyshock]

Thanks for the input Slapin.
I've had another check and the DECT handsets don't have an IP address only a MAC address.
They communicate via these RF devices similar to Access points, so you can have a number of RF devices about the place and the handsets can roam between them, it is only the RF devices that have an IP address and it is one of these RF devices that you configure as the OMM and i belive all communication between the handsets and the IP network goes via the OMM regardless what RF device they are associated with.
So i belive the path for the data between two sites would travel from the IP Phone (5212) to it's 3300 over the IP trunk to the remote 3300 to the OMM to the DECT handset.

The reason i doubt routing is an issue is because from the main site where i was doing the testing i can ping all the RF devices on the remote site and access the remote 3300 and the OMM managment GUI also IP Phone to IP Phone between main and remote sites via the IP trunk can communicate without any problems and the DECT RF devices are on the same voice subnet as the remote Mitel 3300 and IP Phones.

What i need is someone to say they have a DECT ver 2 system working over a IP cluster. Like you slapin i've had no experience of this DECT system and for all i know it can't function over a cluster and i'm trying to fix the unfixable.

 

[slapin]

The think is that voice traffic doesn't cross actual 3300 controller when ICP is connecting two IP devices. That means you have to have direct IP access from OMM device to the IP phone on remote site and OMM should be avare of the default router which can pass traffic to other party. IP trunk is a virual entity for sending signaling traffic only. If your DECT base station is connected over analog or TDM line to the ICP, then voice traffic will actually cross your box.

 

[nappyshock]

The DECT handsets connect to the OMM (DECT base station)via wireless and the OMM (DECT base station) connects to the 3300 via IP.
So if your correct the signalling for the call will go via the 3300's over the IP Trunk and the voice traffic will be directly between the OMM and the IP phone.
The OMM is aware of the default router, you can communicate with it from the main site.

 

[slapin]

I would try to run some sort of network sniffer and confirm traffic path.

 

[Mitelpassion]

3300 version?

 

[nappyshock]

I believe it's 7.1.4.9_1

 

[Mitelpassion]

r u running vlans? is the OMM taking the same route as any other device communicating across the link?

it certainly does sound like a network issue.

we had similar issues on a site on release 8 and then went back to 7 and it was fixed again. not really scientific but the client didn't want to wait for a fix. in addition the guys that configured the network (Cisco kit) mis configured a bunch of things in any case.

the OMM has a command line but I'm not sure if it has a ping command, can't remember. if you can ping to and from any rfp it should work.

 

[nappyshock]

I'm glad you had it working on release 7, at least i know it should work. I've organised going on site in a couple of weeks, i'm taking a spare 3300 and am going to contect it locally via some routers to simulate the WAN link, i can then prove if it's a network issue.
I'll let you know what i find.

 

[nappyshock]

Just an update on this one, my site visit has been postponed by the customer as they have decided to get their MPLS network upgraded to ensure it is fully suitable for their voice infrastructure.
So it is looking very likely that this issue is network related.
I will post the results when it is resolved.