Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound

[Aki Niemi <[e-mail]>]

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.

> > 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

> > 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?

</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?

> > 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?

Cheers,
Aki



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip