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)
#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?
(In fact, I would like to see TCP-keepalives removed completely, as that
just hurts interop.)
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?
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.
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?
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?
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.
#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.
#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? If not,
how about 14 minutes instead? Much better on the battery and should
still play nice with the NATs.
#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...).
#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.
#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 ;)
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. ;)
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
