Hi 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. Note, this is a slightly different call scenario due to some changes in my setup, but the problem is the same. The call is initiated from an incoming SIP trunk, forks to two phones behind NAT, one answers (200 OK) and the ACK is lost after SipXregistry does GRUU translation (correctly now!) /Staffan On 9 sep 2010, at 04.31, Martin Steinmann wrote: > Staffan > > New RPM attached with the third patch from Dale: > http://track.sipfoundry.org/secure/attachment/26634/sipxregistry-4.3.0-01902 > 2-patch3.sipxbuild.i386.rpm > > --martin > > >> -----Original Message----- >> From: Worley, Dale R (Dale) [mailto:[email protected]] >> Sent: Wednesday, September 08, 2010 6:21 PM >> To: Staffan Kerker; Martin Steinmann >> Cc: 'sipx-users' >> Subject: RE: [sipx-users] ACK misrouted in SipXProxy with Tandberg >> terminal >> >> ________________________________________ >> From: Staffan Kerker [[email protected]] >> >> Seems like a new minor issue happends after this patch is applied. The >> ACK is now lost in the sipxregistrar again. >> ________________________________________ >> >> Yes, the Registrar is not handling Route headers in ACKs directed >> toward GRUUs correctly. The attached patch should fix that. >> >> Interestingly, there is a whole class of ACKs that won't be handled >> correctly: If a device adds a Record-Route containing its AOR (rather >> than its contact address). >> >> Handling these cases would probably be easier if we modified the Proxy >> to respond to 3xx responses to ACKs rather than having the Registrar >> forward ACKs directly. >> >> Dale > -- Staffan Kerker mail/sip/xmpp: [email protected] "There is absolutely no money above the 5th fret..." /Donald "Duck" Dunn _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
