Sorry to be so late getting back to you on this, but I've been out of town for two weeks.
On Mon, 2008-11-17 at 09:10 -0500, Joly, Robert (CAR:9D30) wrote: > > 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;" I've looked at section 4.4 now, and clearly it covers phone calls and subscriptions from the phone to sipX. But subscriptions *from* sipX *to* the phone don't seem to be listed (on page 50, at the beginning of section 4.4). Am I overlooking something? > 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. Oddly, GRUU can provide some benefit even if the phone in question does not support GRUU: The registrar assigns a GRUU to any registration that presents an instance ID, even if the phone doesn't support GRUU. (There are some uses for instance IDs outside of GRUU production.) Since the proxy/registrar route requests addressed to the GRUU to the contact URI of the phone, the phone will receive the requests. The GRUU itself can be seen in the registration event package for the phone's registration. Though that case is not likely to happen in practice. 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
