Re: [sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-20 - Ben's technical comments

[Ben Campbell <[e-mail]>]

Thanks for the quick response! More inline. I removed sections that seem to be resolved.

Ben.

> On Nov 30, 2018, at 9:50 AM, Christer Holmberg <[e-mail]> wrote:
> 

[...]


> 
> ---
> 
>> §4.1
>> 
>>   - General: When we speak of multiple bindings, and doing something to all of those bindings (e.g. refreshing
>> them on a push-notification), is it allowable for a UA to have some bindings that use a PNS and some that do not?
>> Or perhaps some that use different PNSs? I realize that may not make sense for the mobile device use case that
>> seems centric to this draft, but I can imagine a situation where a complex UA might have different PNS configurations f
>> or different network paths and/or different SIP services.
>> 
>> If you want to assume that the PNS configuration is the same for all contacts, please say so explicitly. If not, does it
>> make sense to scope PNS-triggered refreshes to just those bindings that use the same PNS configuration?
> 
> I don't think there is any technical reason to mandate usage of the same PNS (or using PNS to begin with) for all contacts, so I don't think we need to forbid it.
> 
> We could say something like: "The procedures in this section apply to bindings associated with a given PNS."
> 
> I don't think we need to say more than that.

That works for me.


> 
>>   -2nd paragraph:
>>   I don't think we can assume that all UAs will always learn all the bindings they need to to setup at the same time.
>>  For example, a UA might have changes in network configuration that require them to add or remove bindings. This
>>  makes it impractical to register them at the same time and always use the same expirations, unless we ask them to
>>  refresh all existing bindings whenever they add a new one. (Or perhaps ask them to set the expiration of any new
>> binding to match the remaining time for existing ones, but that seems like a more difficult approach.)
> 
> I don't think the text assumes that the UA is aware of all bindings at the same time - it only says that it should use the same 'expires' value for each binding.

That depends on whether you consider “Expires” to be the time remaining until expiration, or the Expires header (or parameter) on a specific Register request. For example, if I register contact “A” with an expiration of 2 hours, and then register contact “B” an hour later, it would need to have a 1 hour expires value in order to expire at roughly the same time.

> 
>> -6th paragraph: "REGISTER request will create NAT bindings..."
>> 
>>   If we talk about creating NAT bindings as one of the purposes of the push-triggered REGISTER, we may also need to
>>   think about the lifetime of those nat bindings, and how that interacts with the REGISTER expires value. I'm not sure we
>>  want to go there; would it make sense to remove the mention?
> 
> I am not sure that is needed in the context of PUSH, since the NAT bindings only need to be alive in time for the request that triggered the push notification to reach the UA. Next time there is an inbound SIP request, the REGISTER triggered by the push notification associated with the request will create a NAT binding (if the previous one has expired) for that request.

A one line comment to that effect would be helpful.

> 
>>   - 7th paragraph:
>>   --  The first sentence seems to still assume the REGISTER has as single contact. Should it say to insert the tag into each
>> contact header field? (but see general §4.1 comment above.)
> 
> What sentence are you referring to?

Sorry, it’s the 8th paragraph: "If the UA is able to send binding refresh REGISTER requests using a
non-push mechanism (e.g., using an internal timer that periodically
wakes the UA), the UA MUST insert a ’sip.pnsreg’ media feature tag
[RFC3840] in the Contact header field URI of each REGISTER request"

[...]

> ---
> 
>>   §5.3.1:
>>   - 4th paragraph: Section 4.1 talks about the UA paying attention to sip.pns in a 2XX response. It does not mention
>>  it for other result codes. If the UA needs to pay attention to it in 423 (or in any other response), it should be mentioned there.
> 
> There are no push-specific UA actions for non-2xx responses.
> 
> If the UA receives a 423, it follows normal SIP procedures. Even if the proxy has inserted 'sip.pns' feature-capability indicator in the 423 response it only provides information about the PNS(s) supported by the proxy. It does not mandate push-specific UA actions.

You are right, or course. Nevermind :-)

[...]

> 
> ---
> 
>> §5.3.2, 2nd paragraph: Please mention that the R-URI will only contain these parameters after it is retargeted. This mostly
>> matters if the push-proxy is colocated with a retargeting proxy; retargeting must happen before this procedure.
> 
> Section 1 says:
> 
>   "The proxy MUST be in the signalling path of REGISTER requests sent by
>   the UA towards the registrar, and of SIP requests (for a new dialog
>   or a stand-alone) forwarded by the proxy responsible for the UA's
>   domain (sometimes referred to as home proxy, S-CSCF, etc) towards the
>   UA.”
> 

Okay

>> Along those lines, what is the PUSH proxy expected to do with inbound SIP requests that do not contain the parameters
>> in the R-URI? Route them normally? Reject them?
> 
> I think that is an implementation issue. If the proxy also handles non-PNS calls, it would forward the request using normal procedures.
> 

A brief mention of that would be helpful.

> ---
> 
>>   §6: Is support for push-notifications on mid-dialog requests optional? If so, please state that up front.
> 
> If one wants to support longlived SIP dialogs, one obviously will have to implement section 6. I am not sure we need to say something.

I’m more concerned about whether an implementation can choose _not_ to support long-lived dialogs. I assume so since there’s a separate negotiation. All I’m looking for is the word “optional” somewhere early in the section :-)


> 
> ---
> 
>>   §6.1.1: Does the UA indicate support on a per-dialog basis? That is, it can support the mechanism for some dialogs but not others?
> 
> It could be per-dialog basis. The text says: "if the UA is willing to receive push notifications triggered by incoming mid-dialog requests”.

I assume that if the UA indicates support in one dialog-initiating transaction but not another, that the proxy should not assume that it supports mid-dialog push in both transactions. If that’s a correct assumption, it would be helpful to explicitly state it.

[...]

> ---
> 
>>   §9, 1st paragraph: We are talking about a specification that defines the parameter usage for the given PNS, not the PNS in it's entirety, right?
> 
> Yes. I suggest to say: "defines the usage of the associated PNS". Because, the parameter itself only identifies the PNS.
> 

You said “Yes”, which I take to agree that we don’t require a spec for the PNS itself, but then you said “defines the usage of the associated PNS”, which does sound like a requirement for a spec of the PNS itself. So I’m confused :-)

[...]