On Wed, 2009-06-10 at 13:43 -0400, Joly, Robert (CAR:9D30) wrote: > 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.
I haven't studied this very carefully, but I can think of two questions: - There might be some weird special cases where it would make a difference. The one case I can think of is a REGISTER that provides one contact with expires=0 (thus deregistering it) and another contact with non-zero expires. In theory, the 200 should contain only the second contact. - More significantly, I'm not sure how much the new approach would change things. If step 1 copies the Contact URIs into the IMDB, and step 2 copies the IMDB values into the Contact headers, the new Contact headers will be very much like the original Contact headers. I think the theory is that the URI parts (strictly speaking) of the Contact values will be sent to the IMDB and be fetched from the IMDB without change. (Is there NAT Traversal processing in steps 1 or 2? That could change things.) Dale _______________________________________________ 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/
