>>> "Matthew Kitchin (public/usenet)" <[email protected]>only >>> route, or does it NAT? I would suspect its actually NATing a >>> 172.x.x.x IP to the 10.83 side if your changing the port. </[email protected]><[email protected]> 01/27/11 2:02 PM >>> >>On 1/27/2011 12:53 PM, Matt White wrote: It is not NATing the IP. Their subnet has direct (routed) access to ours. The router sits between these 2 subnets and in this case only translates the port. Not the IP. It is a Verizon DS3, and we have 100 MPLS sites coming in >>through it. Also, in case it is relevant, I have to put 'some' info on the NAT setting under servers in the sipx gui. I don;t use STUN, so I change it to Specify an IP and I have to put something in. It was trial and error 1.5 years ago when we started this. I put in the IP for the >>Verizon gateway we send our calls. I know that isn't correct, but I have to put some value in. I'm not sure if that is relevant. The only other setting we change is 'Use public address for call setup' under Gateway, ITSP account. We have to uncheck that box.
Interesting. I'm surely not a CCIE, but port translation always requires natting at least on a cisco. Even if your just trying to change the outbound port it requires the "ip nat" command. If under "servers"..."NAT" and then public IP address you have put the ip address of the verizon sip proxy...that would certainly be wrong. This needs to be the IP address that sipxbridge receives sip on...whether its NATTED public ip or its private ip...either way its the ip that sipx will get traffic on and tell others where to send traffic destined for itself. Change from port 5060 to 5080 using PAT/NAT does work. We have many many installs using this method for carriers that must send to port 5060. But I suspect your setup is stuck somewhere between thinking its natted and not being natted. You should pick one and commit to it. The trace shows the phone send directly to sipxbridge and it shouldn't. When the codec doesn't change it looks like sipxbridge balks becuase it didn't come form the proxy, but then accepts it because the RTP stream is already open. This doesn't work when the codec has to change. But if the real issue isn't fixed...this will always be an unreliable setup because your breaking the rules of sipx by sending around the sipxproxy. -M </[email protected]>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
