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

[Christer Holmberg <[e-mail]>]

Hi,

>This text seems ok to me, though I haven't evaluated it in the context
>of the draft as a whole. We'll see how it all comes together.

Sure. I will put together a new version as soon as we seem to have a common view on the principles. It is then easier to do the editorial stuff once we have everything on the table.

Regards,

Christer


Christer Holmberg wrote:
> 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