> This issue concerns the RLS making dialog event subscriptions > to the contact address of a phone that is behind a remote > NAT. There are two > problems: Establishing the subscription, and maintaining it. > > Since the SUBSCRIBE has to go to the phone inward through the > remote NAT, it must be sent from the proxy that handled the > most recent REGISTER from the phone, and have > NAT-compensation parameters on the Contact to specify the > external address of the NAT. The RLS obtains the contact > address from the 'reg' event package for the AOR, and since > that includes the recorded contact URI, it contains the > NAT-compensation parameters. But the 'reg' event package > does not contain the "service path", which is what is to be > put in the Route headers of an initial request. (In this > case, the URI of the proxy that handled the most recent > registration, and is keeping the NAT pinhole open.) > > At first glance, we could add an extension to the 'reg' event > package to carry the service path. But I think that the > IETF-preferred method is to support GRUU, so that the RLS can > extract the GRUU of the contact from the 'reg' event package. > Requests sent to the GRUU are forwarded by the proxy via the > registered service path to the registered contact address. > > Adding GRUU support is probably no more difficult than adding > a new element to the 'reg' event package and changing the RLS > to use that element (especially since most of GRUU support is > already written).
Don't we need phone support for GRUU? AFAIK, the proxy and registrar cannot provide GRUU on behalf of phones that do not support it. > > There is an additional problem with maintaining > subscriptions, namely that re-SUBSCRIBEs need to continue to > enter the NAT through the pinhole. However, the pinhole will > change over time, as its external destination will be the > proxy which handled the most recent registration. > > This seems to present insuperable difficulties -- the route > set has to change with time. I think that the problem you raise has already been addressed in the current NAT traversal design. From section 4.4 of the NAT traversal design doc: "[NAT Maintainer will maintain pinhole for] REMOTE_NATED endpoints that have active subscriptions on the sipXecs: sipXecs will need to send NOTIFY messages to these endpoints' public IP:port therefore requiring the pinhole to be open;" BTW, I noticed that this document and other NAT-related docs only exist in the merge-proxy branch. Is that intentional? > But I think there is a way out: > If the RLS addresses its initial SUBSCRIBE to a GRUU for the > phone, and the phone uses its GRUU as its contact, then there > are no route-set URIs for the subscription from the RLS's > point of view -- it always sends re-SUBSCRIBEs directly to > the GRUU, and the proxies process and route each request > correctly by looking up the correct routing at the time each > request is made. > > BTW, the same problem seems to arise for phone calls -- > during a call, the correct route to the phone can change. > Without using a GRUU "dynamically", there doesn't seem to be > any solution. I think that the problem you raise has already been addressed in the current NAT traversal design. From section 4.4 of the NAT traversal design doc: "[NAT Maintainer will maintain pinhole for] REMOTE_NATED endpoints that are involved in a call: While on a call, an endpoint behind a remote NAT may be the recipient of in-dialog requests which will be sent to their public IP:Port therefore requiring the pinhole to be open." > > 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 > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
