Subject: Re: [sipcore] Comments regarding sip-push registration - pull request

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Dec 2017 12:22:41 +0000

Hi,

I've created a pull request, which points out that a re-registration needs to be triggered early enough in order for the re-registration request to reach the registrar before the registration expires.

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

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 27 December 2017 21:27
To: Dale R. Worley <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] Comments regarding sip-push registration

Hi,

>> The interval will be based on the registration expiration.
>>
>> And, similar to the UA wakeup behaviour you mention, the push 
>> notification should be triggered prior to the actual registration expiration.
>
> You need to explain this behavior completely.  It seems that the UA is 
> likely to depend on it, but in order for the UA to do that, it has to 
> have a clear specification as to how the registrar will perform these wake-ups, and precisely *when* they will happen.

I don't think we need to mandate how the wake-ups are triggered, because there are different ways of doing that. If the proxy triggering the push notifications is not part of the registrar, there needs to be A way for it to know when to trigger the push notifications.

I can add text pointing out that the push notifications triggering the re-registrations need to be triggered before the registration expires (eventhough a UA sending re-register before registration expiration as such that is normal SIP behavior).

>>> The usage of URI parameters will make the deployment easier as it 
>>> does not mandate updating the registrars (unless the push 
>>> notification
>> triggering will be done by the registrar, of course). Also, unlike 
>> some of the proprietary ideas I have seen, it does not mandate 
>> intermediaries to modify the REGISTER and/or the contact, etc.
>>
>> In some environments 'adding another table' can be a very big task.
>>
>> As the schedule for deploying this is very tight in many cases, there 
>> is a strong wish from the industry to be able to deploy this without 
>> having to update the registrar.
>
> OK, but you don't have to muddy the documented wire protocol to 
> support unmodified registrars, because the proxy can compensate for that.  And you're already expecting to modify the proxy.

A proxy processing URI parameters (triggering the push notifications etc) is much less impact than the registrar having to be able to store new header parameters: in 3GPP networks that would most likely impact the HSS, the interface between to the HSS etc - thing would require much more standardization.

In addition to being a standardized solution (in addition to different proprietary solutions people are looking at), the solution has been sold as easy to implement, as it does not impact the registrar, user databases etc. I really hope we can keep it that way.

Regards,

Christer

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