> On Tue, 2009-06-09 at 20:39 -0400, Robert Joly wrote: > > This could easily be achieved by adding some logic in the > > sipXregistrar that would take out any of our X-sipX-prefixed > > proprietary headers from the 200 OK sent in response to a > successful > > binding. This would have the advantage of making our Contact > > standards-compliant again; fix the twinkle interop and not > affect all > > the other phones that work fine today. Can you foresee any > downside > > to that approach? > > Of course, the problem is not the presence of > "x-sipX-privcontact=192.168.10.10%3A6050" (the URI comparison > rules allow that), it's that the host has been changed from > 192.168.10.10:6050 to 98.229.117.164:6050.
Right, thanks for the precision. I do have one question about the SipRegistrarServer that you probably can answer. Right now, I see that a valid REGISTER request is processed like this: 1- Save the Contact information in the database; 2- If the registration is successful or is a query, recall the Contact information from the database and decorate it with expires, gruu, instance-id, ..., as returned by the database query; 3- replace the Contact information in the 200 Ok to-be-sent with the Contact constructed in #2. The problem I have is with step #2 which prevents me from providing a very simple solution to the problem being raised in the thread. In the case of successful registrations, what would prevent us from using the Contact in 200 OK and decorating it with expires, gruu and instance-id taken from the database. The difference is that the current approach build a new Contact from the content of the database and overwrites the one in 200 OK whereas the second approach builds the new Contact around the existing 200 OK contact which ensures that the comparison-relevant elements of the contact get preserved. If the latter approach was taken in the code then the problem discussed in this thread would be simpler to address. Can you think of any gotchas with the second approach? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
