One Way Audio

[ralph]

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

[brantn]

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.

[ralph]

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

[brantn]

QSIG Diversion Enabled? Trunk to Trunk? Simulated CCM before ISDN Progress? Third should make a dent in the issue as it changes call signaling.

[ralph]

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

[brantn]

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?

[ralph]

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

[MitelAvayaNortel]

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?

[brantn]

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?

[brantn]

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?

[ralph]

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

[brantn]

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.

[ralph]

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

[brantn]

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.

[ralph]

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