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

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>> 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."

Looks good. I did some editorial changes, to allign with the style in the rest of the documents. I also changed the text a little, to make sure it doesn't look like an INVITE response is the only way of indicating willingess to receive keep-alives.

Also, I removed "initial", because the negotion could take place in a target refresh re-INVITE (assuming no negotiation has taken place before that).

How about:

"When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST insert a "keep" parameter 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."

Regards,

Christer