[sipcore] SIP-push -- Where is the "proxy"?

[[e-mail] (Dale R. Worley)]

Looking at the first paragraphs of section 5.3.2, it says:

   When the proxy receives (or, in case the proxy is the registrar,
   creates) a SIP request for a new dialog (e.g., a SIP INVITE request)
   or a stand-alone SIP request (e.g., a SIP MESSAGE request) addressed
   towards a SIP UA, if the Request-URI of the request contains a pn-
   provider, a pn-prid and a pn-param (if required for the specific PNS
   provider) SIP URI parameter, the proxy requests a push notification
   towards the UA, using the PRID included in the pn-prid SIP URI
   parameter and the PNS identified by the pn-provider SIP URI
   parameter.

The implication is that the proxy may not have access to the AOR to
which the request was originally directed, only the contact URI.

However, the next paragraph says:

   The push notification will trigger the UA to send a re-registration
   REGISTER request.  The proxy will process the REGISTER request and
   the associated response as described in Section 5.3.1.

That requires that no matter where in the network the UA is, its
REGISTER request will reach the proxy.

These two situations don't seem to be consistent -- the second one
requires that the proxy be centrally placed so that it will receive any
REGISTER, but the first envisions that the proxy may be distant from the
redirector (and hence the registrar), and only have access to the
information in the incoming request itself.

I'm not sure what network architecture possibilities you're envisioning,
so I can't see what the resolution of this is.  One possibility is that
the proxy really will be central, but in that case, it has the freedom
to know the full registration record of the AOR, which might let us
clean up some things.

The other possibility is that distributed operation is supported.  I
think that could be accommodated with minor changes to get around the
fact that the proxy may not see the re-REGISTER request:  Add the
requirement that the contact URI includes a pn-aor parameter whose value
is the AOR being registered.  With that restriction, when the proxy
receives the incoming request (after redirection), it can subscribe to
'reg' events for the original AOR (extracted from the pn-aor parameter).
As long as the 'reg' events include the optional 'cseq' attribute of the
<contact> element, the proxy will be notified when the reregistration is
processed, and from that it can extract the (possibly changed) contact
address from the registration and forward the request.

Dale