Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Dale's reivew

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Feb 2018 01:27:12 +0000

Hi Dale,

Thanks for your comments! Please see inline.

** Major/global issues

>* Parameters vs. header parameters
>
>   The document defines new SIP URI parameters,
>
> I still strenuously object to implementing these as URI parameters rather than as header field parameters, given that the 
> information carried is information *about* the registered SIP URI and not part of the URI.  E.g., you wouldn't include these 
> parameters in the request-URI of an INVITE.

There is a separate discussion about this, so I will not repeat it here.

---

> * Reregistration
>
> Handling re-registration still needs some work.  The difficulty is that the registrar/proxy does't know when the UA needs to
> reregister, it only knows when the current registration is going to expire.  In particular, some UAs use a reregistration strategy 
> copied from some DHCP clients:  reregister at intervals of (expiration time)/3 - epsilon.  This allows the UA three opportunities 
> to reregister, and they are widely separated in time, thus minimizing the chance that all three will be defeated by temporary 
> network interruptions.  The registrar/proxy has no way of knowing this.

The proxy knows when the registration is going to expire, and will act upon that, and based on the information I've got that works for terminals.

If we want to give the UA more control regarding when push notifications are triggered, in order to trigger re-registrations, I think we can do that as an extension. It does not need to be part of the base mechanism.

> In addition, the registrar/proxy doesn't know the amount of time that it will take the UA to wake up from a push notification and send its re-REGISTER.

For that reason it needs to trigger the re-REGISTER before the registration expires.

> Ultimately, the dataflow is difficult:  the UA requests a registration duration, the registrar allows a registration that may
> be less than the requested duration, and from the allowed duration, the UA determines when it wants to reregister.  
> But this process seems to require three messages to pass between the UA and the registrar, whereas the REGISTER 
> transaction only has two messages.

> OTOH, it seems that in most cases, the UA can instruct its OS to wake it up after a certain time interval, and thus does not 
> need a push notification for reregistration to maintain its AOR.  If that is so, the reregistration parts of this document can 
> simply be removed, because the ordinary implementation practices will work well -- once the UA receives the 200 response 
> to its REGISTER request, it will set a timer with its OS for whenever it wants to reregister.

Again, the original reason the document was written was for cases where timers cannot be used. 

Having said that, if we want the UA to be able to say "please only a request push notification when there is an incoming request" we could of course do that, if there is a use-case where a UA would use timers to send re-registrations, but still want to use push to be informed about incoming requests.

---

>* Extraneous use of "SIP"
>
>There are various places where "SIP" is used extraneously.  E.g., "proxy", "registrar" "555 response", "request", "URI", "UA", "INVITE request", "REGISTER request", >"network".  Given that the entire document is about SIP, almost no noun needs to be qualified with "SIP".

Maybe "SIP" can be removed in some places, but I want to make sure there is no confusion whether the text is talking about e.g., a SIP request or a push notification request.

---

>* The prefix "pns-"
>
> There are places where the prefix "pns-" is used, but it appears that the author intends for "pn-" to be used.

Will be fixed.

===

** Local issues

>1.  Introduction
>
>   Due to the restriction above, applications can not be woken up by
>   non-push notification traffic.  This means that a suspended SIP UA
>   will not be able to receive an incoming SIP request (e.g., a SIP
>   INVITE request), or to send periodic re-registration requests.
>
> "awakened" is usually more proper than "woken up" in written text.

I will fix as suggested.

---

> Note that reregistration isn't being awakened by traffic, but internally-generated activity.  The first sentence needs to be revised 
> to include that the application cannot schedule its own awakening either.  (But is there ever a case where the UA cannot schedule 
> its own awakening at a definite future time?)

I will look into that.

>(But is there ever a case where the UA cannot schedule its own awakening at a definite future time?)

Yes. Push is the only way to awake the UA.

