Hi Aki,
My comments inline...
On Aug 6, 2007, at 4:16 PM, Aki Niemi wrote:
Here are my WGLC comments to sip-outbound-10. There may be
duplicates as
I've only been following others' comments on the surface.
---
#1 First, the title says:
Managing Client Initiated Connections in the Session Initiation
Protocol
(SIP)
yet, the draft is really about managing registrations, with
failover and
reliability. For example, it is not at all clear how one would go
about
implementing these techniques in, say, subscriptions (this is the
issue
Markus brought up recently with the config-framework)
In outbound-11 I think I have addressed this issue. The UAC can
include an 'ob' parameter in a dialog-forming request and expect the
first hop proxy to record route appropriately. This should allow the
sip config package subscription to work.
#2 URI parameters are confusing.
o First, I don't understand why the keepalive params are needed at
all.
It's simple, really: if the UAC opens a TCP flow, it needs to use
CRLF.
If it opens a UDP flow, it needs to use STUN. Or am I missing
something?
we merged the keep-stun and keep-crlf into a simple 'keep' parameter.
this 'keep' parameter just allows the UAC to know if it will get a
pong in response to its pings.
(In fact, I would like to see TCP-keepalives removed completely, as
that
just hurts interop.)
removed
o Justification for 'timed-keepalives'
Why does the UA need to know beforehand that it needs to use the
default
interval keepalive? Could this not be returned in the 200 OK instead?
it probably could, but it is not clear where it would go in the 200 OK.
All in all, I don't see the reason that these parameters need to be
pre-configured to the UA as the draft suggests. Seems they are either
self-evident (based on transport), or something the registrar/edge-
proxy
could return in a header field or parameter at register-time. Much
cleaner IMHO.
what we have may be ugly, but it will work and we appear to have
consensus on it.
o In 3.2. example message:
REGISTER sip:example.com;keep-crlf SIP/2.0
Why does this parameter need to be in the R-URI?
the parameter does not need to be there. It could instead be in the
topmost Route header for example.
o In 4.3. says:
The UAC MUST also include an "ob" parameter in the
Contact URI if, and only if, the UAC is sending the request over a
flow for which the Registrar applied outbound processing.
Isn't 'ob' only inserted by edge-proxies, and to Path? Furthermore,
how
can the UA know that "the Registrar applied outbound processing" to a
flow that is just about to be formed?
ob is used for two things:
- inserted in Path by the first edge proxy
- added to Contact by UA to request record-routing
o In 5.3 says:
The Edge Proxy can use
the presence of the "ob" parameter in the UAC's Contact URI to
determine if it should add a flow token.
Hmm. I thought it was the reg-id.
The edge proxy uses the presence of the reg-id in a Contact in a
REGISTER request to add a Path header with a flow token, and the
presence of the ob parameter in a Contact in a non-REGISTER request
to add a Record-Route header with a flow token.
#3 Implementation strategy
How is it intended that outbound support be added to a typical single
registrar/proxy deployment today? The spec intentionally leaves
configuration of a proxy-set open, but somehow assumes that one exists
in order to use outbound. Couldn't the UA just attempt a REGISTER via
the default NAPTR/SRV and just include reg-id and instance-ID? This
option should be made the default in the absence of a specific a
priori
configuration in Section 4.2/4.3.
This should just work, but the single UA/proxy would need to return a
Path header, otherwise the UA would have no way of discovering
support for keepalive responses.
#4 Keepalive timer values
Like I've said in the past that 2 mins for TCP is way too low.
Sure, the
UA can extend it, unless of course the proxy mandates it with
timed-keepalive param. And of course the proxy wants high reliability,
which means the UA is hosed probably more often than it would like
to ;)
My question is: where did this 2 minutes come from? Is it based on
some
hard data, like empirical evidence or user experience studies?
No. It was pulled out of thin air.
If not,
how about 14 minutes instead? Much better on the battery and should
still play nice with the NATs.
There was some expectation that the UA would be willing to lose 2
minutes of phone calls, but 14 minutes would be a lot of time to be
off the air. Certainly, the UA can use something short (like 2
minutes) for one flow, and 14 minutes for any additional flows
without many ill effects.
#5 Retry timer calculation formula
In 4.5:
wait-time = min( max-time, (base-time * (2 ^ consecutive-
failures)))
These times MAY be configurable in the UA. The three times are:
o max-time with a default of 1800 seconds
o base-time-all-fail with a default of 30 seconds
o base-time-not-failed with a default of 90 seconds
But there are only two unknowns pertaining to time in the equation
(there is no base-time-all-fail, or base-time-not-failed -- just
base-time that apparently is 30 sec...).
I made this more clear in -11. The base time is either 30 secs or 90
secs.
#6 Definition of a ping or a pong
It should be explained in the spec that a ping is double CRLF, or any
other traffic. And same goes for a pong. I.e., the UA should only
consider a flow dead if it receives no CRLF nor any other traffic
within
10 seconds of sending the ping.
this does not work. receiving some other traffic does not count as a
pong since it could be very stale data.
#7 Very minor things:
o The justification for choosing STUN as the UDP keepalive
mechanism is
a little misleading. It was *claimed* that STUN would be less of a
load
to proxies than a SIP OPTIONS (or similar). However, this was never
proven in practice. There were also people saying that parsing SIP is
not the bottleneck -- network or memory I/O is, and on that front,
STUN
and SIP are equal. If anything, a SIP+STUN parser might actually have
worse performance. Just for the record -- I've no interest to revisit
the decision -- just getting the facts right ;)
Hear, hear! I toned this rhetoric down a bit.
o In 3.3
The UA is configured with multiple outbound proxy registration URIs.
These URIs are configured into the UA through whatever the normal
mechanism is to configure the proxy or registrar address in the UA.
The registrar address is not supposed to be configured. It is learned
from the AoR, the name behind the '@' sign. ;)
yeah.
thanks,
-rohan
That's all
Cheers,
Aki
ext DRAGE, Keith (Keith) wrote:
A reminder of the ongoing WGLC on the above document
This WGLC period runs through IETF and hopefully close August 6,
2007.
That gives you about a week after the end of IETF - please
schedule some time for doing this.
Regards
Keith
-----Original Message-----
From: Dean Willis [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 12, 2007 7:14 PM
To: Dean Willis
Cc: [email protected]; Cullen Jennings; DRAGE, Keith (Keith)
Subject: Correction: WGLC for draft-ietf-sip-outbound
Dean Willis wrote:
I'd like to start a long working group last call for:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt
My error. This should have referred to
draft-ietf-sip-outbound-10, not -09. It was busy working its
way through the posting system and I grabbed a pointer to the
wrong one.
Sorry about that, folks.
--
Dean
_______________________________________________
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
_______________________________________________
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
