03-18-2004 10:57 AM - edited 03-13-2019 04:20 AM
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.
03-18-2004 11:19 AM
I am assuming you are talking softphone....
03-18-2004 12:11 PM
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.
03-18-2004 12:55 PM
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.
03-18-2004 03:54 PM
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.
03-22-2004 12:05 PM
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.
03-23-2004 06:53 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide