SIP Phone Issue: Recieved Parameter in Via Header

I'll be shocked if anyone can help me with this, but I've been working on it for over a month and am no closer to a solution now then when I started!

Here's the deal: we have a MITEL 3300 PBX that we use for VoIP communication at our company.  We've been experimenting with Softphones, specifically with Counterpath's Bria 3, and have had great success inside the network.  Outside, however, has been a different story.  I put NAT rules/ACLs in place to allow inbound traffic to be routed to/from our MITEL PBX, and at first it seemed like it would work great (first connection from the outside did just fine).  Later, however,we found most people couldn't connect from their homes/hotels/etc.

More research turned up that some routers have built in SIP Application Layer Gateways, which rewrite the SIP packets in some magical way that allows them to connect.  Every router we've used that doesn't have a built-in ALG fails.  After comarping Ethereal packet traces, I've determined that the only difference between a succesful connection and a failed one is that succesful SIP packets do not contain the 'received=outside IP' parameter in the Via header while failed packets do.

What can I do, either in Bria, my Cisco ASA, or to my MITEL 3300 ICP that will allow this blasted softphone to connect from regular routers?  Is this software just doomed to fail unless I'm passing through a special ALG enabled router?

Before anyone suggests: Yes, I have tried using  It doesn't work.

Thanks in advance!!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Well, with the ASA, the only way to allow an internal soft phone to register with an external SIP host is to turn on the "Inspect SIP" within the Class inspection.    This inspection will re-write the packets so that the phones can connect without a STUN service.  

Regular "consumer" routers don't have this type of feature so a STUN service is usually required.   The whole issue lies with the routers NATing the UDP packets for outbound traffic.   The STUN service would allow the SIP signalling and RTP to traverse NAT.
mhentrichAuthor Commented:
That's interesting...let me ask you a couple more Q's then:

First up, since I'm trying to connect externally to an internally located PBX, would enabling the Inspect SIP feature help at all?  I *do* receive a single reply from our PBX (100 Trying), which implies that maybe rewriting the packets on the way out might help?

