Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests - Pull request

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2018 13:52:58 +0000

Hi,

I have created a pull request, which now adds a new feature-capability indicator, sip.reqpush, which can be used:

  1.  By the UA to indicate that it is able to generate re-registration REGISTER requests without receiving push notifications
  2.  By the proxy to indicate the minimum time, prior to registration expiration, when the UA needs to send the re-registration REGISTER request.

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

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 15 February 2018 at 08:55
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, Dale Worley <[email-masked]<mailto:[email-masked]>>
Cc: Mickey Arnold <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests

Hi,

Or, we could change the text:

"It is RECOMMENDED that the proxy requests the push notification at least 10 seconds before the registration expires."

to:

“The proxy SHOULD NOT request a push notification earlier than 10 seconds before the registration expires, in case the UA is able to awake using a non-push mechanism in order to send a re-registration REGISTER.”

That means the UA can send it’s re-registration REGISTER whenever it wants, as long as it does it earlier than 10 seconds before the registration expires. We could make the number a little larger, though, e.g., 60 seconds.

But, if people want a way for the proxy to explicitly indicate the min value to the UA, we can for sure add e.g., a feature-capability indicator for that.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Thursday 15 February 2018 at 05:31
To: Dale Worley <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Mickey Arnold <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests

On Wed, Feb 14, 2018 at 10:25 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps also a parameter which is the UAs request for how long before
registration expriation it will need a wake-up in order to ensure that
it can re-register.

I have been asking for the same thing in my comments, but it still was not added.
_____________
Roman Shpount

---

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

Christer Holmberg <[email-masked]> writes:
> I have created a pull request, which now adds a new feature-capability
> indicator, sip.reqpush, which can be used:
>
>   1.  By the UA to indicate that it is able to generate
>   re-registration REGISTER requests without receiving push
>   notifications
>   2.  By the proxy to indicate the minimum time, prior to registration
>   expiration, when the UA needs to send the re-registration REGISTER
>   request.

Christer Holmberg <[email-masked]> writes:
> If the UA decides what the value shall be, then we could use a pn-
> parameter. But, the proxy should not modify the pn- parameters, as it
> would mess up the URI matching.

I think the problem we are facing has three parts:

1. The network needs a certain amount of time between when the UA sends
   the REGISTER before the reregistration is effective.

2. The UA needs a certain amount of time between when it receives the
   push notification and when it can transmit the REGISTER.

3. The network needs a certain amount of time to generate the
   push-notification request, send it to the push notification service,
   and the push notification reaches the UA.

The architectural problem is that the network knows items 1 and 3, and
the UA knows item 2.  If the UA generates reregistrations itself, it
needs to know 1 and 2.  If the network prompts the UA to generate
reregistrations, it needs to know 1, 2, and 3.

sip.reqpush takes care of the case where the UA generates
reregistrations spontaneously, by telling the UA item 1.

But we still need a mechanism to handle the other case, when the network
has to prompt the UA, and the UA has to tell the network item 2.  So I
think we need a complementary feature-cap indicator that the UA attaches
to the REGISTER that tells the network that it is not capable of
reregisering spontaneously, and what length of time it needs to generate
REGISTERS.

There's a choice in exactly how we define item 2, whether it includes
the inherent delay of the push notification service or not.

   the time between when the UA receives the push notification and when
   it transmits the REGISTER

vs.

   the time between when the push notification service receives the push
   notification request and when the UA transmits the REGISTER
  
In the first case, the network needs to know the delay in the service;
in the second case, the UA needs to know the delay in the service.
However, both the UA and the network are likely to have specific
knowledge of the service, so it seems to me that either choice would
work.

Dale

---

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

Hi,

> The architectural problem is that the network knows items 1 and 3, and the UA knows item 2.  
> If the UA generates reregistrations itself, it needs to know 1 and 2.  If the network prompts the 
> UA to generate reregistrations, it needs to know 1, 2, and 3.
>
> sip.reqpush takes care of the case where the UA generates reregistrations spontaneously, by telling the UA item 1.
>
> But we still need a mechanism to handle the other case, when the network has to prompt the UA, and the UA 
> has to tell the network item 2.  So I think we need a complementary feature-cap indicator that the UA attaches 
> to the REGISTER that tells the network that it is not capable of reregisering spontaneously, and what length of 
> time it needs to generate REGISTERS.
>
> There's a choice in exactly how we define item 2, whether it includes the inherent delay of the push notification service or not.
>
> In the first case, the network needs to know the delay in the service; in the second case, the UA needs to know the delay in the service.
> However, both the UA and the network are likely to have specific knowledge of the service, so it seems to me that either choice would work.

Of course there will be "delays", and the proxy needs to take that into consideration.

Regards,

Christer