Subject: [sipcore] Allowing "far" proxies in sip-push

From: [email-masked] (Dale R. Worley)
Date: Tue, 20 Mar 2018 23:05:38 -0400

I'm thinking that with a few extensions to the current scheme, we
could enable sip-push to support "far" proxies, that is, proxies that
do not have a close connection to the registrar/redirector of the SIP
domain, proxies that (1) cannot be assured of seeing all
reregistrations for the AOR, and (2) have no non-standardized way of
accessing the registrar.

I see supporting "far" proxies quite desirable not only because it
broadens the architectures that we support, but also because if "far"
proxies are used, the pn-* information *must* be communicated from the
UA to the registrar and hence to the implementing proxy using URI
parameters of the contact URI -- because that is the only available
data path.  Without supporting "far" proxies, it is equally easy to
use header parameters on the Contact headers of the REGISTER request,
and it is an architecturally cleaner use of SIP.  Thus, demanding to
support "far" proxies alleviates my most persistent objection to the
current scheme.

This approach seems to be upward-compatible with the current scheme, as
an implementation of the current scheme only needs to be changed by
adding generation of the pn-aor parameter in registered contact URIs.

What I have NOT yet done is see whether this paradigm supports the
architectures that Roman has recently mentioned.  I anticipate doing
that as a reality check.

There is a requirement that there be only one registration for a given
AOR with particular values of pn-provider/pn-prid/pn-parameter.  So a
UA can use one PNS subscription for registrations to several AORs,
but two different UAs (presumably on the same device) can't use the
same PNS subscription when registering to the same AOR.  This is, I
think, a little looser than the current scheme, which requires that
pn-provider/pn-prid/pn-parameter be unique for every registration.

The updated behaviors are:

When the UA registers, it attaches to the contact URI not only
pn-provider/pn-prid/pn-parameter but also pn-aor, which contains the
userinfo and hostport parts of the AOR being registered.  (E.g.,
"[email-masked]", which is the AOR with the URI scheme omitted,
encoded as "1234%40example.com', because "@" is not allowed in URI
parameters.)

When the proxy receives an incoming request (whose request URI
contains pn-provider and pn-prid), then it must (with certain
exceptions) trigger a push notification (using pn-provider, pn-prid,
and pn-param).  Then it must monitor the status of the registration
for the AOR listed in the pn-aor parameter that has the values of
pn-provider/pn-prid/pn-parameter, waiting for a reregistration with
those properties.  It can do this by any method it chooses, including:

- Due to the network architecture, it is assured that it is in the
  path of any such re-REGISTER, and can monitor responses to such
  REGISTERs.

- It can subscribe to 'reg' events for the AOR, waiting for increase in
  the 'cseq' attribute of the appropriate 'contact' element.

When the proxy determines that a reregistration has been done, if the
contact URI of the registration is the same as the request URI of the
pending request, it must forward the request based on that URI.  If a
reregistration has been done but the contact URI of the registration
is now different than the request URI of the pending request, the
proxy MAY reject the request with a 404 response, or it MAY redirect
the request to the new contact URI.  If no reregistration is done, the
proxy MUST reject the request with a 404 response.

This updates the example in section 1 to:

     REGISTER sip:[email-masked] SIP/2.0
     Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
     Max-Forwards: 70
     To: Alice <sip:[email-masked]>
     From: Alice <sip:[email-masked]>;tag=456248
     Call-ID: 843817637684230@998sdasdh09
     CSeq: 1826 REGISTER
     Contact: <sip:[email-masked];
       pn-provider=acme;
       pn-param=acme-param;
       pn-prid=ZTY4ZDJlMzODE1NmUgKi0K;
       pn-aor=alice%40example.com>
     Expires: 7200
     Content-Length: 0

It would be helpful if the 'contact' element of 'reg' events (RFC
3680) was extended with an optional attribute 'last-reg', which is the
number of seconds since the contact was last updated.  This allows a
subscriber to directly determine that the UA is awake (due to having
recently enough sent a re-REGISTER) and implement

   If the proxy has knowledge that the UA is awake, and that the UA is
   able to receive the SIP request without first sending a REGISTER
   request, the proxy MAY choose to not request a push notification
   towards the UA (and wait for the associated REGISTER request and 2xx
   response) before it tries to forward the SIP request towards the UA.

