On 1/27/2011 1:22 PM, Matt White wrote:
>>> "Matthew Kitchin (public/usenet)" 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.
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.
I just grabbed my network engineer.We are doing port mapping, no NAT. It
is using the IP NAT command, but not changing the IP. Just the port.
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.
I just tried putting in the local IP on servers, NAT and the hold issues
with 3.2.1B behaves the same.
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.
With the exception of the port translation, we are not natting, so I
will be glad to commit to no natting.
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.
I definitely would like to fix the real issue. Is there anymore detail I
can look at that would explain what is making the phone contact sipxbridge?
-M
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
