Mitel Forums - The Unofficial Source

Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: ralph on August 26, 2011, 11:49:11 AM

Title: One Way Audio
Post by: ralph on August 26, 2011, 11:49:11 AM
I'm in a bit of trouble.
I was brought in on a problem where inbound SIP calls ring in ok, the outside caller hears the inside person but the inside person hears nothing.
In talking with the firewall tech, he says the external IP address is NATing (PATing) 5060 to the 3300.
My question is this: When a call comes into the 3300, the 3300 sets up the call to the phone.
Once the user answers the call the 3300 drops out.   So how would the incoming audio hit the phones if FW policies only NAT to the 3300?

Ralph
Title: Re: One Way Audio
Post by: ccboe on August 26, 2011, 01:22:30 PM
just thinking out loud

I would think you need to setup your sip device to use the 3300 as the proxy.

Tom
Title: Re: One Way Audio
Post by: brantn on August 26, 2011, 01:38:42 PM
What kind of firewall? This issue is more then likely audio ports not being allowed through or SIP settings not being enabled in the firewall. SIP is only call setup so yes 5060 might be allowed through but what about the 5000 audio ports that can be used?
Title: Re: One Way Audio
Post by: ralph on August 26, 2011, 02:30:51 PM
SIP Trunks - not devices
Juniper Firewall.

I'm part way fixed now.  - or at lease I was ~.5 hr ago -
Firewall tech reset the NATing and we started geting audio again.
Now we just cant transfer and get audo.
If we put the call on hold/off hold we loose audio.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 26, 2011, 06:41:15 PM
Try changing avoid signalling hold to Peer and let me know.
Title: Re: One Way Audio
Post by: ralph on August 26, 2011, 11:21:16 PM
Tried that.  Didn't work.
I hate being in a position where I don't control of the firewall.  Too much finger pointing going on.
Two full days so far and it's still not right.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 28, 2011, 12:15:25 PM
Send your SIP Peer Profile to me just to verify also what is your Simulated CCM before ISDN progress in the trunks COS. After I verify those then I will blame the firewall.
Title: Re: One Way Audio
Post by: ralph on August 29, 2011, 09:15:42 AM
Thanks brantn,
I've attached the SIP Peer Profile.
I checked the COS of the trunks for simulated CCM before ISDN Progress.  It was set to no so I changed it to yes.  No difference.
It's now back to no.

My current biggest problem is that if you put a call on hold or transfer, you loose audio.

Ralph
Title: Re: One Way Audio
Post by: bobcheese on August 29, 2011, 10:10:11 AM
Hi Ralph, what version of software are you running on this 3300?
Title: Re: One Way Audio
Post by: ralph on August 29, 2011, 10:11:47 AM
10.2.2.10
Title: Re: One Way Audio
Post by: brantn on August 29, 2011, 11:29:53 AM
Avoid Signaling Hold to the Peer Set to Yes
Enable Mitel Proprietary SDP Set to No
Title: Re: One Way Audio
Post by: ralph on August 29, 2011, 11:36:09 AM
Thanks brantn,
Made the changes but it made no difference.
I"m now looking at wireshark traces external to the firewall.
Tech support saw me sending invites to the carrier but got no responses.
Could be carrier.   Could be firewall.
Working through the trace now.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 29, 2011, 11:52:30 AM
With those 2 options set that should be a working config I am assuming then it is the firewall. I would look closely at the media ports as that is the typical issue is it is there just going to the wrong port because of consistent nat issues.
Title: Re: One Way Audio
Post by: ralph on August 29, 2011, 07:05:30 PM
Firewall!
Tech reset the NAT policies and BOOM!  Audio!!