This is particularly useful if the proxy has seen a reregistration
with a different contact URI and has forwarded the request to a second
implementing proxy.  If the second proxy subscribes to 'reg' events
for the pn-aor, it could tell from the 'last-reg' attribute that the
UA is still awake and could skip sending another PNS request to the
UA before forwarding the request to the UA.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Mar 2018 16:40:42 +0000

Hi,

I am not aware of any case where the proxy (no matter whether it is "far" or "near") would not receive the REGISTER/re-REGISTER requests. 

Also, in your "Due to the network architecture..." sentence you seem to imply that the proxy would not receive the initial REGISTER (which is the reason pn-aor is needed), but it could receive the re-REGISTER requests. I have never heard about such use-case.

Also, if the proxy does not receive the re-REGISTER request, there may be NAT issues when the proxy is trying to forward the request (since there is no re-REGISTER, Outbound keep-alive etc opening the pin hole).

Also, any proxy (no matter whether it is "far" or "near") can use the 'reg' event package in order to figure out the status of a registration.

But, if we want to cover your proxy-out-of-path scenario, we can do that in a separate draft (similar to the Outbound case). Because, based on the text above, I think it requires a little more thinking than simply defining a new pn-aor parameter. As I said when this work started, there is an industry need for a solution now, the window for providing a standard solution is narrow, and the assumptions in the current version of the draft meet need.

Regards,

Christer

> I'm thinking that with a few extensions to the current scheme, we could enable sip-push to support "far" proxies, that is, proxies
> that do not have a close connection to the registrar/redirector of the SIP domain, proxies that (1) cannot be assured of seeing all
> reregistrations for the AOR, and (2) have no non-standardized way of accessing the registrar.
>
> I see supporting "far" proxies quite desirable not only because it broadens the architectures that we support, but also because if "far"
> proxies are used, the pn-* information *must* be communicated from the UA to the registrar and hence to the implementing proxy 
> using URI parameters of the contact URI -- because that is the only available data path.  Without supporting "far" proxies, it is equally 
> easy to use header parameters on the Contact headers of the REGISTER request, and it is an architecturally cleaner use of SIP.  Thus, 
> demanding to support "far" proxies alleviates my most persistent objection to the current scheme.
>
> This approach seems to be upward-compatible with the current scheme, as an implementation of the current scheme only needs to
> be changed by adding generation of the pn-aor parameter in registered contact URIs.
>
> What I have NOT yet done is see whether this paradigm supports the architectures that Roman has recently mentioned.  
> I anticipate doing that as a reality check.
>
> There is a requirement that there be only one registration for a given AOR with particular values of 
> pn-provider/pn-prid/pn-parameter.  So a UA can use one PNS subscription for registrations to several 
> AORs, but two different UAs (presumably on the same device) can't use the same PNS subscription when 
> registering to the same AOR.  This is, I think, a little looser than the current scheme, which requires that 
> When the UA registers, it attaches to the contact URI not only pn-provider/pn-prid/pn-parameter but 
> also pn-aor, which contains the userinfo and hostport parts of the AOR being registered. 
> (E.g., "[email-masked]", which is the AOR with the URI scheme omitted, encoded as 
> "1234%40example.com', because "@" is not allowed in URI parameters.)
>
> When the proxy receives an incoming request (whose request URI contains pn-provider and pn-prid), then it must (with certain
> exceptions) trigger a push notification (using pn-provider, pn-prid, and pn-param).  Then it must monitor the status of the 
> registration for the AOR listed in the pn-aor parameter that has the values of pn-provider/pn-prid/pn-parameter, waiting for 
> a reregistration with those properties.  It can do this by any method it chooses, including:
>
>When the proxy determines that a reregistration has been done, if the contact URI of the registration is the same as
>the request URI of the pending request, it must forward the request based on that URI.  If a reregistration has been 
>done but the contact URI of the registration is now different than the request URI of the pending request, the proxy 
>MAY reject the request with a 404 response, or it MAY redirect the request to the new contact URI.  If no reregistration 
>is done, the proxy MUST reject the request with a 404 response.
>
> 3680) was extended with an optional attribute 'last-reg', which is the number 
> of seconds since the contact was last updated.  This allows a subscriber to directly 
> determine that the UA is awake (due to having recently enough sent a re-REGISTER) and implement
>
> This is particularly useful if the proxy has seen a reregistration with a different contact URI and has 
> forwarded the request to a second implementing proxy.  If the second proxy subscribes to 'reg' events 
> for the pn-aor, it could tell from the 'last-reg' attribute that the UA is still awake and could skip sending 
> another PNS request to the UA before forwarding the request to the UA.

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Roman Shpount <[email-masked]>
Date: Wed, 21 Mar 2018 17:49:10 -0400

