Subject: [sipcore] sip-push: Recongizing the re-REGISTER

From: [email-masked] (Dale R. Worley)
Date: Mon, 19 Mar 2018 05:26:08 -0400

When there is an incoming request for a UA using sip-push, this
paragraph in section 5.3.2 describes how it is to be processes:

   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.  In case of a
   2xx response to the REGISTER request, once the proxy has forwarded
   the REGISTER response towards the UA, if the contact in the REGISTER
   response matches the Request-URI of the SIP request to be forwarded,
   the proxy can also forward the SIP request towards the UA, using
   normal SIP procedures.  If the contact of the most recent REGISTER
   2xx response and Request-URI do not match, the proxy MUST reject the
   SIP request with a 404 (Not Found) response.

The last sentence, in particular, assumes that the proxy can reliably
recognize which REGISTER request was sent by the UA, but the section
doesn't describe how it does that.  This needs to be spelled out, as
almost all elements of the registration can change over time.  In
particular, the IP address can change as the UA moves between networks,
or even sections of one network, and the PNS information may change (as
detailed elsewhere in the draft).

I can think of a number of approaches to this recognition, but they all
seem to have deficiencies that block the use of sip-push in situations
that I can imagine would want to use it.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Mar 2018 10:19:52 +0000

Hi Dale,

Please see inline:

> When there is an incoming request for a UA using sip-push, this paragraph 
> in section 5.3.2 describes how it is to be processes:
>
> The last sentence, in particular, assumes that the proxy can reliably recognize which REGISTER 
> request was sent by the UA, but the section doesn't describe how it does that.  This needs to be 
> spelled out, as almost all elements of the registration can change over time.  In particular, the IP 
> address can change as the UA moves between networks, or even sections of one network, and the 
> PNS information may change (as detailed elsewhere in the draft).

Note that the case where the R-URI and registered contact won't match is when the registrar forwards an INVITE towards the proxy at the same time when the UA sends a re-registration with a new contact. So, the R-URI of the INVITE will contain the "old" contact, while the 200 OK response to the REGISTER will contain the new contact.

As far as matching the INVITE with the REGISTER, you can use the pn- parameters for that.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2018 11:26:55 -0400

On Mon, Mar 19, 2018 at 6:19 AM, Christer Holmberg <
[email-masked]> wrote:

> recognize which REGISTER
> Note that the case where the R-URI and registered contact won't match is
> when the registrar forwards an INVITE towards the proxy at the same time
> when the UA sends a re-registration with a new contact. So, the R-URI of
> the INVITE will contain the "old" contact, while the 200 OK response to the
> REGISTER will contain the new contact.
>

Would this be better implemented by using RFC 3327 Path registration
extension? SIP Push proxy can include a parameter in the Path URL so that
it can match the inbound registration with all the requests that Registrar
will send for this registration.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Mar 2018 16:48:30 +0000

Hi,

>> Note that the case where the R-URI and registered contact won't match is when the registrar forwards an 
>> INVITE towards the proxy at the same time when the UA sends a re-registration with a new contact. So, the 
>> R-URI of the INVITE will contain the "old" contact, while the 200 OK response to the REGISTER will contain 
>> the new contact.
>>
> Would this be better implemented by using RFC 3327 Path registration extension? SIP Push proxy can
> include a parameter in the Path URL so that it can match the inbound registration with all the requests
> that Registrar will send for this registration.

Why would that be "better"? 

I am not even sure how it would work. When the proxy receives an INVITE, and requests a push notification, the REGISTER from the UA is not going to contain the Path information. 

In addition, usage of Path requires support by the registrar.

Usage of pn- parameter works fine.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2018 14:17:35 -0400

On Mon, Mar 19, 2018 at 12:48 PM, Christer Holmberg <
[email-masked]> wrote:

> paragraph
> >> INVITE towards the proxy at the same time when the UA sends a
> re-registration with a new contact. So, the
> extension? SIP Push proxy can
> I am not even sure how it would work. When the proxy receives an INVITE,
> and requests a push notification, the REGISTER from the UA is not going to
> contain the Path information.
>
We might also be talking about different things. I was talking about
matching of dialog creating request received by the edge proxy with an
existing registration. You might also be talking about matching the new
Registration from the client to the pending dialog creating request.

