cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
468
Views
0
Helpful
6
Replies

nat - one way audio

craigcurtis
Level 1
Level 1

here we go:

phone ip: y.y.3.182

one-to-one nat to: y.y.77.182

cm: x.x.x.3

Phone will connect to the call manager. it shows up connected in the cm with the ip address of y.y.3.182

Phone can call and be called but the return audio never arrives to the phone. I can here them, they cannot hear me.

I guess one question is, if the cm thinks it is at y.y.3.182, why can I call it? how does it know where to find the phone to ring it?

Any help would be greatly appreciated.

6 Replies 6

adignan
Level 8
Level 8

Actually no. this is a phone that we are trying to make work at a remote location. I wanted to add that I can ping the nat address from the call manager.

Obviously the RTP stream is being blocked or lost coming into the phone. What device is the phone calling; another IP Phone, a voice gateway, or both? You mentioned "one-to-one" NAT. Do you mean that you have a static NAT mapping or simply that you aren't using the overload command to turn NAT into PAT?

Connectivity is there; at least on most ports. That is why the phone can register and you can ping it. However, the high-end udp port that RTP uses is not getting mapped inside. Can you snip out the NAT config from the router and post it? I'd be interested in seeing that.

I think it is being stoped at the checkpoint firewall. it is a checkpoint firewall that is doing the static nat mapping of the phone.

The weird thing to me is that I can call the phone. if the callmanager has the ip address of the inside nat # why can I even call it? if the stream was sent to the outside nat number and then translated to the inside # i would think it would work.

2 possible reasons why you can receive a call, but not recieve audio. The first is simple ports. Call control is established from the CCM using SCCP, which uses TCP port 2000. The RTP stream uses (correct me if I'm wrong here) a random UDP port up in the 16000. That's why voice through a NAT requires special attention.

The other reason is because to receive a call, the phone must be reachable, and must be able to reach, the CallManager. However, CallManager only facilitates the call setup. The voice path, the actual RTP stream travels directly from one phone or gateway to the other phone or gateway. And being RTP, a connectionless protocol, no error is generated if one of the end devices cannot reach the other, so long as both can reach, and be reached by, the CallManager.

RON ROYSTON
Level 1
Level 1

The problem is not with the firewall, it's with the NAT process. If you had a PIX firewall, you could use an "application level gateway" feature called "fixup protocol". This would fix the IP addressing in the Skinny setup messages. I don't think Checkpoint has support for SCCP NAT fixup. You'll have to get them a 3002 hardware client at the remote site and dial it into your IOS box or PIX at the core. This is plug and play and will work fine.

Hope that helps.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: