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