Our implementation was based on SIP Outbound and supported sip.instance and
registration path extensions from the start. When registration was received
from client UA, flow from the UA was stored in-memory on the edge proxy
together with sip-instance, reg-id, and push notification information. Key
for this in-memory DB entry was inserted in opaque parameter in Path header
added to registration message. When new request was received by the edge
proxy, the same opaque parameter would be present in the Route header. Edge
proxy would lookup if active flow was still present to the UA. If the flow
was present, the message would be immediately sent. If no flow was present,
message was queued in the in-memory DB on this flow entry and new push
notification was triggered. When new Registration was received, it was
matched against the in-memory DB based on sip-instance and reg-id. When 200
OK for this Registration was received, flow information for this flow entry
would get updated and if queued message were stored on this flow entry they
will be sent to UA. This is, of cause simplified, since our implementation
also dealt with sip flow expiration and flow probation (from the time
Registration was received until 200 OK was received from the registrar flow
was stored but not used).

>From implementation stand point I see two possible ways SIP push can be
implemented:

1. An implementation where edge proxy and registration server are part of
the same system. They use an internal mechanism to exchange data about
registration, push, and queued SIP messages. It would also likely assume
that only one UA is registered per AOR. In this case registration is
matched to pending requests using AOR. SIP Outbound is not used and NAT
binding is maintained during the call using SIP Session timer with short
expiration time. This implenetation will not track flows to the UA, and
will likely need to use push for each dialog creating or non-dialog message.

2. An implementation where edge proxy and registration server are separate
and communicate through standard communication mechanisms. For this
registration path extension and sip-instance are used to associate dialog
creating and non-dialog messages with registrations and push parameters.
This implementation would deal with multiple registrations per AOR and
clients changing IPs. It would also use SIP Outbound keep alive to maintain
flows to the client when client UA is active and only use SIP Push to
re-establish flows when SIP UA is suspended.

I think SIP Outbound implementation is better since it is more efficient
and deals with more scenarios (client IP changes). Path extension is pretty
much required if separate edge proxies are used with separate Registration
server. I see how "simpler" solution can be developed for an integrated
edge proxy and registrar, but when these component are separate, something
like Path extension and sip.instance will be needed.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2018 05:14:45 +0000

Hi Roman,

Thank you for your clarification!

As we agreed earlier, we could write a separate on how to use Push together with Outbound (and the extensions etc associated with Outbound). The core draft does allow forwarding the request without requesting a push notification it “has knowledge” that the SIP UA is awake, and usage of Outbound is one mechanism for providing such knowledge.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 19 March 2018 20:18
To: Christer Holmberg <[email-masked]>
Cc: Dale R. Worley <[email-masked]>; [email-masked]
Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER

On Mon, Mar 19, 2018 at 12:48 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

We might also be talking about different things. I was talking about matching of dialog creating request received by the edge proxy with an existing registration. You might also be talking about matching the new Registration from the client to the pending dialog creating request.

Our implementation was based on SIP Outbound and supported sip.instance and registration path extensions from the start. When registration was received from client UA, flow from the UA was stored in-memory on the edge proxy together with sip-instance, reg-id, and push notification information. Key for this in-memory DB entry was inserted in opaque parameter in Path header added to registration message. When new request was received by the edge proxy, the same opaque parameter would be present in the Route header. Edge proxy would lookup if active flow was still present to the UA. If the flow was present, the message would be immediately sent. If no flow was present, message was queued in the in-memory DB on this flow entry and new push notification was triggered. When new Registration was received, it was matched against the in-memory DB based on sip-instance and reg-id. When 200 OK for this Registration was received, flow information for this flow entry would get updated and if queued message were stored on this flow entry they will be sent to UA. This is, of cause simplified, since our implementation also dealt with sip flow expiration and flow probation (from the time Registration was received until 200 OK was received from the registrar flow was stored but not used).

From implementation stand point I see two possible ways SIP push can be implemented:

1. An implementation where edge proxy and registration server are part of the same system. They use an internal mechanism to exchange data about registration, push, and queued SIP messages. It would also likely assume that only one UA is registered per AOR. In this case registration is matched to pending requests using AOR. SIP Outbound is not used and NAT binding is maintained during the call using SIP Session timer with short expiration time. This implenetation will not track flows to the UA, and will likely need to use push for each dialog creating or non-dialog message.

2. An implementation where edge proxy and registration server are separate and communicate through standard communication mechanisms. For this registration path extension and sip-instance are used to associate dialog creating and non-dialog messages with registrations and push parameters. This implementation would deal with multiple registrations per AOR and clients changing IPs. It would also use SIP Outbound keep alive to maintain flows to the client when client UA is active and only use SIP Push to re-establish flows when SIP UA is suspended.

I think SIP Outbound implementation is better since it is more efficient and deals with more scenarios (client IP changes). Path extension is pretty much required if separate edge proxies are used with separate Registration server. I see how "simpler" solution can be developed for an integrated edge proxy and registrar, but when these component are separate, something like Path extension and sip.instance will be needed.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 20 Mar 2018 04:10:35 -0400