Second, I've done some digging, and I can't find any good resources on how to setup a STUN server, or employ an existing STUN service.  What do I have to do to get ahold of something like that?  Counterpath (makers of Bria 3) offer a STUN server (, but like I said earlier, it's not helped thus far.

Matt, the issue you have is a common one. The problem is that SIP headers pass the address and port values used. If the agent is behind your usual home firewall, the address will be private and not internet routable and while a connection out will have the address translated to the firewall WAN address, the port will be translated dynamically to something else. SIP aware firewalls fix this by changing the headers with the WAN address/ports, open up the firewall for the ports used and handle the port translations.

You can address the issue by fixing things at the client end.

In the Bria 3 SIP Account, Topology tab
1. Select Firewall Traversal method to be Discover public IP address (STUN) - the STUN server returns the connecting address it sees and the agent uses this for SIP traffic.
2. Select Range of ports used on local computer. Use a start port of something like 8000 and end port 8013 - this allows a pair for signalling (though it may only use one port) and a pair (one port for streaming, the other for control) for each of up to 6 calls.

On the client firewall you need to configure port forwarding for the port range used above to the agent IP address. The firewall access should allow the agent address to connect out to all and allow all to connect in using the port range forwarded.

That's it!

Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

mhentrichAuthor Commented:

Thanks for your input!  I'll try these suggestions out when I get home (have to leave my place of work to test this problem) today.  Quick Q, however: you said to change my firewall traversal method to STUN, but didn't say anything about entering a STUN server.  What STUN server should I use?  Or can I leave that blank?

You need an STUN entry here. Try Counterpath's:
Frabble Seems to be familiar with that Bria Service.    

I'll just finish up my earlier comments about the ASA by saying that class-inpspection for SIP is enabled by default and would usually be left in that state except under very specific conditions.  
mhentrichAuthor Commented:

Very glad to have your input thus far.  Unfortunately, no luck on any of your suggestions to this point.  Here's what I've observed:

1. The ASA didn't indeed have SIP inspection enabled.  I played with some of the settings, but in the end left it at the default.

2. I've tried dozens of STUN servers, no luck.  I've set my ports to 8000-8013, and setup port forwarding on my local router.  Here's what happens packet-wise:  First, I send a binding request immediately followed by a binding response.  As far as I can tell, that part goes smoothly.  Immediately after, however, I send my registration request, followed by the 100 Trying message, but I never get passed that.

I have to reemphasize: whether employing STUN, ICE, Local IP, Port Forwarding, or any range of available ports, I always see the same thing in the packet traces.  From my local router, the Via Header in the SIP packet reads:
 Via: SIP/2.0/UDP;received=;branch=z9hG4bK-d8754z-f2e503cc32aee998-1---d8754z-;rport

However, when I connect from another network (one with a built in ALG), it reads:
Via: SIP/2.0/UDP;branch=z9hG4bK-d8754z-cfbd0a1c4516f3e1-1---d8754z-;rport

This is the only difference I can discern between packets sent from my network and packets sent from another (working) network.  For reference, I've attached the binding response packet from my failed attempt to use

Any thoughts?  I throw myself at the mercy of the experts!!

Matt BindingResponse.txt
mhentrichAuthor Commented:
Anybody?  No more ideas?
Is the BindingResponse content been changed in anyway to perhaps mask addresses?
The MAPPED-ADDRESS should be the public address the server sees the binding request come, somehow this is the client address
The SOURCE-ADDRESS should be the actual client address, this is another private address

Looking at SIP message, the client is registering with it's actual address from

From the above, is the client address, is the WAN address? and where does come from?
mhentrichAuthor Commented:

Correct, is my computer's local address (assigned by my router), and is my external IP address (assigned by my ISP).  As for, I have no idea what that is.  I see it listed as a Source Address in the Binding Response, but don't know where the STUN server is getting that from.

I've been doing some correspondence with Counterpath, here's what they've been saying.  First, regarding what we tried earlier:

'You have enabled STUN as well as, under the Topology settings, manually specifing a UDP port range (8000-8013). That is *not* going to work. Either use the STUN server - "Discover public IP address(STUN), and let Bria dynamically allocate and map the UDP ports, or specify the port range (eg 5060-5080) and open those UDP ports on your NAT/firewall, and select "None(use local IP address)" for the firewall traversal method.'

I tried all of these variations, nada.  Here's what they sent me today:

'Most NAT devices used in homes are non-symmetric, but if your's is a symmetric NAT, then STUN will not work. You may then want to explore other options, such as using a different router that has a non-symmetric NAT, or open a range of UDP ports on the NAT/router, and set Bria to use those ports.'

That's non-sensical in my opinion.  I have tried to connect from dozen of places, and it *rarely* works...really, only connections from behind a few, special routers take, with or without STUN.  Actually, STUN has never helped, it either connects via ICE or not at all.  And there is *no* port blocking on my router, I've setup port forwarding several times to no avail.

As always, I truly appreciate your assistance...any expertise you might be able to lend would be grealty appreciated!!

mhentrichAuthor Commented:
I had some very small, measured success by making use of a couple of free SIP proxy services:


I thought the latter was interesting because if I put in or (advertised on their website), the connection failed.  But when I put in :80, it connected instantly.

These services have allowed me to register to the PBX, and the PBX reflects my registration and shows my phone as being online.  If I set Bria's Signaling Transport to UDP only, I'm *almost* able to do things I need to do.  For instance:

- If someone calls me, Bria rings on my end.  I can click answer, but the other party just still hears the phone ringing.  I can also then click end, but their phone will still keep ringing.

- If I call someone internally (in my company), the call times out (408 Timeout).

- If I call someone externally (like a cell phone), the call will go through but when they answer, neither of us can hear each other.  However, hanging up in this situation does end the call on both ends.

If Signaling Transport is set to TCP or Automatic, I don't even get this much success.  I've attached a few ethereal/wireshark packet captures for reference.  I still am hoping someone can help me out!!

Matt RegisterViaProxy AttemptCallInternal AttemptCallExternal InboundCallAttemptToAnswer
Hi Matt, could you persist with direct client connections a bit more.
The fixed port range on the agent and forwarding the same port range and allowing them in and out of the firewall removes any port translations and restrictions. The problem I see you have is the agent registering with its private address.

In your binding response trace, the MAPPED-ADDRESS (as seen by the server) should be a public address and not the agent private address shown. Incidently, the SOURCE-ADDRESS is the source address of the server so it would seem that Counterpath have the STUN server on the 10 range and NAT to the outside.
It appears that some routers may modify the mapped address value. The easiest way to check if this is happening is to look at the XOR-MAPPED-ADDRESS value - the Wireshark decode will give the actual address and this should be the public address.
mhentrichAuthor Commented:

Thanks again for all your help, I think I've resigned myself to the fact that STUN will not help me here.  The Counterpath and MITEL folks have stated pretty clearly that STUN will not work with bidirectional NAT, which most folks use in their home routers.

What I'm actively looking into now is a hardware device that my MITEL rep suggested: the Ingate SIParator 19.  Do you (or does anyone out there) know anything about this device?

Hmm, well if they say so then it must be right.
Can't help you with the SIParator but the specs say it has a SIP proxy so that should enable you to fix the issue with private addresses. Good luck.
mhentrichAuthor Commented:
Thanks all.  FYI to anyone interested, I decided to (at least temporarily) go the route of using softphones over VPN.  It's actually worked fairly well in my first few tests.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ernie BeekExpertCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Voice Over IP

From novice to tech pro — start learning today.