One way audio - Inbound ISDN call sent over an IP Link

[RDECIT]

We have a customer running 2 x 3300 MXe's. Very latest MCD build. They have two sites with a 3300 on each and are linked via an IP Trunk. Each site has it's own ISDN 30 for making outbound calls however site A has all the DDI's which relate to most groups and extensions located at site B. So the majority of calls will always come in at site A and then routed over the IP link.

Site A experiences no issues inbound or outbound.
Site B are experiencing issues with one way audio (They can't hear the caller but the caller can hear them) This can happen 2 seconds into the call to a few minutes into the call. If site B then calls the person back using their local ISDN they have no problems.

I'm making the assumption that it is the IP link that is causing the issue but I'm not sure what the best method of bug fixing will be. As a start I've enable compression on the IP Trunk as this was off.

The WAN link is a wireless lan extension between sites which we have no control over, but I'm wondering if I should be talking to the provider about voice QOS.

 

[KurpeusLondon]

If this was happening always at start of the call, I would think about a firewall in between dropping traffic .

I've seen that although, the call set up use the IP trunk, IP sets open a channel directly to the remote peers and do not use the PBX to send traffic through. The result is that you encryption domain must allows your voice networks to speak directly.

If it was a QOS issue, I would expect to have numerous packets dropped during the call (deteriorate the call quality), but not all of them

 

[Mitel100]

First thing I would do is make sure that the 3300 L2 ports are running in Full Duplex.

On the command line of both 3300 put the command L2 STAT PORT 1

Scroll back up and it will tell what the speed and duplex is. If it is running at 100 Full then you need to look at the network side.



__________________________

There is no 'I' in 'Team'
__________________________

 

[IrwinMFletcher]

Sounds like a connection timing issue. Answer supervision on the original trunk?

I like to look at the streaming first, so I would look at the E2T of the gateway system and check to see when the system starts to stream to the set off of site B. If it's late, then you know it's a signaling problem and not a firewall/network issue (which I doubt it is, but it's a place to start).

 

[Mitel100]

Also, If a phone from site A was to call site B without using the ISDN, is there still a problem?



__________________________

There is no 'I' in 'Team'
__________________________

 

[dryaquaman]

You may need to do a wireshark sniff of both phones. Look for an ICMP redirect. If you see it, turn ICMP off in your routers.

Dry Aquaman

 

[RDECIT]

Thanks for all the suggestions, one major point I left out, is that this isn't a constant thing. Most calls are fine, but I've been here all day and have been told at least 10 calls have done it.

Mitel100, both ports are 1000Mbps FULL.
Port MAC Address Status Speed Duplex Flow Control
------------------------ ------------ ------ ----- ------ ------------
1 08000f4056c7 Up 1000M Full Disabled

Port MAC Address Status Speed Duplex Flow Control
------------------------ ------------ ------ ----- ------ ------------
1 08000f405b25 Up 1000M Full Disabled


dryaquaman, Mitel suggested a wireshark, problem is that it isn't the same phone. It is random making packet sniffing a lottery as it might not happen on that set for a while or ever.

 

[IrwinMFletcher]

Set the wireshark on the site a controller, not the set.

 

[RDECIT]

I'll change it, I was just monitoring the set lots of numbers scrolling up the screen. Being new to wireshark, how do I direct it to the controller and am I best filtering stuff out?

 

[IrwinMFletcher]

You need to physically move it to the controller and either through your L2 or the controller, mirror the packets to the pc with wireshark.

What you will see is a stream going to a particular set, and a stream from that set. If you see that the set->controller starts (in time) well before the controller->set stream, then you know it's a signaling problem.

You can set a filter to have the source and destination IP address as that of the E2T. e.g. if your E2T has the address 10.38.2.2

ip.dst == 10.38.2.2 || ip.src == 10.38.2.2

 

[RDECIT]

I'm at site b,canI not monitor everything and filter it down to the controller.

 

[IrwinMFletcher]

The problem with that is that you are trying to determine if it's a call setup problem, or a streaming problem. If you've got too much equipment between what you capture and the source of the stream (site A), then you can't say for certain that it's not a streaming problem.

 

[RDECIT]

Ok, I've come to site A. Its on a procurve switch so my wireshark deivce is on port 2 set to monitor port 1 (3300 L2 port)

 

[RDECIT]

What you will see is a stream going to a particular set, and a stream from that set. If you see that the set->controller starts (in time) well before the controller->set stream, then you know it's a signaling problem.

Irwin, I've got wireshark on and filtered it down. But it's just a constant stream of in, out, protocal and port info. I don't really know how to read these results.

 

[IrwinMFletcher]

What you'll see under the time column is the relative time that the packets arrive. Look for the start of the stream that is sending the UDP packets from the set to the controller on site A, note the time. Do the same for the stream going from the controller to the set.

The difference in time should be small, less than a second or two. This is the time it took to complete (part) of the signaling. If that time is large (many seconds) and matches the time that the set side has to wait before it hears the far end, then there is a problem in the signaling.