Dale,

How does "far" proxy gets the request from registration server when new
dialog creating request is sent to the registrar (AOR)? How does
registration server knows it needs to send messages to edge proxy and not
to the UA Contact?

The standard way to do it is to use Path header which will cause
registration server to insert the Route header for edge proxy.
The "hack" to do this is for proxy to modify registration contact when
forwarding message to the registrar and replace it with proxy address with
some parameters.

What are you proposing here?

Regards,

_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 21 Mar 2018 23:26:39 -0400

> forwarding message to the registrar and replace it with proxy address with

True, the standard and general way to ensure that a proxy is on the path
for an intial request is for the registration to use a Path header.
However, it is also possible that the proxy is "naturally" on the path
from the SIP domain's redirector to the contact URI, that is, when the
redirector sends the request to the contact URI, it will pass through
the proxy.

I believe that this latter pattern is what is envisioned in the current
draft.  Indeed, the current draft seems to assume that every initial
request forwarded by the redirector will pass through the same proxy.

What makes the more general situation complicated is that when the UA
awakens, its re-registration may pass through a different edge proxy,
changing the Path of the registration.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 21 Mar 2018 23:34:06 -0400

Christer Holmberg <[email-masked]> writes:
[out of order]
> But, if we want to cover your proxy-out-of-path scenario, we can do
> that in a separate draft (similar to the Outbound case). Because,
> based on the text above, I think it requires a little more thinking
> than simply defining a new pn-aor parameter. As I said when this work
> started, there is an industry need for a solution now, the window for
> providing a standard solution is narrow, and the assumptions in the
> current version of the draft meet need.

I intensely dislike the scenario of "The industry needs a solution now,
and this is what the industry has implemented, and so we must approve
it."  This is a situation where the IETF cannot maintain quality control
over what it approves.

In this particular case, my opinion is that the use of URI-parameters is
architecturally undesirable.  (Compare that in RFC 5626, reg-id and
+sip.instance are header parameters.)  The *only* reason to make the URI
parameters is scenarios where the implementing proxy is far enough from
the registrar that the only information it has in the incoming request
is the contact URI.

> I am not aware of any case where the proxy (no matter whether it is
> "far" or "near") would not receive the REGISTER/re-REGISTER requests. 

OK, but I can easily construct such cases.

> Also, in your "Due to the network architecture..." sentence you seem
> to imply that the proxy would not receive the initial REGISTER (which
> is the reason pn-aor is needed), but it could receive the re-REGISTER
> requests. I have never heard about such use-case.

The proxy must have received a register at some time in the past, or
otherwise it would not be receiving the incoming request now.  But if
the proxy is any sort of "edge proxy", there's no reason to assume that
it must receive the re-REGISTER.

> Also, if the proxy does not receive the re-REGISTER request, there may
> be NAT issues when the proxy is trying to forward the request (since
> there is no re-REGISTER, Outbound keep-alive etc opening the pin
> hole).

Ah, but if the proxy knows that the re-REGISTER has happened, then the
NAT must have been taken care of.  In that case, it can forward the
request to the *new* contact URI.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Wed, 21 Mar 2018 23:36:54 -0400

> changing the Path of the registration.

I think this breaks SIP Outbound as well since I think it assumes that when
flow is recovered it is recovered on the same edge proxy.

I think we can mandate that the same edge proxy must be used for
re-registrations as a limitation for the SIP push draft.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2018 05:21:55 +0000

