Hi Erkki,
I think you got a good point. I don't know what is behind the "keep-"
parameters. But I don't see a real value using these parameters either. I agree
with you with your approach. Here is some more comments.
First, if the proxy supports all three kinds of keep alive mechanism, the
client is free to choose the one that it supports. Then the keep-parameter is
not useful.
Second, the client should be able to detect if it's behind a firewall or not
(by rport). The client may not send any keep alive packet if it's not behind
any firewall. In such case, the configuration with "keep-" parameter would only
introduce confusion.
Third, if the protocol can solve the problem automatically, it would be
better not to introduce any configuration. Right now, there are too many
configurations already to deploy on any SIP set.
Fourth, similar to the ";transport=udp" parameter which does not need to be
configured in any sip set explicitly if the UA can resolve the transport type
by using NAPTR/SRV (RFC3263). Therefore again, it's not necessary to configure
";keep-xx" parameter if the proxy supports all of them.
Jerry
[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 ?
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.
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:
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
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.
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
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
---------------------------------
Shape Yahoo! in your own image. Join our Network Research Panel today!_______________________________________________
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
