Hi Aki,
Don't shoot the messenger ;-)
I think most of our disconnect here is based on the ability to do
keepalives outside of outbound.
We had consensus to make the document so someone could implement STUN
keepalives over UDP that does not implement outbound. This
motivated the keep-stun URI parameter, later merged into the keep URI
parameter.
Since the correct keepalive responses are required by the first hop
when doing outbound, the UAC *could* infer the ability to send
keepalive pings and receive pongs based on the a successful outbound
registration working over the same flow.
We could get rid of the keep parameter for outbound registration and
only use it in non-outbound keepalive uses (and move the definition
to section 8), but we would need to get the consensus of the WG to do
that.
More brief comments inline...
On Dec 3, 2007, at 1:41 AM, Aki Niemi wrote:
Inline.
la, 2007-12-01 kello 12:59 -0800, ext Rohan Mahy kirjoitti:
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.
Huh? Sending the pong is mandatory.
if the implementation supports outbound. (see above)
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.
How about Flow-Expires: 120
I like it, but we need consensus to switch to that.
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.
I remember some very wise advice on these sorts of things: a spec is
ready only when there are no non-critical features left to remove.
I think this is definitely one such feature. More below.
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.
You mean could, SHOULD, or MUST?
whether the parameter is there or not is a by product of where it
appears (in which URIs). depending on where the URI came from , it
gets copied to various places. outbound does not change those rules.
</snip>
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.
Again, what purpose does the keep parameter then server?
again, we would need to agree to assume that an outbound registration
is "good-enough". This is certainly safe for any server that
correctly implements the spec.
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.
We don't have that today. In fact, today we have a one hour
re-registration interval, and I don't see a lot of people complaining.
Certainly, the UA can use something short (like 2
minutes) for one flow, and 14 minutes for any additional flows
without many ill effects.
2 minutes is too short. It drains the battery. Do you think having an
additional flow in addition to the 2-minute flow will improve the
situation?
I'm not the one you need to convince here. ;-)
thanks,
-rohan
_______________________________________________
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
