Hi Erkki, et al.
I hope you are enjoying your summer holiday. I'm assuming that Aki
and/or Miguel will join in the thread, per your other email.
I was hoping that François Audet would reply to the time-keepalive
part of this thread, but I will reply based on one of the use cases he
described to me. I will also talk a bit about keep-stun and
keep-crlf.
Comments inline.
On 6/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi,
I have today had a look into the fresh Outbound-09
to see how it addresses the keepalive issues in comparison
to the proposal I submitted originally in the beginning of
March and resent it yesterday.
My first questions are related to this statement:
Clients MUST support this CRLF keepalive.
If so, what is the value of promoting the TCP Keepalive within
SIP Outbound ? In which circumstancies an UA supporting TCP
Keepalive would instead select sending CRLF keepalive ?
If the server did not add "timed-keepalives", and the UA is happy with
the value of the TCP keepalive timers, then the UA can use TCP
keepalive.
Further on, I like this piece of text within Outbound-09:
The client needs to perform normal RFC 3263 [4] SIP DNS resolution on
the URI from the outbound-proxy-set to pick a transport. Once a
transport is selected, the UA selects a keepalive approach that is
allowed for that transport ...
That approach is elegant and consistent with RFC 3263.
But I still dislike these pieces of text:
... and that is allowed by the server based on the tags in the URI
from the outbound-proxy-set.
User Agents that form flows check if the configured URI they are
connecting to has a 'keep-crlf' URI parameter (defined in
Section 12). If the parameter is present and the UA is not already
performing keepalives using another supported mechanism, the UA can
send keep alives as described in this section.
User Agents that form flows, check if the configured URI they are
connecting to has a 'keep-stun' URI parameter (defined in
Section 12). If the parameter is present and the UA is not already
performing keepalives using another supported mechanism, the UA can
periodically perform keepalive checks by sending STUN [3] Binding
Requests over the flow as described in Section 8.
Outbound-09 suggests that configured proxy URIs could contain
'keep-crlf' or 'keep-stun' parameters, with which the UAs could
check whether the proxy supports the corresponding keepalive
mechanism before starting to send such keepalives. Instead of
all that I simply suggest using the 'ob' parameter for the proxy
URI to indicate that the proxy supports SIP Outbound and all the
keepalive mechanisms defined in SIP Outbound for those transports
the proxy supports according to DNS.
Rationale:
1. SIP Outbound anyway already mandates compliant proxies to
support all keepalive mechanisms (see section 5.4) so there is
no need to define separate flags for each of those mechanisms.
One single flag for Outbound support is sufficient indication.
2. The draft has already defined the 'ob' URI parameter and how the
proxy should use it. My proposal is to use the flag as defined
but additionally to bundle the semantics of separate keepalive
flags to this single 'ob' parameter.
3. The UA could check the presence of 'ob' parameter within the
proxy URI either
a) within its configured outbound-proxy-set; or
b) Path header received within 200 OK to REGISTER
(like suggested in section 8)
4. Simple is better: less flags to be introduced to IANA,
to the URIs or to the implementations. Resulting URIs
would also be shorter with this single and short parameter.
The 'ob' parameter is not appropriate if we continue to allow STUN
keepalives to be used without outbound. Christer requested this and
the WG agreed to move the STUN keepalive definition to a separate
section of the draft.
We could certainly change 'keep-stun' and 'keep-crlf' to just 'keep'
(for example), but we had consensus that supporting keepalives and
supporting outbound should be kept orthogonal. In addition, I think
using 'ob' in so many contexts would be confusing:
- in the first Path header it means that the first Edge Proxy added a flow token
- in the UACs Contact header it means that the UAC registered
successfully with outbound. The first Edge Proxy can use this as a
hint to add a flow-token to its Record-Route.
Then you propose to add this one:
- in the outbound-proxy-set URIs it means that keepalives are supported.
- in the topmost Path header returned after registration it means that
keepalives are supported
Having 'keep-stun' and 'keep-crlf' is merely historic and I support
merging these into a single 'keep' parameter if we have consensus to
do so.
Finally I do not find any value for the 'timed-keepalives'
parameter. It was agreed in IETF68 but I was not attending
the meeting and I have not seen the rationale for it anywhere.
For the proxy point of view what is the difference whether or
not the proxy URI contains this parameter ? If the parameter
is within the URI, the proxy can be sure that it receives
the keepalives with intervals defined in the spec but otherwise
the UA could select longer intervals. However the spec does not
specify any actions for the proxy to check how often it receives
the keepalive messages so what is the point to have such a URI
parameter ? Instead of that I would suggest dropping this
parameter and either:
This parameter was a compromise between folks who want the client to
be able to send whenever it likes (typically less often, to conserve
battery power for example); and folks who want their server to be able
to track liveness of their clients.
The spec does not define what a proxy using timed-keepalives would do
with this information, but below are some examples.
1) The UA is used in a call center. If a certain number of keepalives
are missed by a UA, the proxy assumes the UA could be down and only
forwards calls to that agent when no "live" clients are available.
2) If several keepalives are missed, the proxy declares the UA down
and deletes the flow.
3) Associated with the proxy is a management station that shows the
status of each UA connected to it.
I am not trying to argue for including these features. I am just
providing an explanation of what folks might do with this parameter.
I would like to point out that this only works if the EP and the
registrar are coordinated at least via configuration. A simple way to
do this in a cross-domain environment would be for the EPs to include
;keep in the outbound-proxy-set and for the registrar to add
;timed-keepalives to the Path header for the EP.
a) mandate the UA always to use timers as defined in the draft
or
b) let the UA always to choose any timer values it wants to use
and make the timer values in the draft as recommendations
Choice a) certainly does not work well for battery operated devices,
and choice b) does not enable the use cases I described above.
Option b) could be better if the UA later on has some
mechanism (like STUN extension etc.) to ask the middleboxes
to adjust their timer behaviour.
Discovering the topology between the UA and the EP is easy 90% of the
time and practically impossible 1% of the time. The problem is that
the UA can't tell which situation it is in. Consequently, I won't hold
my breath for a deterministic solution to middlebox timer
configuration.
Example of URIs for a proxy supporting all keepalive methods:
Outbound-09:
sip:pri.example.com;lr;keep-stun;keep-crlf;timed-keepalives;ob
My proposal:
sip:pri.example.com;lr;ob
Your first URI isn't quite correct. If your proxy has no interest in
timed-keepalives, then it would omit the parameter. The 'ob'
parameter does not appear in the outbound-proxy-set. If we
consolidate keep-stun and keep-crlf, the situation looks pretty good.
outbound-proxy-set:
sip:pri.example.com;lr;keep-stun;keep-crlf OR
sip:pri.example.com;lr;keep
Path:
sip:pri.example.com;lr;keep-stun;keep-crlf;ob
sip:pri.example.com;lr;keep;ob
I don't think this is quite as daunting.
thanks,
-rohan
Just guess why I prefer the latter ;-) Any comments ?
Regards,
Erkki
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
