SIP Phone Issue: Recieved Parameter in Via Header

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.

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 (stun.counterpath.com), but like I said earlier, it's not helped thus far.

Thanks!
Matt

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!

Frabble,

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?

Thanks!
Matt

You need an STUN entry here. Try Counterpath's:
stun.counterpath.net

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.  

Frabble/Mike:

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 192.168.2.2:8000;received=173.31.241.251;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 10.0.0.14:8000;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 stun.counterpath.net.

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

Thanks,
Matt BindingResponse.txt

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 10.252.131.113

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

From the above, 192.168.2.2 is the client address, 173.31.241.251 is the WAN address? and where does 10.252.131.113 come from?

Frabble,

Correct, 192.168.2.2 is my computer's local address (assigned by my router), and 173.31.241.251 is my external IP address (assigned by my ISP).  As for 10.252.131.113, 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!!

Thanks,
Matt

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

- proxy01.sipphone.com
- p.sippp.com:80

I thought the latter was interesting because if I put in p.sippp.com or p.sippp.com:56 (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!!

Thanks,
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.

Frabble,

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?

Thanks!
Matt

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.

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.