Hi,

> I intensely dislike the scenario of "The industry needs a solution now, and this is what the > industry has implemented, and so we must approve it."  This is a situation where the IETF > cannot maintain quality control over what it approves.

This is not what the industry has implemented yet - this is what we are trying to get the industry to implement, instead of all kind of different proprietary solutions that I have seen flying around.

My point is that this is not a new fancy feature that operators "may implement at some point in the future" - it is a feature that is needed now.

And, as you have said yourself, your suggested extension does not change the basic mechanism.
 
>In this particular case, my opinion is that the use of URI-parameters is architecturally >undesirable.  (Compare that in RFC 5626, reg-id and
>parameters is scenarios where the implementing proxy is far enough from the registrar >that the only information it has in the incoming request is the contact URI.

A proxy can be "far" from the registrar even if it receives the REGISTER/re-REGISTER requests. 

Even in your suggestion the proxy needs to be aware of the registration status. The only extra seems to be that the proxy does not receive all REGISTER/re-REGISTER requests.

> OK, but I can easily construct such cases.

That is why I am suggestion we write it down in a separate draft. I think there would be a need for call flows showing your scenario(s), you were talking about extending the 'reg' event package etc...

>The proxy must have received a register at some time in the past, or otherwise it would >not be receiving the incoming request now.  But if the proxy is any sort of "edge proxy", >there's no reason to assume that it must receive the re-REGISTER.

Even without push, I have never heard of about such scenarios. REGISTERs and re-REGISTERs always traverse the same path. Even with Outbound, REGISTERs/re-REGISTERs associated with a given flow traverse the same path.

> Ah, but if the proxy knows that the re-REGISTER has happened, then the NAT must have 
> been taken care of.  In that case, it can forward the request to the *new* contact URI.

Sure, but depending on the NAT that doesn't mean that requests from the proxy will be allowed through the binding - only request from the IP address of whoever received the re-REGISTER will.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 22 Mar 2018 07:18:49 -0400

Christer Holmberg <[email-masked]> writes:
> Also, any proxy (no matter whether it is "far" or "near") can use the
> 'reg' event package in order to figure out the status of a
> registration.

That's true in theory, but in the present scheme, the proxy doesn't know
the AOR to subscribe to in order to obtain the 'reg' events -- it only
has the contact URI, and there's no algorithm for deriving the AOR from
the contact URI.  Carrying the AOR to the implementing proxy is what the
pn-aor parameter is designed to do.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2018 12:44:20 +0000

Hi,

>That's true in theory, but in the present scheme, the proxy doesn't know the AOR to >subscribe to in order to obtain the 'reg' events -- it only has the contact URI, and there's >no algorithm for deriving the AOR from the contact URI.  Carrying the AOR to the >implementing proxy is what the pn-aor parameter is designed to do.

Doesn't the proxy get the AOR from the REGISTER request?

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 25 Mar 2018 16:27:22 -0400

> Doesn't the proxy get the AOR from the REGISTER request?

The point of the proxy subscribing to reg events is so that it isn't
required to see the re-REGISTER.  There are several cases for that.  The
most significant one is the first, enabling "far" proxy network
architectures.

1) One case is a "far" proxy, that is, far away from the registrar.  If
the UA is awakened, and sends a REGISTER to the registrar, the UA may be
attached to the network in a differnt location, and the "far" proxy may
not be on the path of the REGISTER request.

2) One case is a matter of design, when the proxy doesn't want to
examine the message traffic for REGISTER requests.  Instead, it can
subscribe to the appropriate reg events.

3) Another possibility is if we can update reg events to report
"last-reg", the length of time since the last registration.  If the
proxy subscribes to reg events for the correct AOR, it can determine if
the UA has recently re-registered, and if so, it can omit sending a
notification.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Mar 2018 07:52:16 +0000

Hi,

I suggest that the scenarios are described in a separate draft. It is not
only about defining a new pn- parameter - in my opinion it requires call
flows in order to understand the whole underlying concept, it requires
procedures, it requires the reg-event extension, it requires additional
NAT traversal considerations, etc etc etc.

Regards,

Christer