Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the COMMENT issues - part 3

[Eric Rescorla <[e-mail]>]

On Tue, Jan 8, 2019 at 4:50 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
> S 5.3.2.
> >>
> >>      If the proxy has knowledge that the UA is awake, and that the UA is
> >>      able to receive the SIP request without first sending a REGISTER
> >>      request, the proxy MAY choose to not request a push notification
> >>      towards the UA (and wait for the associated REGISTER request and
> 2xx
> >>      response) before it tries to forward the SIP request towards the
> UA.
> >
> >Why not race these?
>
> One could do that, but I don't think it should be mandated.
>
>
> >The current text prohibits racing if you *don't* know that the UA is
> awake.
>
> The basic assumption of the mechanism is that a UA cannot receive SIP
> requests before it has received the push notification, sent the REGISTER
> etc.
>
>
> >But that may or may not be true, depending on whether the device has
> gone to sleep
>
> Implementations can of course do whatever they want, but I think it is bad
> design to specify such behavior. Unless the request will reach the UA, some
> re-transmissions will be "wasted",
>

We trade off "wasted" transmissions for performance all the time. For
instance: RFC 6555.


and once the proxy receives the REGISTER the re-transmission timer might
> have become rather big.
>

Well, that's easy to fix by not incrementing the timer on these
transmissions.


But, perhaps we could say something like:
>
> "if the proxy has knowledge, or strong reasons to believe, that the UA is
> awake"
>
> An example of such strong reason is that the proxy received the previous
> REGISTER just a few seconds ago.
>

This text still seems to discourage this behavior, and I'm not in agreement
with you that we should do so.

-Ekr

Regards,
>
> Christer
>
>
> -Ekr
>
>
> Regards,
>
> Christer
>
>
>
>