Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - SIP Proxy waiting for 200 OK before forwarding SIP request

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Feb 2018 10:55:11 +0000

Hi,

Below is suggested new text regarding the SIP proxy waiting for the REGISTER response before forwarding the request towards the UA.

The text also covers the case where the registered contact has changed, and no longer matches the Request-URI of the request to be forwarded.

OLD:

   "When the SIP proxy receives (or, in case the proxy is the SIP
   registrar, creates) a SIP request for a new dialog (e.g., a SIP
   INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
   request) aimed for 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 triggers a push
   request towards the PNS associated with the PRID.  After that the
   proxy forwards the SIP request towards the UA using normal SIP
   procedures.

   As the push notification will trigger the SIP UA to perform a re-
   registration, the SIP proxy can use the receipt of the SIP REGISTER
   request as a trigger to forward SIP request towards the UA."

NEW:

   "When the SIP proxy receives (or, in case the proxy is the SIP
   registrar, creates) a SIP request for a new dialog (e.g., a SIP
   INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
   request) aimed for 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 triggers a push
   request towards the PNS associated with the PRID.

   The push notification will trigger the SIP UA to perform a
   re-registration. The SIP proxy will either forward the REGISTER request 
   towards the registrar using normal SIP routing procedures or, in the case
   the proxy is the SIP registrar, process the REGISTER request . If the SIP proxy
   receives (or, in case the proxy is the SIP registrar, creates) a 200 (OK) response 
   to the REGISTER request it can forward the SIP request towards the UA. 
   If the SIP proxy receives (or creates) a non-200 response to the REGISTER request 
   is rejected the proxy MUST NOT forward the request towards the UA. Instead the 
   SIP proxy MUST reject the SIP request with a 404 (Not Found) response. In
   addition, if the contact in the REGISTER response does not match the Request-URI
   of the SIP request the SIP proxy MUST reject the SIP request with a 404 (Not Found)
   response. 

   NOTE: The reason the SIP proxy needs to wait for the REGISTER response before
   forwarding the request is to make sure that the REGISTER request has been
   accepted by the registrar."

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Feb 2018 23:22:43 -0500

Christer Holmberg <[email-masked]> writes:
> Below is suggested new text regarding the SIP proxy waiting for the
> REGISTER response before forwarding the request towards the UA.
>
> The text also covers the case where the registered contact has
> changed, and no longer matches the Request-URI of the request to be
> forwarded.

I think the text needs to be expanded to cover the common case where the
registrar returns a 401 response to the first re-REGISTRAR (because the
nonce has expired) and the UA has to send a second re-REGISTRAR.  I'm
sure that implementers understand this, but it's worth stating.

However, the new text doesn't seem to directly describe what is to be
done in the situation where the UA successfully reregisters with a
different contact address.  That's a bit tricky, because all of the
special push processing is triggered by the *old* contact address,
whereas the actual forwarding of the request is controlled by the *new*
contact address.

Perhaps change the short NOTE paragraph to:

    Once the proxy has seen that the UA has successfully reregistered,
    it must use the contact URI from the revised registration to forward
    the request to the UA (rather than the contact URI that was obtained
    from the registrar when the request was received by the proxy).

Dale

---

From: Roman Shpount <[email-masked]>
Date: Mon, 5 Feb 2018 23:29:13 -0500

>     from the registrar when the request was received by the proxy).
In this case, I think interaction with sip.instance contact header
parameter should also be described here.

Also, I think text should specify 2XX responses, not just 200 responses to
the registrations.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 04:39:20 +0000

Hi,

> I think the text needs to be expanded to cover the common case where the registrar returns a 401 response to the 
> first re-REGISTRAR (because the nonce has expired) and the UA has to send a second re-REGISTRAR.  I'm sure that 
> implementers understand this, but it's worth stating.

I think that is good to mention.

> However, the new text doesn't seem to directly describe what is to be done in the situation where the UA successfully 
> reregisters with a different contact address.  That's a bit tricky, because all of the special push processing is triggered by 
> the *old* contact address, whereas the actual forwarding of the request is controlled by the *new* contact address.