> Figure 1 omits quite a bit of the action.  Viz., once SIP UA has sent the REGISTER, there should be shown a period of 
> suspension.  At the end of suspension, an INVITE arrives at SIP Proxy, triggering it to send the Push Message.  It seems 
> that the mechanism requires that the awakened SIP UA must send a REGISTER immediately to inform the proxy that it 
> can now receive messages, and that REGISTER should be shown, after which the incoming request is sent.

I agree, and I will update the picture.

---

> 3.  Push Resource ID (PRID)
>
> This section should describe the expected syntax or character set used by PRIDs and the other values.  Actually, all of these 
> are general "pvalue" from RFC 3261, and so can represent arbitrary character strings.  But that should be stated clearly.

The text says: "The format of the PRID may vary depending on the PNS provider."

Non-allowed characters need to be escaped, but I assumed that is normal SIP. But, I can add a note about that.

---

4.  SIP User Agent (UA) Behavior

>   When the SIP UA receives a 200 (OK) response to the SIP REGISTER
>   request, if the response does not contain a Feature-Caps header field
>   with a '+sip.pns' header field parameter, ...
>
> The items in a Feature-Caps header are "indicators", not "parameters".  See RFC 6809 section 6.3.

When used in the Feature-Caps, it is a header field parameter - at least that's how I remember Keith explaining it :)

>   When the SIP UA receives a 200 (OK) response to the SIP REGISTER
>   request, if the response does not contain a Feature-Caps header field
>   with a '+sip.pns' header field parameter ...
>
> The text must include a positive statement indicating when the UA can understand that its desired push notification
> service is supported for the registration.  Or better, the sense of the condition at the beginning of the paragraph should be inverted:
>
>   When the SIP UA receives a 200 (OK) response to the SIP REGISTER
>   request, the response contains a Feature-Caps header field
>   containing a '+sip.pns' indicator, and that indicator's value
>   contains a tag-value that is the same as the pn-provider in the
>   REGISTER, the UA can assume that push notifications will be
>   triggered by any SIP proxy handling requests for the given AOR.  In
>   all other cases, the UA cannot assume that push notifications will
>   be triggered by a SIP proxy.  The actions taken by the UA might be
>   dependent on implementation or deployment architecture, and are
>   outside the scope of this document.

I will look into that.

> Note that I've also fixed the logic here:  success requires that
> +sip.pns value contains the same tag as the pn-provider that was used.
> The original text was that the +sip.pns value contains a tag that the UA supports, but that does not 
> guarantee that the supported tag is the one the UA *used*.

Correct.

>  If the SIP UA expects to receive payload in the push notification,
>  the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field
>  SIP URI parameter, in order to allow encryption of the data using the
>  mechanism in [RFC8291].  The pn-enckey URI parameter contains the
>  public key, and the pn-encsec URI parameter contains the
>  authentication secret [RFC8291].  The format of such payload is
>  outside the scope of this document.
>
>   NOTE: End-to-end encryption of the payload between the SIP proxy and
>   the SIP UA cannot be used if the push notification request payload
>   contains information that needs to be accessible by the PNS provider.
>
> It's not clear to me, regarding the payload that is encrypted using pn-enckey and pn-encsec, who generates it and
> what it contains.  If it is generated by the registrar (or the proxy pretending to be the registrar), then this document 
> should define what the payload is. If the payload is generated by the push notification service itself, presumably the 
> payload contents are defined by the PNS, but it's not clear how the parameters in the REGISTER will be transmitted 
> to the push notification service.
>
>  ... a pn-enckey and a pn-encsec ...
>
> "pn-encsec" doesn't seem to be used elsewhere in the document.
> Perhaps "pn-enccode" was meant?  Or rather, "encsec" seems a better name than "enccode" and should be used throughout...

pn-enckey and pn-encsec were added based on an early comment by Martin.

But, based on previous discussions, as the mechanism does not require usage of end-to-end payloads, I intend to remove it.

---

> 5.  SIP Proxy Behavior
>
>   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 ...
>
> Isn't this just a prolix way of saying "When the SIP proxy receives a request aimed for a SIP UA ..."?

