Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments

[Paul Kyzivat <[e-mail]>]

at end

Christer Holmberg wrote:
> Hi Paul,
> 
>>>>> I have read draft-ietf-sipcore-keep in detail for the first time.
>>>>>
>>>>> I have one questions and some Nits.
>>>>>
>>>>> Question: 7.3 Should the TRYING (not shown) from P1 to Alice have
>>>>> keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the
>>>>> NAT pinhole closes?
>>>> It is true that the flow only shows the 200 OK, but the text
>>>> in section 4.4 responses in general.
>>>>
>>>> I guess we could add some text that points out that the keep
>>>> value should be sent as soon as possible, as it may take a
>>>> while before the final response is sent.
>>> What about the following new text in section 4.4.
>>>
>>>       "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the
>>>       request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one of the responses. The
>>>       SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."
>> You really need to consider reliable and unreliable provisionals separately.
>>
>> Either restrict to reliable responses (provisional or final), or else
>> allow in unreliable provisionals preceding a reliable response. (Which
>> might get it going sooner.)
>>
>> As we have seen with o/a, allowing in unreliable provisionals introduces
>> complications, especially when changing values are used.
> 
> You are right. I was thinking about that, but must have forgot when I put the text together...
> 
> The text should say that the parameter needs to be inserted in at least one response that is sent reliably. I see no reason to forbid to, in addition, also include it in unreliable responses.
> 
> So, something like:
> 
>        "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the
>        request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one response that is sent 
>        reliably. The SIP entity MAY insert the parameter value also in other responses (relaible and unreliable) associated with the request. 
>       The SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."

You have to be very careful with the wording here.
(Speaking after bad experience with o/a.) The above doesn't say that the 
value must be the same if sent more than once, or what should happen if 
it is not the same. How about:

"A SIP entity receiving an initial INVITE request and wishing to 
indicate a willingness to receive keep-alives, MUST insert a "keep" 
parameter value in one reliable response to the INVITE. The SIP entity 
MAY insert an identical "keep" parameter value in other responses to the 
same INVITE. The SIP entity MUST NOT insert "keep" parameters with 
differing values in responses to a single INVITE. The SIP entity SHOULD 
indicate the willingness to receive keep-alives as soon as possible."

	Thanks,
	Paul