At 12:44 29/02/2008, Klaus Darilion wrote: Maybe underdocumentation is the point why many folks seem to be excited by removal :-) Well -- with RFC2543 it could have been quite inconvenient for you to figure out that after say 90 seconds of early media (say on my favorite callee, German imigration office) you will be disconnected by a proxy server while stil in hope someone would answer for you. This is particularly annoying if the server in the path is playing a special purpose role (such as load-balancer) and surprises rest of the world with a CANCEL. this has been a real trouble in the field. This obstacle should be in theory removed in RFC3261 which allows 18x to extend the proxy server timer. (It goes back to the INVITE transaction as whole being misconcepted in the SIP protocol, but that's frankly not worth fixing now.) With that, my recommendation is to check behaviour of existing gateways before doing changes. (otherwise noisy_timer is undoubtably a confusing hack which if absent makes things simpler) -jiri p.s. the argument 3) is an oxymoron. By using noisy_timer the proxy becomes in fact stateless. -- Jiri Kuthan http://iptel.org/~jiri/

At 15:33 03/03/2008, Anatoly Pidruchny wrote: see bellow. Because it may be legitimate to have a very long call setup period (consuming memory), and you don't know in advance how long is long enough. Then, applying the "better-than-nothing" principle, it is beneficial to conserve memory and go stateless, rather than experiencing a stateful cancellation of transactions due to short timers or memory exhaustion due to long timers. A partial answer to this dilemma is the RFC3261 UAS-driven lifetime extension, which should help to extend the timer using recepient's knowledge. Well, you can't really separate those two since a proxy terminate the INVITE transaction when the fr_int_timer expires. There is no good timer length to be had. Sometimes for "on-no-reply" type-of-services, it may be susbriber-driven, sometimes like with the gateway example, it may be protocol-driven, in all cases it may have very different lengthes. ( higher than 5 minutes may be really useless for personal call forwarding, lower than 5 minutes may prohibit my calls to immigration office). Thus there are cases, when unsure about what length is long enough to keep callers happy and short enough to avoid memory exhaution (which is 100MB/min with full-stem traffic), you better silently drop the transaction context on hope to be able to complete pending call setups. To provide an approximation of what time is actually good (so that if the timer timesout you can feel safe to cancel the transaction), IETF came up with the UAS-driven timer extension as introduced in RFC3261. This is about what to do when the timer strikes, in particular when it strikes earlier than you hoped for. If you think that it is always reasonable to cancel on timer expiration (which I would second *if* UASs were RFC3261-compliant in this matter), there is no question. I hope you don't mind if I don't join this procedure as I am not a great fan of engineering by counting raised hands. Here is at least my suggestion so that folks interested in this process can create their own opinion. The suggestion is to look how devices interoperate today (particularly check if they respect RFC3261 and resend provisional responses for early media). If they comply, remove it, otherwise keep it. It is a RFC2543 backwards compatibility hack, if the backwards compatibility is no longer issue, it can be easily removed (which is really trivial to do -- the only trouble is possible interop issues). If folks don't know which is the case interop-wise, I think leaving things "as is" is proper answer: having it permamnently turned on doesn't really cause any harm, and those with interop issues can still turn it off. If it ain't broke, don't fix it exactly. Being stateful is not a software-related feature, it is a feature of a specific transaction at a given point of time. With noisy_timer the transaction context is silently dropped, and the transaction can still complete statelessly. There are cases when stateless completion is better than none. For example, load-balancers may loose stickeness but it is perceived as better if they complete without stickeness than if they fail. (OTOH, those who account from SER using transactional logic typicall prefer cancelled calls over incomplete CDRs.) Similar use-case is with different failover stories where both machines are still able to send traffic, and it is better if the newly-active machine completes a transaction statelessly, whereas the active-before doesn't disturb by sending CANCELs around. -jiri

At 17:17 03/03/2008, Iñaki Baz Castillo wrote: It is all about 16.7. The part that you are referring to states what to do if a proxy is stateless. I was merely referring to the bullet 2. Here it is suggested that a UAS can extend the C-timer. This allows the timer in proxy to be set to some reasonable maximum, whilst extending it on-demand by the callee. Callee should be in many cases in shape to know best, how long one shall still wait... Almost :-), I have been referring to a different part of the same section, 16.7. -------- 2. Update timer C for provisional responses For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes. --------- That's true, but I respectfuly disagree with this suggestion. Anyhow, at the moment it is merely an Internet Draft under discussion. By RFC3261 (and by my common sense), that's not the case. -jiri -- Jiri Kuthan http://iptel.org/~jiri/

At 20:12 03/03/2008, Iñaki Baz Castillo wrote: Unless it has been explicitely changed after its fork from ser, it forwards replies. (which has been knowingly put there so). BTW--I have posted a question to the SIP WG, I really think that at least MUST should be turned into SHOULD or even better informative documentation of what the alleged security risks are. But that's just FYI, IETF debates grow to be very lengthy. with the above reservation, yes. in the silent mode, it neither sends a 408 nor a CANCEL. it just discards the transaction context. -jiri -- Jiri Kuthan http://iptel.org/~jiri/

Jiri Kuthan wrote: I think there is no easy way to solve this. A workaround would be to increase the fr_inv_timer in the reply route (e.g. after getting a 183 response) - but I fear this would be difficult to implement. regards klaus

At 20:17 03/03/2008, Ovidiu Sas wrote: Yes -- actually I think it would be a clean step to separaate failure_route in failure_route handling negative replies and timeout_route. (cc-ing serdev thus too). Reseting the timer from there to comply to RFC3261 or executing some service (all kinds of haunting) or going stateless if desirable and possible would be few examples of meaningful actions to be done from there. I like explicit control in this case esthetically better too. -jiri -- Jiri Kuthan http://iptel.org/~jiri/

El Tuesday 04 March 2008 11:20:47 Bogdan-Andrei Iancu escribió: I agree. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

On Tue, Mar 4, 2008 at 5:20 AM, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: I'm all for it. I would like to leave onreply route as is and deal with timeouts in a timeout_route. It will keep things structured and organized. If I need to check something about a timer, it will be in a single place, not spread around my config (just my 2c). It looks like. Regards, Ovidiu Sas

On Thu, Mar 6, 2008 at 7:17 PM, Juha Heinanen <jh(a)tutpro.com> wrote: Adding a timeout_route doesn't imply that the backward compatibility will be broken. A timeout_route will deal with a timer, and not with a message (regardless if it's a locally generated one or a received one) like failure_route. timeout_route where the administrator can decide to re-arm the timer or not. The default action (i.e. no action taken in timeout_route), of course, will be to let the timer fire, and this it will generate a local 408 reply that will be handled in the failure_route, just like today. Like this, backward compatibility is fully retained. just my 2c Regards, Ovidiu Sas