atcomsystems.ca/forum Forums TDM Business Telephone Systems Toshiba Telephones & Systems DID problem

Hi all.

I'm having a weird issue with DID numbers that point to IP phone extensions on a remote IPU.

For example I have 2 buildings with CIX40 systems. The PRI resides at a 3rd building with the phone system being a CIX670. All of these systems are networked, but when I try to assign a DID in emanager to one of the extensions on the CIX40's, I run into a weird problem.

When making the call, the caller cannot be heard. However, the caller CAN hear the person who answers the call.

I have no issues assigning DID's to the extensions at the building with the CIX670. They work fine. Just not at the remote sites with the CIX40's.


Anyone heard of this before?

Hi AndyK, welcome to the board!

Just to clarify...

1. Are the remote buildings (CIX40's) networked via Q-Sig over point-to-point T1's?

2. Do the CIX40's use the PRI on the CIX670 for in/outbound calls?

First suggestion/question - Have you tried changing the CoDec's or the Voice Packet Transmission Interval?

Thanks for responding!

Well, the buildings are networked with Proxim Tsunami wireless bridges. We aren't using point-to-point T1's for that.

The CIX 40's do use the PRI on the CIX670 for outgoing calls most definitely, but right now most incoming calls to those buildings are transferred through vociemail.

For example, someone dials the main number to our company and the voicemail auto attendant answers. They dial the extension for that person at the remote building and their phone rings. They answer and all is good.

When I assign DID's to the same remote building extension, that's where the caller can't be heard, but the caller can hear the person who answered their call.

I'm not really at expert level yet with eManager so it's hard to say about Q-Sig. I can tell you what I've got though for setups in ILG.

On the 670, it shows a group number 1 for ISDN. This is the DID CO service type, and the line type is CO. Private service type is Standard.

There is also a group number 20 for ISDN. In there the service type is DIT and the line type is TIE. Private service type is Q-SIG.

That same group 20 for ISDN is on both CIX 40's under the ILG setup.

As for as CoDec's or Voice Packet Transmission I don't really know where to look.

The software was given to me by the vendor when we got our system. They gave me a crash course but nothing too in depth, so I'm learning a lot by the seat of my pants.

Hopefully, that info gives you a better idea of what may be going on. I can't help but think it's something to do with either the networking portion or something with the incoming line over the network since it's the incoming caller that can't be heard.

Anyway, thanks for any advice you can offer.

Andy

A bit of an update here. I was tinkering today and found out something even more strange.

I was trying different things trying to get it to work and decided to call the DID number, then do a transfer to my phone which is at the building with the 670 and PRI.

I transferred the call to my phone and it worked with no problem. Not that surprising I guess.

BUT

Afterward, I tried the DID again. This time it worked!!

It only worked a few times before it stopped working. If it stops working I repeat the above steps. Call the DID answer the call...transfer it to my phone, answer the call at my phone wait a few seconds, and hang up. When I call the DID immediately afterward, it works again.

Not sure if this helps at all, but I found it interesting.

I think you get the award for the best described, most puzzling question of the year so far.

You're telling me!
I've been trying to resolve this one for about a week now! It just seems so weird and hard to pin point. I've looked through a bunch of settings in eManager, and I finally figured out what MacOSX was talking about above and played with those settings a bit, and it wasn't that. Only thing I can think is something isn't shaking hands properly 100% of the time with the CIX 40 and the 670 with the PRI at the remote location.

Nobody seems to have any ideas here, so I'm just going to keep throwing out what I'm doing to try and resolve this so it might spike some ideas.

I decided to take a phone programmed for the main building with the CIX640 over to one of the remote buildings with a CIX40 to try and see if a call through a DID would work, or it would not work.

I did this basically to eliminate the wireless link(Proxim Tsunami) as the problem.

The wireless has been eliminated. A call to the phone through DID worked fine, even at that building.

Now my next step will be looking at how those remote systems use the PRI. The problem must be with that part of the configuration, right?

Anyone here know what I should typically see in my eManager if I have two buildings using CIX40's and the main building with the PRI using a CIX640? I'm looking for things I can tweak, maybe find a mistake, etc.

Any help would be great...I know this is a difficult one.

All your phones are IP phones? Intersting how a phone registeredto the CIX670 IPU works correctly accross the network.

Typically in an VoIP environment, the 2 endpoint devices will communicate directly after a call is established. I believe that for the IP phones registered to the local CIX system will talk directly to the IPU on the main CIX 670 system. The local IPU on the CIX40 will establish the call and will no pass audio traffic.

If that is the case, the the problem is between the Main IPU and the remote IP phone, where the RTP traffic is't passing correctly. Since the caller can not be hear I would guess it is a problem from the main IPU to the remote IP phone.
The best way to verfy this is to use wireshark at one of the endpoints.

I would guess that all the IP addresses are local network IP since you are not routing through the WAN.

Just to throw stuff out there, you could try setting the NAT, no peer to peer setting in the IPT to enabled. This is usually not set in a LAN enviroment, but it causes all audio traffic to be sent to the local IPU. I'm not 100% sure if it effects IPT to IPU traffic. For that matter I'm not 100% sure the local IPU is bybassed across a Stratanet network either.

Also, sometimes Diffserv or 802.11Q and P can block audio if the LAN devices don't understand the signaling. Try disabling them to see.

We do have a few Digital telephones. They run off of the CIX670 because there's some digital station cards in it. However, most are IP phones. There's no digital phones at the remote sites I'm talking about. All of the IP's for the phones themselves are a VLAN. VLAN 10 to be exact, then our data network is on VLAN 1.

Thanks for the ideas, I'll try them on Monday and give an update as to what happens. I've already glanced in eManager and found the NAT peer to peer setting, and I do have wireshark. Anything in particular I should be looking for on Wireshark when I run it?

One dumb question though, where would I change those Diffserv or 802.11Q settings you're talking about? Would that be on the Tsunami?

Thanks again!

I have not used Vlans on Toshiba systems as of yet. Like I said, preferably the NAT setting should be left disable a LAN setup, but I was throwing stuff out to try.

As far as Diffserv and 802.11Q, they are both QOS with ideally should help with the quality of the audio. Diffserv is enabled in Prg 150, System IP Data, FB 03. If it is enabled, then FB 04 defines it ad TOS or DSCP, and for DSCP you assign it a number in FB 06.

802.11Q is enabled in PRg 161, IPU configuration. You wouldn't want to change VLAN, but you can try to disable packet prioritization.

Normally for either QOS setting, any device that does not recognize the header info will just ignore it and pass it through, but I have seen cases where the audio gets blocked, usually across a WAN.

As far as Wireshark, if I were doing it I would look for the RTP traffic to/from the IP phone to see which device IP it is talking to during a call, just to varify my thought that the IP phone is probably talking directly to the IPU on the remote side. Then I would try various point in the network, were possible, to see if any device on the network is not passing the audio, such as either side of your router.

Obviously you could mirror a port on some switches. If you had a data hub (a 10BT in an old pile of junk somewhere) you could move the snoop point around a bit, but maybe just mirroring the data switch will give you the info you need.

You would see some Megaco traffic to that phone also. I'd be more concerned about the Realtime Traffic.