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

[Peter Musgrave <[e-mail]>]

Thanks Christer,

Inline.

On Tue, Aug 3, 2010 at 7:47 AM, Christer Holmberg
<[e-mail]> wrote:
>
> Hi Peter,
>
> Some proposed new/modified text based on your comments.
>
>>>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."
Sounds good.
>
> --------------
>
>>Nits
>>1. s/Eventhough/Even though/
>>
>>1.3 "As specified in [RFC5626], usage keep-alives is not implicitly
>>negotiated for such flows, why usage needs to be explicitly
>>negotiated." Re-phrase?
>>
>>4.2.1 s/The section/This section/
>>
>>4.4 para 2. This paragraph is one sentence. I read it many
>>times - I gave up.
>
> I tried to make the paragraph more readable. It still contain a long sentence, but please let me know if it's easier to understand now:
-
>        "When a SIP entity creates or receives a response, and the adjacent downstream SIP entity that sent the associated request indicated
>        willingness to send keep-alives, if the SIP entity is willing to receive keep-alives associated with the registration (in case of
>        a REGISTER response), or the dialog (in case of a response to an initial request for a dialog, or a response to a mid-dialog
>        target refresh request), from the adjacent downstream SIP entity it MUST add a parameter value to the "keep" parameter, before sending
>        or forwarding the response. The parameter can contain a recommended keep-alive frequency, or a zero value."
Better - but I am still getting a stack overflow since I parse
"When... A or B ..and...if..or.."

How about:

If a request from a downstream SIP element indicated support for
keep-alives and the upstream element also supports keep-alives then
the response from the upstream element MUST contain a parameter value
for the "keep". This value can contain a recommended keep-alive value
or a zero value.

(I have cut out the stuff on what kind of request it is - I am not
sure if this distinction was vital?)
>
> Regards,
>
> Christer
>
>