Mid-dialog requests will not trigger push.

>   If the SIP proxy is able to assume that the SIP UA is awake ...
>
> Better wording is "If the SIP proxy has knowledge that the SIP UA is awake ...".  (Because anything "is able to assume" anything, though it might be wrong...)

I will fix as suggested.

>   If the SIP proxy is not able to contact the push notification
>   provider, or to forward the SIP request to the SIP UA, the proxy MUST
>   reject the SIP request.
>
> It might be useful to describe what response code(s) should be used in this situation.  408 seems suitable, but it is not specific to 
> this situation.  480 is "Temporarily Unavailable", but that means that the *user* is temporarily unavailable rather than the *network*.  
> It might be worth defining a response code meaning "UA is temporarily unavailable".

In the pull request, I am suggesting 404. 

(I was also considering 503.)

---

>7.3.  SIP URI Parameters
>
>     The format and semantics of pns-param is specific to a given
>     pns-provider value.
>
>I think "pns-param" is supposed to be "pn-param".

Yes. Will be fixed (see pull request).

> Isn't it true that the format of pn-prid, pn-enccode, and pn-enckey are also controlled by the pns-provider?

Regarding pn-prid, yes.

(pn-enccode and pn-enckey are intended to be removed)

---

> 8.  PNS Registration Requirements
>
>   The value of the pn-param URI parameter is the APNs App ID, which is
>   encoded by two values, separated by a period (.): Team ID and Bundle
>   ID.  The Team ID is provided by Apple and is unique to a development
>   team.  The Bundle ID is unique to a development team, and is a string
>   that will can match a single application or a group of applications.
>
>   Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp
>
> As written, this is confusing, because the description of the syntax of pn-param doesn't allow the reader to parse the given example, since the example contains three 
> periods.  Probably the Team ID cannot contain a period, which disambiguates the example, but that needs to be stated to avoid confusing the reader.

I don't think we need to go into those details in the draft - they need to be described elsewhere.

What we need to define is what the parameter contains. 

----

> 9.  pn-provider, pn-param and pn-prid URI Parameters for Apple Push 10.  pn-provider, pn-param and pn-prid URI Parameters for Google
>
> It seems like sections 9 and 10 could be grouped as subsections of a single section, most likely part of section 12.

It could be in a single section, but I don't think it shall be part of section 12. The definition/description of the values shall be separated from the IANA considerations.

---

>11.  Security Considerations
>
>There is no description of what mechanism prevents one UA from registering using the pn-parameters of another device, or even 
>using entirely random pn-parameters.  The document is written as if the pn-parameters form a "capability", an identifier containing 
>so much entropy that just knowing the identifier of a resource proves that one has the right to access the resource.  However, the 
>example in section 8 suggests that this is not so.

Technically, I don't think there is anything preventing one UA from registering parameters belonging to another device - just like a UA could use whatever other credentials belonging to another UA if it gets access to those. For that reason it is important to secure/encrypt the SIP signalling etc.

---

>12.1.1.  pn-provider
>
> This section doesn't mention that it is connected with either the registry for its values (defined in section 12.4) or the currently 
> defined values (defined in sections 9 and 10).

I don't think that is needed in the IANA registration.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Feb 2018 15:48:49 +0000

Hi,

I have updated the pull request based on the comments from Dale.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 07 February 2018 03:27
To: Dale R. Worley <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Dale's reivew

Hi Dale,

** Major/global issues

> I still strenuously object to implementing these as URI parameters 
> rather than as header field parameters, given that the information 
> carried is information *about* the registered SIP URI and not part of the URI.  E.g., you wouldn't include these parameters in the request-URI of an INVITE.

---

