Subject: Re: [sipcore] Draft new version: sip-push-13

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Jun 2018 08:21:49 +0000

Hi,

It is now 2 weeks since I sent my reply.

I¹d really like to move the document forward.

Regards,

Christer

On 21/05/18 10:01, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>>> I suggest to remove the second paragraph, talking about maintaining
>>> connections with keep-alives. Will that make things more clear?
>>
>> Maybe I should state this differently.  You have an ample problem
>>statement, but what you don't
>> have is a *solution* statement.  That is, an explanation of the model
>>you are using to address that problem.
>
>Doesn't the 4th paragraph of the Introduction address that?
>
>>>>> The primary mechanism in this document is an augmentation of UA
>>>>> contact details. If you think of it that way, the lack of
>>>>>reachability is the
>>>>> exceptional condition.
>>>> The primary mechanism is to wake up suspended UAs, in order to
>>>> maintain registrations and provide reachability. That was the
>>>>original use-case that
>>>> triggered the whole document.
>>>
>>> The possibility to indicate that a UA is able to maintain
>>>registrations,
>>> but still want to receive push notifications for incoming calls, was
>>>added later.
>>
>> How the document got to where it is doesn't matter so much as where it
>>is now.
>
>In my opinion it is still the main use-case, and I think we shall keep it
>that way: the default is that the UA can not awake , and any exception
>can then be explicitly signalled.
>
>>> The purpose is that, if the UA has indicated that it is able to
>>>maintain the registration, but for whatever reason
>>> does not send a re-registration, the proxy can still trigger a push
>>>notification prior to registration expiration.
>>
>> Yes, that is clear.
>>
>>> Do you want to remove that feature, and assume that UAs that have
>>>indicated that they are able to maintain the
>>> registration will actually do it (and, if they don't, the registration
>>>will expire)?
>>
>> I'm suggesting that - when framed as a mechanism to ensure continuous
>>reachability, it is better to make the
>> time relative to the time of registration rather than relative to the
>>end of registration.
>
>So, what do you suggest?
>
>Regards,
>
>Christer
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jun 2018 07:51:39 +0000

Can we please move the draft forward now?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Jun 2018 19:52:08 +1000

Do as you will.  I apologize for not responding, it's clear that we're
not speaking the same language, but it's not that important.
On Mon, Jun 18, 2018 at 5:51 PM Christer Holmberg