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

[Christer Holmberg <[e-mail]>]

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

Regards,

Christer