> * Reregistration
>
> Handling re-registration still needs some work.  The difficulty is 
> that the registrar/proxy does't know when the UA needs to reregister, 
> it only knows when the current registration is going to expire.  In 
> particular, some UAs use a reregistration strategy copied from some 
> DHCP clients:  reregister at intervals of (expiration time)/3 - epsilon.  This allows the UA three opportunities to reregister, and they are widely separated in time, thus minimizing the chance that all three will be defeated by temporary network interruptions.  The registrar/proxy has no way of knowing this.

> Ultimately, the dataflow is difficult:  the UA requests a registration 
> duration, the registrar allows a registration that may be less than the requested duration, and from the allowed duration, the UA determines when it wants to reregister.
> But this process seems to require three messages to pass between the 
> UA and the registrar, whereas the REGISTER transaction only has two messages.

> OTOH, it seems that in most cases, the UA can instruct its OS to wake 
> it up after a certain time interval, and thus does not need a push 
> notification for reregistration to maintain its AOR.  If that is so, 
> the reregistration parts of this document can simply be removed, because the ordinary implementation practices will work well -- once the UA receives the 200 response to its REGISTER request, it will set a timer with its OS for whenever it wants to reregister.

---

---

Will be fixed.

===

** Local issues

I will fix as suggested.

---

> Note that reregistration isn't being awakened by traffic, but 
> internally-generated activity.  The first sentence needs to be revised 
> to include that the application cannot schedule its own awakening 
> either.  (But is there ever a case where the UA cannot schedule its 
> own awakening at a definite future time?)

I will look into that.

> Figure 1 omits quite a bit of the action.  Viz., once SIP UA has sent 
> the REGISTER, there should be shown a period of suspension.  At the 
> end of suspension, an INVITE arrives at SIP Proxy, triggering it to 
> send the Push Message.  It seems that the mechanism requires that the awakened SIP UA must send a REGISTER immediately to inform the proxy that it can now receive messages, and that REGISTER should be shown, after which the incoming request is sent.

---

> This section should describe the expected syntax or character set used 
> by PRIDs and the other values.  Actually, all of these are general "pvalue" from RFC 3261, and so can represent arbitrary character strings.  But that should be stated clearly.

---

> The text must include a positive statement indicating when the UA can 
> understand that its desired push notification service is supported for the registration.  Or better, the sense of the condition at the beginning of the paragraph should be inverted:
>

I will look into that.

> The original text was that the +sip.pns value contains a tag that the 
> UA supports, but that does not guarantee that the supported tag is the one the UA *used*.

Correct.

> It's not clear to me, regarding the payload that is encrypted using 
> pn-enckey and pn-encsec, who generates it and what it contains.  If it 
> is generated by the registrar (or the proxy pretending to be the 
> registrar), then this document should define what the payload is. If 
> the payload is generated by the push notification service itself, presumably the payload contents are defined by the PNS, but it's not clear how the parameters in the REGISTER will be transmitted to the push notification service.
>

---

> Better wording is "If the SIP proxy has knowledge that the SIP UA is 
> awake ...".  (Because anything "is able to assume" anything, though it 
> might be wrong...)

I will fix as suggested.

> It might be useful to describe what response code(s) should be used in 
> this situation.  408 seems suitable, but it is not specific to this situation.  480 is "Temporarily Unavailable", but that means that the *user* is temporarily unavailable rather than the *network*.

---

Regarding pn-prid, yes.

---

> As written, this is confusing, because the description of the syntax 
> of pn-param doesn't allow the reader to parse the given example, since the example contains three periods.  Probably the Team ID cannot contain a period, which disambiguates the example, but that needs to be stated to avoid confusing the reader.

----

> 9.  pn-provider, pn-param and pn-prid URI Parameters for Apple Push 
> 10.  pn-provider, pn-param and pn-prid URI Parameters for Google
>

---

>There is no description of what mechanism prevents one UA from 
>registering using the pn-parameters of another device, or even using 
>entirely random pn-parameters.  The document is written as if the 
>pn-parameters form a "capability", an identifier containing so much entropy that just knowing the identifier of a resource proves that one has the right to access the resource.  However, the example in section 8 suggests that this is not so.

