> > On Tue, 2009-06-09 at 20:39 -0400, Joly, Robert (CAR:9D30) wrote: > > > > Thanks for taking the time to analyze this thoroughly. It > is pretty > > clear from your explanation that the Contact header we generate is > > non-standard. Given that the phones we officially support seem to > > cope with our non-standard header, it is debatable whether > or not we > > want to fix it in the 4.0 branch - what were your plans around that? > > Not true, unfortunately - I've got my analyzer working again, > and am finding phones in the logs I've looked at that are not > picking up the refresh time correctly (Polycoms do work). > > > What is > > not debatable is the notion that we ought to fix this > problem at some > > point in time. Rather than adding an Expires header whose > effects are > > unknown, what about taking an approach that would > 're-standardize' our > > Contact header. 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? > > First, I don't think those need be mutually exclusive > approaches. I've posted my patch at > http://code.sipfoundry.org/cru/XECS-22 . > > I'm not sure I understand your idea. Looking in the > sipregistrar log, the Contact in the REGISTER request has > already been modified when it is received. Are you > suggesting that we add a function to the registrar that > reverses the transform applied by the proxy before sending > back the response? An ideal solution would not modify the > Contact at all, but I realize that's a tall order.
The inverse transform is indeed what would be required. This may sound scary but this inverse transform is already done on every NATed calls on Request-URIs. This inverse transform is performed to make sure that the endpoint we send a request to will not see its sipX-annotated in the R-URI of the incoming request but the contact URI instead. Although not very clean, similar logic could be performed by the Registrar. Regarding your ideal solution, I need to spend more time thinking about it but the reason why sipXproxy is applying the transforms to the Contact of the REGISTER is so that the location information shows up in the regDB against the contact so that it can be used when the phone is being called. If we could deliver this location information to the registrar 'out-of-band' (i.e. through a private header instead of the contact) it could just append it to contact it stores in the RegDB - everything from that point on should be the same. Perhaps an even simpler approach would be for the sipXproxy to refrain from doing the Contact transform on REGISTER messages and let the sipXregistrar figure out the location information by inspecting the Vias the same way sipXproxy does it today and stick it on the RegDB without altering the Contact of the REGISTER. _______________________________________________ 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/
