Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started 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
-
just thinking out loud
I would think you need to setup your sip device to use the 3300 as the proxy.
Tom
-
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?
-
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
-
Try changing avoid signalling hold to Peer and let me know.
-
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
-
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.
-
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
-
Hi Ralph, what version of software are you running on this 3300?
-
10.2.2.10
-
Avoid Signaling Hold to the Peer Set to Yes
Enable Mitel Proprietary SDP Set to No
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
QSIG Diversion Enabled? Trunk to Trunk? Simulated CCM before ISDN Progress? Third should make a dent in the issue as it changes call signaling.
-
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
-
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?
-
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
-
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?
-
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?
-
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?
-
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
-
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.
-
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
-
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.
-
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
-
Cool our PRIs are almost double sip trunk cost.