---

>12.1.1.  pn-provider
>
> This section doesn't mention that it is connected with either the 
> registry for its values (defined in section 12.4) or the currently defined values (defined in sections 9 and 10).

Regards,

Christer

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

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 11 Feb 2018 15:14:33 -0500

Christer Holmberg <[email-masked]> writes:
>> In addition, the registrar/proxy doesn't know the amount of time that
>> it will take the UA to wake up from a push notification and send its
>> re-REGISTER.
>

Well, yes, obviously.  But the question is *how long* before the
registration expires should it trigger the re-registration?  I see no
mechanism to control that, or even advice on what the interval should
be.

> When used in the Feature-Caps, it is a header field parameter - at
> least that's how I remember Keith explaining it :)

Well, that's not how it's written in the RFC.

>> this situation.  408 seems suitable, but it is not specific to this
>> situation.  480 is "Temporarily Unavailable", but that means that the
>> *user* is temporarily unavailable rather than the *network*.

Though 404 seems to be used more for "incorrect address", which doesn't
really apply here.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Feb 2018 22:50:36 +0000

Hi,

> Well, yes, obviously.  But the question is *how long* before the registration expires should it trigger the re-registration?  
> I see no mechanism to control that, or even advice on what the interval should be.

I guess we don't need to define a specific value, but a minimum value. 10 seconds? RECOMMENDED? SHOULD?

---

> Well, that's not how it's written in the RFC.

I think his argument was that, in the Feature-Caps header field, the indicators are represented as header field parameters.

----

>>> It might be useful to describe what response code(s) should be used 
>>> in this situation.  408 seems suitable, but it is not specific to 
>>> this situation.  480 is "Temporarily Unavailable", but that means 
>>> that the
> Though 404 seems to be used more for "incorrect address", which doesn't really apply here.

I suggest to separate the cases:

- In case of a non-2xx response to the REGISTER request triggered by the push notification, or if the contact in the REGISTER response does not match the Request-URI of the SIP request to forward, we use 404. Of course, we could define a new 4xx (Request-URI Not Registered) response code, but I don't see how it would be semantically different from 404.

- In case of a failure to request the push notification, we use 555.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Feb 2018 06:46:28 -0500

> Well, that's not how it's written in the RFC.

Perhaps the word you're looking for is "values"?  One meaning of "value"
is what follows the colon in a header, but by virtue of RFC 3261 section
7.3, a series of headers can be combined by separating their values with
commas, and so it's reasonable to call the items separated by comma
"values" and people do so.

OTOH, "parameters" seems to be used only for things following
semicolons.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Feb 2018 14:01:18 +0000

Hi,

>OTOH, "parameters" seems to be used only for things following

I don¹t knowŠ I don't want time arguing about it, so unless anyone has
issues with it I¹m ok using ³indicators² :)

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Feb 2018 07:12:54 -0500

> value. 10 seconds? RECOMMENDED? SHOULD?

I don't know how these networks and devices actually behave, but it
seems to me 10 seconds is rather short.  I'd choose something like 120
seconds as the default to ensure that *any* device on *any* network
would have time to complete processing before the registration expires.
OTOH, I've always worked with wired networks where the reregistration
interval was at least 1 hour.  Perhaps the reregistration interval in
this environment is significantly shorter, in which case 120 seconds
might be a large fraction of the interval.

> I think his argument was that, in the Feature-Caps header field, the
> indicators are represented as header field parameters.

Well, my point was that the usage of the indicators doesn't match the
use of "parameters" in RFC 3261, because it isn't something that follows
a semicolon.  But I am wrong there, I didn't read RFC 6809 section 6.3.2
closely enough, they actually are in the header as paramaters.  My
apologies for that.

> - In case of a non-2xx response to the REGISTER request triggered by
> the push notification, or if the contact in the REGISTER response does
> not match the Request-URI of the SIP request to forward, we use
> 404. Of course, we could define a new 4xx (Request-URI Not Registered)
> response code, but I don't see how it would be semantically different
> from 404.

