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

[Christer Holmberg <[e-mail]>]

Hi Paul,

>I finally got around to reading the keep draftfor the first time in
>quite awhile. I have a few comments and questions:
>
>IMO the usage of "upstream" and "downstream" (which is ubiquitous) is
>confusing, because its not evident which is the high ground and which is
>the low ground. Normally for SIP I would assume that the sender of a
>request is on the high ground, with the request flowing *downstream*
>toward the recipient, and the response flowing *upstream* toward the
>sender of the request. But most of the text in this draft assumes the
>opposite. Perhaps this stems from a view that the "device" is on the low
>ground and the registrar is on the high ground. But then 4.1 further
>complicates this:

After a first thought I probably agree with your comment that the request flows *downstream*.

I guess I could add some clarification text, to make it clear that "adjacent downstream" refers to the adjacent SIP node in which a request is sent.

>   NOTE: Usage of keep-alives is negotiated per direction.  If a SIP
>   entity has indicated willingness to receive keep-alives from its
>   adjacent downstream SIP entity, sending of keep-alives towards the
>   same SIP entity needs to be separately negotiated.
>
>If that negotiation were performed following the procedures in this
>draft then the upstream and dowstream roles would be reversed.

I guess the note could be re-written without the "downstream" wording:

"NOTE: Usage of keep-alives is negotiated per direction.  If a SIP
entity has indicated willingness to receive keep-alives from an
adjacent SIP entity, sending of keep-alives towards the
same SIP entity needs to be separately negotiated."

-----------------

>Section 4.2.2:
>
>IIUC, the keepalive is associated with a flow as defined in 5626. Hence
>it isn't appropriate to use this negotiation mechanism on a registration
>that doesn't specify a flow. I don't see that stated anywhere.
>
>(If there was no flow, what would the keepalive state be associated *with*?)

The second paragraph describes the case when outbound is used, and when you do have flows. 

The generic procedure is described in the first paragraph of the section, and it does not talk about flows - it talks about registrations.

-----------------

>Section 4.2.3:
>
>Is there a reason *why* you can't renegotiate the dialog to eliminate
>the use of keepalives? (session timers are a similar concept, and they
>are renegotiated on/off with every reINVITE/UPDATE.)
>
>(Maybe there is a good reason - I just don't see it.)

People thought that we shouldn't make things too complicated and heavy by allowing mid-dialog renegotiations - and especially not *mandating* a renegotiation with every reINVITE/UPDATE.

-----------------

>Section 4.3:
>
>The following:
>
>    When a SIP entity is about to send a keep-alive, if the SIP entity at
>    the same time is also about to send or forward a SIP request
>    associated with the same registration or dialog, for which the keep-
>    alive is to be sent, the SIP entity MAY choose not to send the keep-
>    alive, as the SIP request will perform the same keep-alive action.
>
>seems pretty imprecise. Wouldn't it be more precise to state that every
>request sent resets the clock for when a keep-alive needs to be sent?

I can use such wording instead, if people think it's better.

>Also, while this skipping of the explicit keep-alive makes sense to me,
>AFAICT it isn't consistent with -outbound-.

So, do you suggest that a SIP request should NOT reset the clock?

OR, would you like some note saying that, when keep-alives are implicilty negotiated as part of outbound, requests do not reset the timer?

-----------------

>Section 5:
>
>The following has me totally confused:
>
>   SIP Outbound uses the Flow-Timer header field to indicate the server-
>    recommended keep-alive frequency.  However, it will only be sent
>    between a UA and an edge proxy.  Using the "keep" parameter, however,
>    the sending and receiving of keep-alives might be negotiated between
>    multiple entities on the signalling path.  Since the server-
>    recommended keep-alive frequency might vary between different SIP
>    entities, those would have to re-write the Flow-Timer header field
>    value.  In addition, if a SIP entity does not indicate willingness to
>    receive keep-alives from its adjacent downstream SIP entity, and
>    receives a Flow-Timer header field in a response, it would have to
>    remove the Flow-Timer header field from the response.  This issue
>    does not exist for the "keep" parameter, as each SIP entity has its
>    own individual Via header field.
>
> (There are too many hypotheticals in it.)
>
>After reading this, I don't know:
>
>- can I use keep in conjunction with an outbound registration?

I think the draft currently does not explicitly say anything about that, but I think it would be good to add text saying that it is possible.

>- if so, does this alter the procedures of outbound - requiring some manipulation of the Flow-Timer value?

No. The usage of Flow-Timer with outbound is optional, so saying that it MUST NOT be used if the draft mechanism is not used does not break anything, in my opinion.

Thanks for your comments!

Regards,

Christer