Still working though some other issues but at least we're up after 3 business days.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 30, 2011, 04:19:05 AM
Just a word of advice to all those sip lovers out there save yourself a lot of time and effort and use the ingate product line for sip termination it makes things a lot easier as well as that is what the majority of Mitel testing is done with.
Title: Re: One Way Audio
Post by: ralph on August 30, 2011, 06:11:20 AM
We have an Ingate in our office.  (not the site where I've been camped out for the last few days)
I esp. like how I can pull sniffs from it without a big hassle.

We have ours set up in parallel with the firewall.
Will the Ingate set up in DMZ like a MBG will or does it have to be external to the FW?

One of the issues I have to deal with constantly is that when a sales rep sells a system with SIP trunks and you tell them they need to sell an Ingate with it, they hit me with "they have a SIP aware firewall.  If it's supported then we don't need an Ingate."    The sales rep makes his commission and we loose our shirt on the back end.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 30, 2011, 11:23:47 AM
I hear you there as that is the biggest fight we have as well.  There are a lot of nice configuration options on the Ingate line for different topologies. The capture piece is nice and test calling. Stun settings. You can limit traffic and ports. Just the way to go if you want no hassle. Takes a little setup but they have some great videos and documents on configuration.
Title: Re: One Way Audio
Post by: ralph on August 30, 2011, 12:05:37 PM
Struggling through my next issue at this site:
There is a second site connected via mitel IP trunks.
If a call comes in to one location and is transferred to the remote end, the answering extension cannot hear although the calling party can.   Doesn't matter which site the call starts from.   Only gets one way audio.
I'm really blind on this one.  Wireshark isn't showing me anything I think I can use.   Since the call is trans-versing a VPN, I can't see anything even though I'm sniffing the external FW interface.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 30, 2011, 03:04:39 PM
QSIG Diversion Enabled? Trunk to Trunk? Simulated CCM before ISDN Progress? Third should make a dent in the issue as it changes call signaling.
Title: Re: One Way Audio
Post by: ralph on August 31, 2011, 09:15:37 AM
Back on site again.    :(
My call diversion is off,  Trunk to Trunk is ok, what do you suggest the CCM before ISDN progress to be set to?


As I write this the carrier is setting up some additional traces on his switch.
He wants to see what he can on this issue.

What I'm thinking is ultimately we're going to have to have the carrier give us a unique IP to connect to for each site.   Then in the firewalls I can force routing correctly.

I'd like to here a perspective from Ingate on this.   Maybe I can get them to chime it.
If a Siperator would resolve this I need to know so I can insist on it for next time.   Need to know how and why this would help.

Ralph
Title: Re: One Way Audio
Post by: brantn on August 31, 2011, 11:16:26 AM
Assuming you have ip trunking between sites? CCM I think should be yes but mine are set to no currently so I will have to test when I get some time. What if you route a call to the other pbx with no transfer?
Title: Re: One Way Audio
Post by: ralph on August 31, 2011, 11:43:54 AM
Routing to the far end (voice mail) produces RNA.
Here's the problem.
The call come in one firewall that's set to NAT for it's voice network.
When it transfers to the far end the local FW isn't set to NAT for it.
What happens is, in the body of the SIP message the carrier is then told to send the call to 192.168.179.x   
Now the carrier doen's know how to get there so the audio dies.

I'd be interested to know if there is anyone, anyone at all, that would have the two 3300's, both with their own SIP trunks that are networked together without using a proxy.

I do have 4 separate solutions for this problem.  All of them ugly.   One of them is >$10,000 US with proxies.   Another is using T1/E1 modules for some looping.  That's still ~$4000.

Ralph
Title: Re: One Way Audio
Post by: MitelAvayaNortel on August 31, 2011, 03:45:36 PM
I'm not sure if this would help, but what would happen if the incomming call to switch 1 rang a speedcall to get to the extension on switch 2.  Would this mean that the call then had 2 directional audio?
Title: Re: One Way Audio
Post by: brantn on August 31, 2011, 04:15:01 PM
I have multiple trunks going to multiple sites. Asterisk, Exchange, Nortel Softswitch, Genband Softswitch without proxies.

Going to need and see a wireshark of the bad call.

When sent to the remote site can they hear the calling party or no audio at all?
Title: Re: One Way Audio
Post by: brantn on August 31, 2011, 04:22:24 PM
By the way as a note on ingate here is what you would do ...

Terminate trunks from both sides into the unit.
Dial Plan routing 1000-3000@ITSP address send to local site
Dial Plan routing 4000-6000@ITSP address send to remote site.
Dial Plan routing 1000-3000@Local address send to ITSP
Dial Plan routing 4000-6000@Remote address send to ITSP

At least that is the jist of course there is a little more to it but very easy.

Is your sip connection just carrying voice? or voice and data?
Title: Re: One Way Audio
Post by: ralph on August 31, 2011, 10:03:46 PM
MitelAvayaNortel,
That's exactly what I did.  Speed dial to remote ext.   - one way audio.

I worked with the carriers CCIE.   He did a packet sniff on his switch.
The problem appears to be when the call is transferred to the remote site in the body of SIP the packet, it says to connect to 192.168.279.68    This would be the remote phone.   Since it's a pvt IP the carrier can't route it.

I'm thinking it's the firewalls ALG would correct that if it was NATing for that subnet.   But it isn't.   The firewall at the remote site NATs that subnet so the ALG never corrects the packet.

Ralph
Title: Re: One Way Audio
Post by: brantn on September 01, 2011, 09:41:44 AM
I am not sure on fortinet firewalls but typically a lot have sip transformation settings that get missed I would check if there are any. You should never send your private ip as the primary contact, which tells me your firewall is not truely sip aware. In a sip aware or a sip transformation firewall a header will show the private ip via the ITSP ip that way the carrier sends it on to the firewall and then it is stripped and carried to the private side.
Title: Re: One Way Audio
Post by: ralph on September 02, 2011, 10:27:14 AM
Unfortunately we don't have access to any thing firewall related.  Have to work through 3rd party.
I have 40+ hours into this now so have impose a solution.
Switching to PRIs.   Already had licenses just no hardware.
This will solve my little problem.

Now to catch up on the rest of my work.

Ralph
Title: Re: One Way Audio
Post by: brantn on September 02, 2011, 11:48:49 AM
Bummer so much more money saved with SIP and 40 hours isn't anything compared to SIP hours I have put in :) Nice thing with a Mitel there is always another way.
Title: Re: One Way Audio
Post by: ralph on September 02, 2011, 12:09:05 PM
Actually, as far as cost go, no additional cost to the customer.  Rates remain the same.
Just our cost for the PRI mods.  We'll have to eat those.

Ralph
Title: Re: One Way Audio
Post by: brantn on September 02, 2011, 01:45:08 PM
Cool our PRIs are almost double sip trunk cost.