The suggested text says that, if the newly registered contact does not match the R-URI of the request to be forwarded, the request is rejected.

>    from the registrar when the request was received by the proxy).

I was thinking about that, but unless the proxy is also the registrar, do we want it to modify the R-URI?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 04:43:53 +0000

Hi,

> In this case, I think interaction with sip.instance contact header parameter should also be described here.

I think that is a slippery slope, and we shouldn't go there. It's better to reject the request. Of course, perhaps we could somehow indicated "outdated contact", so that the registrar may try to re-send the request with the updated contact information, instead of rejecting the call establishment.

> Also, I think text should specify 2XX responses, not just 200 responses to the registrations.

Ok. I can fix that.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Feb 2018 17:53:01 -0500

> parameter should also be described here.

The problem is that sip.instance is optional.  Perhaps we could make it
mandatory for UAs doing SIP-push, in which case it could be used to
corrleate REGISTER requests and registrations.  But sip.instance won't
be on the incoming requests, which will limit its usefulness.  Given
that PRIDs will be unique, we probably don't need to process
sip.instance's.

> do we want it to modify the R-URI?

It's a proxy, so it's allowed to change R-URIs in requests that it
forwards.  So I don't think there's a reason to object to that.  The
question is whether we envision architectures where the UA's IP address
may change while it is alseep.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 09:07:18 +0000

Hi,

> The problem is that sip.instance is optional.  Perhaps we could make it mandatory for UAs doing SIP-push, in 
> which case it could be used to corrleate REGISTER requests and registrations.  But sip.instance won't be on the
> incoming requests, which will limit its usefulness.  Given that PRIDs will be unique, we probably don't need to 
> process sip.instance's.

Correct.

> It's a proxy, so it's allowed to change R-URIs in requests that it forwards.  So I don't think there's a reason to 
> object to that.

Ok. I will add some text about that.

> The question is whether we envision architectures where the UA's IP address may change while it is alseep.

I don't think it will normally happen just because the UA is asleep (it may of course happen if the UA changes network etc while being asleep).

But, the mechanism works even if it does. If the IP address in the stored request is different than the IP address of the reregister contact, then the proxy can re-write the R-URI.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Feb 2018 11:39:35 -0500

> I don't think it will normally happen just because the UA is asleep (it may of course happen if the UA changes network etc while being asleep).

The UA knows the TTL of its IP address. Seems like it needs to arrange a 
way to wake up before then, refresh its IP, and then if necessary 
re-register.

I don't know how the push mechanisms work, but won't they also have a 
problem if the IP changes?

> But, the mechanism works even if it does. If the IP address in the stored request is different than the IP address of the reregister contact, then the proxy can re-write the R-URI.

Beware. This sounds like you are suggesting ad hoc changes to the sip 
address rewriting mechanisms. That seems like a bad idea. But maybe I 
misunderstand you. ISTM that the proxy (assuming it is the home proxy 
for the AoR) should simply delay the rewrite until the push has been 
completed.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 17:40:59 +0000

Hi,

> The UA knows the TTL of its IP address. Seems like it needs to arrange a way to wake up before then, refresh its IP, and then if necessary re-register.
>
> I don't know how the push mechanisms work, but won't they also have a problem if the IP changes?

Keep in mind that, just because the SIP UA app "sleeps", the device is still up and running. So, therefore I doubt the IP address will change in normal situations.

>> But, the mechanism works even if it does. If the IP address in the stored request is different than the IP address of the 
>> reregister contact, then the proxy can re-write the R-URI.
>
> Beware. This sounds like you are suggesting ad hoc changes to the sip address rewriting mechanisms. That seems like a bad idea. 
> But maybe I misunderstand you. ISTM that the proxy (assuming it is the home proxy for the AoR) should simply delay the rewrite 
> until the push has been completed.

If the proxy is the registrar, it will see what contact comes in the REGISTER, so it can place that value in the R-URI using normal SIP procedures.

If the proxy is not the registrar, the draft currently says that it rejects the request if it receives a REGISTER where the contact does not match the R-URI.

Regards,

Christer