A point that is related to the above item is this:  How does the proxy
recognize that an incoming re-REGISTER matches a request that it is
buffering?  I haven't read -06 through, but I don't think it says
explicitly.

I think people have been assuming that this is done by matching the
contact URI in the REGISTER with the request-URI in the incoming
request.  But that doesn't work in the presence of NATing (see section
6), because the address (as seen by the proxy/registrar) that the UA has
received this time may be transient and different from last time.

I think there are three(!) available choices, all of which involve
matching elements of the new REGISTER with the "metadata" of the
registration which triggered the proxy to buffer the incoming request:
- the Call-Id
- the instance-id (+sip.instance) Contact header field (which is optional)
- the pn-provider/pn-prid combination (which is assumed to be unique,
  section 3)

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2018 12:39:57 +0000

Hi Dale,

>might be a large fraction of the interval.

We can do 120 seconds. As you say, re-registration intervals are normally
measured in hours, so there is no reason for us to pick a value that is
too small.

>closely enough, they actually are in the header as paramaters.  My

No problems :)

Note, though, that I changed it in the latest version. Do you want me to
change it back?

>request.

Correct.

>  But that doesn't work in the presence of NATing (see section

The NAT will not change the contact URI in the REGISTER. The proxy will
obviously have to stored request towards the NAT address, from where it
received the REGISTER, but it will use the contact URI for the matching.
We should probably add some words about that to the NAT Considerations
sections.

>registration which triggered the proxy to buffer the incoming request:

The Call-Id of the request-to-be-forwarded is generated by the remote
peer, so there is no way to guarantee it will be identical to the one used
in the REGISTER. Most likely it won¹t be.

>- the instance-id (+sip.instance) Contact header field (which is optional)

As far as I remember, the instance-id is not present in the request.

>- the pn-provider/pn-prid combination (which is assumed to be unique,

Well, pn-provider/pn-prid are part of the URI, so by comparing the contact
URI with the R-URI you DO use those :)

I think it is still good to also compare the IP address:port of the URI,
to make sure they match.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2018 21:04:02 +0000

Hi,

...

>>But that doesn't work in the presence of NATing (see section 6), 
>>because the address (as seen by the proxy/registrar) that the UA has 
>The NAT will not change the contact URI in the REGISTER. The proxy will obviously have to >stored request towards the NAT address, from where it received the REGISTER, but it will >use the contact URI for the matching.
>We should probably add some words about that to the NAT Considerations sections.

I have created a pull request, adding more text about the mapping, and adding more text to the NAT Considerations.

https://github.com/cdh4u/draft-sip-push/pull/12

Regards,

Christer

>registration which triggered the proxy to buffer the incoming request:

The Call-Id of the request-to-be-forwarded is generated by the remote peer, so there is no way to guarantee it will be identical to the one used in the REGISTER. Most likely it won¹t be.

>- the pn-provider/pn-prid combination (which is assumed to be unique,

Well, pn-provider/pn-prid are part of the URI, so by comparing the contact URI with the R-URI you DO use those :)

I think it is still good to also compare the IP address:port of the URI, to make sure they match.

Regards,

Christer

---

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

Christer Holmberg <[email-masked]> writes:
>>[...]  But I am wrong there, I didn't read RFC 6809 section 6.3.2

Whatever you think is best.

> We should probably add some words about that to the NAT Considerations

I think it's more complicated than that.  Actually, I don't know the
details of how NAT compensation is done; at least in some systems, the
edge proxies modify requests and responses in some circumstances.

But in this situation, when a UA is awakened, it seems to me that in
some architecures have to acquire a new IP address, having been asleep
and not been using one for a while, possibly hours.  In that case, the
Contact URI it generates for the REGISTER may contain a different IP
address than the one it registered with previously.

