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

[[e-mail] (Dale R. Worley)]

Christer Holmberg <[e-mail]> 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 <[e-mail]> 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