Christer Holmberg <[email-masked]> writes:
[taking points out of order]
> As far as matching the INVITE with the REGISTER, you can use the pn-

That makes sense, but as I said before, "This needs to be spelled out,
as almost all elements of the registration can change over time."  The
current text doesn't really specify what the proxy needs to do.

> Note that the case where the R-URI and registered contact won't match
> is when the registrar forwards an INVITE towards the proxy at the same
> time when the UA sends a re-registration with a new contact. So, the
> R-URI of the INVITE will contain the "old" contact, while the 200 OK
> response to the REGISTER will contain the new contact.

Yes, that's one of my primary concerns, as I don't see any guarantee
that a newly awakend UA can obtain the same IP address as it had
before.  I gather that in the environment you're currently working in,
that's the case, but it seems like we want to avoid designing that
restriction into the mechanism.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 20 Mar 2018 04:13:31 -0400

Roman Shpount <[email-masked]> writes:
> and communicate through standard communication mechanisms.

Finally, we have a concrete example of when "the proxy" is "far" from
the registrar.  I'm going to have to read through your example
carefully!

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2018 09:54:06 +0000

Hi,

>That makes sense, but as I said before, "This needs to be spelled out, as almost all >elements of the registration can change over time."  The current text doesn't really specify >what the proxy needs to do.

I agree. I will add text. It seems like I forgot to say that in my previous reply :)

>Yes, that's one of my primary concerns, as I don't see any guarantee that a newly awakend >UA can obtain the same IP address as it had before.  I gather that in the environment >you're currently working in, that's the case, but it seems like we want to avoid designing >that restriction into the mechanism.

As we know, if the IP address changes the request is rejected by the proxy with 556. Then, the registrar can of course be smart enough to figure out what is going on, so when it receives the 556 response it places the new contact in the R-URI of the INVITE and tries to send it towards the UA again. But I don't think we need to specify such behaviour.

Regards,

Christer

---

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

> re-establish flows when SIP UA is suspended.

My conception is that in this case, where the implementing proxy and
registration server are separate, and so the implementing proxy can be
viewed as an edge proxy, we are adding a further complication:  When the
UA awakens, its new REGISTER may go through a *different* edge proxy
(and may register different contact URI).

I believe that that case is unavoidable when we have proxy separation.
I also believe that we can accommodate this situation with minimal
changes in the draft.  The mechanism I've proposed is similar to the
system you describe, with the pn-provider/pn-prid taking the place of
the opaque parameter, and matching between the REGISTER and the incoming
request done by pn-provider/pn-prid rather than sip-instance/reg-id.

However, I do believe that what I have written is not sufficient for
situations where the UA is using SIP Outbound, and needs to be updated
to support SIP Outbound.  I suspect that this only requires elaborating
the conditions for "recognizing the matching REGISTER".

Dale

---

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

> (and may register different contact URI).

I am fairly sure that if SIP UA goes through different edge proxies when it
wakes then non of the current NAT traversal solutions will work. I think
the best way to address this in SIP Push draft is to spell out that this is
not supported.

Fixing this in general case that you are describing is fairly hard, since
it will require the edge SIP proxy, when it gets a new registration, to
communicate with all the other edge proxies and check if they have any
queued SIP messages waiting for the connection from this client.

Regards,
_____________
Roman Shpount

---

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

It seems to me that sip-push and SIP Outbound can be used together, with
SIP Outbound's edge proxies being sip-push's implementing proxies.
Operationally, the complication is that when the UA awakens, it may
establish flows with different edge proxies.  The proxy that awakened
the UA needs to recognize this and forward the incoming request to the
correct edge proxy.

Conceptually this isn't hard, but it seems like some machinery needs to
be added to the proposal to handle it.  When the proxy is processing an
incoming request, it needs to know which registration to monitor.  To do
that, it needs to know the AOR, which is carried in pn-aor.  It needs to
know the UA identity, which is effectively carried in
pn-provider/pn-prid (and these two determine the sip.instance, so
sip.instance need not be carried directly).  It also needs to know the
reg-id, but we seem to have no mechanism for carrying that.  So it seems
like we'd need to add a pn-reg-id parameter for carrying the reg-id
value.