When I made my earlier comments, I assumed that it was the
proxy-redirector that was buffering the incoming request, and so it knew
not only the request but the contents of the registration record that
was redirecting the request.  This makes recognizing the incoming
REGISTER much simpler, as I said, it can be done in several ways.

However, you're looking at the more difficult case where redirection has
already been done, and the proxy handing SIP-push doesn't have the
registration record.  It doesn't even know the AOR the request was
originally targeted to!  (Which would let it look up the registration by
querying the registrar.)

> I think it is still good to also compare the IP address:port of the URI,

Conveniently the pn-provider/pn-prid combination is unique across all
registrations.  (Or is there a use case where one or more UAs use one
PRID to get wakeups for multiple AORs?)  I do think, though, we don't
want to depend on the IP address being maintained during sleeping.

Unless we know that the IP address in question is the one that the push
notification service is using to wake up the UA, and we know that the
push service reqires the device maintain a constant IP address.

I'm quite nervous about requiring the UA to be able to reregsiter using
the same IP address; not only does that limit NAT compensation
strategies (which may not be a problem) but it also requires the
environment not reassign addresses while devices are sleeping.  But
matching based on PRID alone requires that when a device receives a
wakeup, the UA(s) that are using that PRID for SIP-push for AOR(s) must
reregister all of those AORs.  (A single UA handling multiple AORs for
one domain can reregister them both with one request.)  I think that
behavior is what we expect anyway.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 08:56:32 +0000

Hi,

First, in our experience the UA does not change its IP address between "wake ups".

Having said that, the mechanism does not require the UA to maintain its IP address. If the proxy is the registrar, and the reregister contains a new IP address, the proxy will simply set the R-URI of the request accordingly. That is normal registrar behaviour.

Regards,

Christer

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: 18 February 2018 21:48
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Dale's reivew

Christer Holmberg <[email-masked]> writes:
> Note, though, that I changed it in the latest version. Do you want me 
> to change it back?

> The NAT will not change the contact URI in the REGISTER. The proxy 
> will obviously have to stored request towards the NAT address, from 
> where it received the REGISTER, but it will use the contact URI for the matching.

I think it's more complicated than that.  Actually, I don't know the details of how NAT compensation is done; at least in some systems, the edge proxies modify requests and responses in some circumstances.

But in this situation, when a UA is awakened, it seems to me that in some architecures have to acquire a new IP address, having been asleep and not been using one for a while, possibly hours.  In that case, the Contact URI it generates for the REGISTER may contain a different IP address than the one it registered with previously.

When I made my earlier comments, I assumed that it was the proxy-redirector that was buffering the incoming request, and so it knew not only the request but the contents of the registration record that was redirecting the request.  This makes recognizing the incoming REGISTER much simpler, as I said, it can be done in several ways.

However, you're looking at the more difficult case where redirection has already been done, and the proxy handing SIP-push doesn't have the registration record.  It doesn't even know the AOR the request was originally targeted to!  (Which would let it look up the registration by querying the registrar.)

> Well, pn-provider/pn-prid are part of the URI, so by comparing the 
> contact URI with the R-URI you DO use those :)
>

Conveniently the pn-provider/pn-prid combination is unique across all registrations.  (Or is there a use case where one or more UAs use one PRID to get wakeups for multiple AORs?)  I do think, though, we don't want to depend on the IP address being maintained during sleeping.

Unless we know that the IP address in question is the one that the push notification service is using to wake up the UA, and we know that the push service reqires the device maintain a constant IP address.

I'm quite nervous about requiring the UA to be able to reregsiter using the same IP address; not only does that limit NAT compensation strategies (which may not be a problem) but it also requires the environment not reassign addresses while devices are sleeping.  But matching based on PRID alone requires that when a device receives a wakeup, the UA(s) that are using that PRID for SIP-push for AOR(s) must reregister all of those AORs.  (A single UA handling multiple AORs for one domain can reregister them both with one request.)  I think that behavior is what we expect anyway.

Dale