Subject: [sipcore] draft-ietf-sipcore-keep-04

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2010 12:44:31 -0400

Christer,

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:

    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.

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*?)

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

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?

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

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?
- if so, does this alter the procedures of outbound - requiring some
   manipulation of the Flow-Timer value?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Jul 2010 11:35:55 -0400

[I neglected to note that these comments were made as an individual]

Paul Kyzivat wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>