Given that information, the proxy can identify the correct registration
in the reg event package, which looks something like this:

   <?xml version="1.0"?>
       <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    version="0" state="full">
         <registration aor="sip:[email-masked]" id="as9"
                       state="active">
           <contact id="76" state="active" event="registered"
                    duration-registered="7322" cseq="123">
                    <uri>sip:[email-masked];transport=tcp;pn-provider=acme;pn-param=acme-param;pn-prid=ZTY4ZDJlMzODE1NmUgKi0K;pn-aor=bob%40example.com;pn-reg-id=1</uri>
	            <unknown-param name="reg-id">1</unknown-param>
	            <unknown-param name="+sip.instance">&lt;urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF&gt;</unknown-param>
           </contact>
           <contact id="77" state="active" event="registered"
                    duration-registered="7013" cseq="456">
                    <uri>sip:[email-masked];transport=tcp;pn-provider=acme;pn-param=acme-param;pn-prid=ZTY4ZDJlMzODE1NmUgKi0K;pn-aor=bob%40example.com;pn-reg-id=2</uri>
	            <unknown-param name="reg-id">2</unknown-param>
	            <unknown-param name="+sip.instance">&lt;urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF&gt;</unknown-param>
           </contact>
         </registration>
       </reginfo>

The AOR allows the proxy to retrieve the correct event information, the
pn-prid et al. allows it to identify the <contact>s for the UA in
question, and the <unknown-param name="reg-id">s allow it to select from
those <contact>s the one registration which was used to forward this
incoming request.

But when the proxy monitors <contact id="76">, when the contact is
updated (the cseq attribute increases), the proxy can observe whether
the <uri> has changed, but it has no way to monitor whether the Path in
the REGISTER request has changed.

If the Path has changed, the proxy needs to either 404 the request, or
re-route it by removing any remaining Route headers, and then forwarding
it to the path (new Path URIs, new contact URI).  Or alternatively, it
can forward it to the AOR, and have the domain's redirector send the
request through the correct path to the correct edge proxy.

I can think of two ways for the proxy to deal with a changing Path.

1. Extend the reg event package to have a way to carry the Path
information.  If the registrar implements Path (RFC 3327), it is
recording this information already, so it shouldn't be difficult to add
this to the event package.

2. If the Path has *not* changed, the edge proxy is likely to process
the REGISTER and its response.  So if the proxy monitors the event
package and watches for REGISTERs, it can determine whether the Path
stayed the same (REGISTER was also seen) versus the Path changes
(REGISER was not seen).  If the Path changed, it can forward the request
to the AOR for re-forwarding.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2018 14:32:59 +0000

Hi Dale,

I may not agree with everything below, but the things you talk about below will be covered in draft-push-with-outbound.

Regards,

Christer

Sent from my iPhone

On 22 Mar 2018, at 12.41, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

  <?xml version="1.0"?>

Dale

---

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

Christer Holmberg <[email-masked]> writes:
> I may not agree with everything below, but the things you talk about
> below will be covered in draft-push-with-outbound.

It's not clear to me what assures that it those topics will be covered
in "draft-push-with-outbound".  Are you saying that you will be writing
that draft?

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Mar 2018 15:51:45 +0000

Hi,

> It's not clear to me what assures that it those topics will be covered in "draft-push-with-
> outbound".  Are you saying that you will be writing that draft?

I definitely would, because I do think it can become a useful feature.

Regards,

Christer

---

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

> queued SIP messages waiting for the connection from this client.

After thinking about this case, I think it's simpler to fix than it
first appears.  I've given a fairly detailed first draft in another
message, but the essence is that when the UA awakens and connects to a
new edge proxy, it then sends a re-REGISTER.  That REGISTER lands on the
registrar, causing the 'cseq' parameter in the reg event package to
increase.

Any edge proxy that is queueing an initial request for the UA is
watching that reg event package, and thus it sees 'cseq' being
incremented.  At that point, there are multiple techniques for
delivering the queued requests, but the simplest is for the proxies that
are queueing them to forward them to the original AOR.  The requests
return to the SIP domain's redirector, which sends them to the edge
proxy that the UA is currently connected to, which knows that the UA is
awake (by one method or another) and forwards the requests to the UA.

Dale

---

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

>registrar, causing the 'cseq' parameter in the reg event package to

How do you know that the ³new² edge proxy supports SIP push to begin with?

The support is negotiated during registration, and if you want to register
via multiple proxies you should use Outbound.

Also note that RFC 3261 says that re-registrations SHOULD be sent to the
same network address as the original registration. So, if you want start
sending re-registrations ³all over² I think that goes beyond SIP push.

>awake (by one method or another) and forwards the requests to the UA.

What is the ³SIP domain¹s redirector²?

It is really difficult for me to picture your scenario, so please provide
call flows.

Regards,

Christer