________________________________________ From: Staffan Kerker [[email protected]]
The sipXregistrar now seems to do the right stuff, but now it looks to me as if the sipXproxy is messing up the Request-URI and not using the correct one (public IP address) that is received from sipXregistry. I've uploaded a new trace and a new snapshot to the tracker: http://track.sipfoundry.org/secure/attachment/26638/sipx-snapshot-sipx.kerker.se-patch3-applied.tar.gz http://track.sipfoundry.org/secure/attachment/26639/tandberg-GRUU-ACK-misouted-patch3-applied.xml Looking at the trace file, frame 33 show the now correctly resolved ACK sent back from the patched sipXregistry, but frame 34 now shows the SipXproxy trying to send the ACK of to the internal IP address (192.168.0.116) shown in "x-sipX-privcontact" and not the public IP of the NAT outside, as recieved by SipXregistry Request-URI. ________________________________________ I now have time to look into this. It looks like this is a problem with the remote NAT traversal feature. It's possible that it isn't specific to GRUU processing. I will talk to our expert on NAT Traversal. There is one other problem. I don't think it is causing a malfunction in this situation, but it might in other situations. The Tandberg is being given <sip:[email protected];gr> as its GRUU, but it is using <sip:[email protected];gr;transport=tcp> as its Contact. (Server: TANDBERG/257 (TE2.2.0.215697)) It should not be doing that; UAs must treat GRUUs opaquely. Dale _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
