> > 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.
On Tue, 2009-06-09 at 21:44 -0400, Joly, Robert (CAR:9D30) wrote: > 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. If you've already got the reverse transform code in the proxy, wouldn't it be cleaner to just spot REGISTER responses and apply the transform to the Contact headers in the response? > 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. I like the idea of having the proxy add a private header that is then combined in the registrar to populate the registration database. I'm less comfortable with parsing Vias. _______________________________________________ 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/
