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

[Rohan Mahy <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip