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). 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. 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. 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
