At 12:44 29/02/2008, Klaus Darilion wrote:

I vote for "remove" and have it "on" always.

I never saw a reason for this parameter

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.

and always had it turned on.

klaus

Bogdan-Andrei Iancu wrote:

...

Hi,

I want to get some feedback from the users regarding one of the TM parameters: "noisy_ctimer" .

This parameter, is disabled, would try to let a call to ring for ever (openser will never give internal timeout). But, the parameter is automatically turned on (disregarding the script setting) in certain conditions: - parallel forking is done - a failure route is set - a failure callback is set by other module (like acc, cpl, dialog, etc) - a fr_invite timeout was configured via AVP - some reply was already received - no other module explicitly asked for this (like siptrace, acc,osp)

Following some discussion on the tracker, there is large support for removing this parameter as: 1) it is difficult to anticipate the final behaviour due complicated logic 2) due all dependencies, in 99% of the case, the param will be automatically turned on 3)it breaks the RFC3261, which make mandatory to have a final reply form a stateful proxy

My question is:

Is anybody having a good point in not removing this parameter (and having noisy_ctimer behaviour all the time)?

I'm pushing this question only on users list, as between the developers, there is an consent in removing it ;)

Regards, Bogdan

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

-- Jiri Kuthan http://iptel.org/~jiri/

At 15:33 03/03/2008, Anatoly Pidruchny wrote:

Jiri Kuthan wrote:

...

Maybe underdocumentation is the point why many folks seem to be excited by removal :-)

I do not think so. I think it should be removed because I do not know any reasons why you would not want to send CANCEL to the called party, but terminate the INVITE transaction in OpenSER and send 408 Request Timeout to the calling party when fr_inv_timer expires.

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

Again, what you are complaining about is not at all the fact that OpenSER sends or does not send CANCEL to the callee when fr_inv_timer expires. What you are complaining about is just the fact that a proxy can terminate the INVITE transaction.

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.

In case of OpenSER it happens when fr_inv_timer expires. The problem could be that somebody configured OpenSER with fr_inv_timer parameter that is too short for you. This is a different issue that has nothing to do with the noisy_ctimer parameter that is discussed in this thread.

...

This obstacle should be in theory removed in RFC3261 which allows 18x to extend the proxy server timer.

You can start a different thread if you want to discuss ways to increase fr_inv_timer somehow dynamically. As I said, this issue has nothing to do with noisy_ctimer parameter.

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.

...

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

So, do you vote to remove noisy_ctimer or not? From previous sections it looked like you are trying to defend keeping the noisy_ctimer parameter, but here you say that noisy_ctimer is a confusing hack and so you do want it to be removed.

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

...

p.s. the argument 3) is an oxymoron. By using noisy_timer the proxy becomes in fact stateless.

I do not understand what you are trying to say here. Are you saying that setting noisy_ctimer=1 somehow makes a proxy stateless?

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

Regards, Anatoly.

...

...

and always had it turned on.

klaus

Bogdan-Andrei Iancu wrote:

...

Hi,

I want to get some feedback from the users regarding one of the TM parameters: "noisy_ctimer" .

This parameter, is disabled, would try to let a call to ring for ever (openser will never give internal timeout). But, the parameter is automatically turned on (disregarding the script setting) in certain conditions:

• parallel forking is done
• a failure route is set
• a failure callback is set by other module (like acc, cpl, dialog, etc)
• a fr_invite timeout was configured via AVP
• some reply was already received
• no other module explicitly asked for this (like siptrace, acc,osp)

Following some discussion on the tracker, there is large support for removing this parameter as:

1. it is difficult to anticipate the final behaviour due complicated logic
2. due all dependencies, in 99% of the case, the param will be automatically turned on

3)it breaks the RFC3261, which make mandatory to have a final reply form a stateful proxy

My question is:

Is anybody having a good point in not removing this parameter (and having noisy_ctimer behaviour all the time)?

I'm pushing this question only on users list, as between the developers, there is an consent in removing it ;)

Regards, Bogdan

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

-- Jiri Kuthan http://iptel.org/~jiri/

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

-- Jiri Kuthan http://iptel.org/~jiri/

At 17:17 03/03/2008, Iñaki Baz Castillo wrote:

El Monday 03 March 2008 16:58:39 Jiri Kuthan escribió:

...

...

I do not think so. I think it should be removed because I do not know any reasons why you would not want to send CANCEL to the called party, but terminate the INVITE transaction in OpenSER and send 408 Request Timeout to the calling party when fr_inv_timer expires.

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.

Jiri, I assume you mean the section 16.7 of RFC 3261:

RFC 3261:

16.7 Response Processing

When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction.

 Forwarding responses for which a client transaction (or more
 generally any knowledge of having sent an associated request) is
 not found improves robustness.  In particular, it ensures that
 "late" 2xx responses to INVITE requests are forwarded properly.

---

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

But also note that this RFC 3261 behaviour is considered a bug (in fact a security bug). In fact there is a draft making it fix, and it changes the previous 16.7 section with this one:

http://tools.ietf.org/html/draft-sparks-sip-invfix-01#section-8.2

 When a response is received by an element, it first tries to
 locate a client transaction (Section 17.1.3) matching the
 response.  If none is found, the element MUST NOT forward the
 response.  If a transaction is found, the response is handed to
 the client transaction.

---

That's true, but I respectfuly disagree with this suggestion. Anyhow, at the moment it is merely an Internet Draft under discussion.

So, in case the Timer is expired in OpenSer it MUST drop any reply received after it.

By RFC3261 (and by my common sense), that's not the case.

-jiri

-- Iñaki Baz Castillo ibc@in.ilimit.es

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

-- Jiri Kuthan http://iptel.org/~jiri/

At 20:12 03/03/2008, Iñaki Baz Castillo wrote:

El Lunes, 3 de Marzo de 2008, Jiri Kuthan escribió:

...

...

http://tools.ietf.org/html/draft-sparks-sip-invfix-01#section-8.2

 When a response is received by an element, it first tries to
 locate a client transaction (Section 17.1.3) matching the
 response.  If none is found, the element MUST NOT forward the
 response.  If a transaction is found, the response is handed to
 the client transaction.

---

That's true, but I respectfuly disagree with this suggestion. Anyhow, at the moment it is merely an Internet Draft under discussion.

...

So, in case the Timer is expired in OpenSer it MUST drop any reply received after it.

By RFC3261 (and by my common sense), that's not the case.

Yes, but the fact is that many proxies implement this behaviour (same as the suggested in the draft) in some propietary/custom way. For example, what about OpenSer?

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.

In case the timer expires and OpenSer doesn't generate a CANCEL, will OpenSer forward stateless a future reply?

with the above reservation, yes.

Also, since OpenSer generated the "408 timeout", in the case the later 200 OK arrives to the caller it will be discarted, so...

in the silent mode, it neither sends a 408 nor a CANCEL. it just discards the transaction context.

-jiri

Best regards.

-- Iñaki Baz Castillo

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

-- Jiri Kuthan http://iptel.org/~jiri/

Jiri Kuthan wrote:

At 12:44 29/02/2008, Klaus Darilion wrote:

...

I vote for "remove" and have it "on" always.

I never saw a reason for this parameter

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)

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:

On Mon, Mar 3, 2008 at 2:06 PM, Klaus Darilion klaus.mailinglists@pernau.at wrote:

...

Jiri Kuthan wrote:

...

At 12:44 29/02/2008, Klaus Darilion wrote:

...

I vote for "remove" and have it "on" always.

I never saw a reason for this parameter

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)

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

Another workaround would be a timeout_route

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.

and there the admin can take a decision:

• drop the transaction, disable CANCEL generation and switch to stateless mode
• re-arm the timer and stay in statefull mode

Like this, the script has full control over the behavior of the server and no under the hood tricky mechanism is involved.

I like explicit control in this case esthetically better too.

-jiri

BTW: I would love to see this implemented for dialog timers :) http://sourceforge.net/tracker/index.php?func=detail&aid=1892203&gro...

Regards, Ovidiu Sas

-- Jiri Kuthan http://iptel.org/~jiri/

El Tuesday 04 March 2008 11:20:47 Bogdan-Andrei Iancu escribió:

Hi guys,

Thanks a lot for the valuable input. In my opinion,trying to summarize the discussion:

what we need is not to have a mechanism to ignore the C timer, but rather a better way to manage/control C timer.

This means:

1. dropping (after all) the "noisy_ctimer" as it proves to be more or

less a hack

2. add new feature to manage/control C timer (like onreply route change

support, different routes for timeout and failures, etc)..

Is this commonly agreed?

I agree.

On Tue, Mar 4, 2008 at 5:20 AM, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:

Hi guys,

Thanks a lot for the valuable input. In my opinion,trying to summarize the discussion:

what we need is not to have a mechanism to ignore the C timer, but rather a better way to manage/control C timer.

This means:

1. dropping (after all) the "noisy_ctimer" as it proves to be more or

less a hack

I'm all for it.

2. add new feature to manage/control C timer (like onreply route change

support, different routes for timeout and failures, etc)..

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

Is this commonly agreed?

It looks like.

Regards, Ovidiu Sas

On Thu, Mar 6, 2008 at 7:17 PM, Juha Heinanen jh@tutpro.com wrote:

Bogdan-Andrei Iancu writes:

...

2. add new feature to manage/control C timer (like onreply route change

support, different routes for timeout and failures, etc)..

Is this commonly agreed?

as long some backwards compatibility is retained, i.e., it should not be mandatory to split current failure route into failure and timeout route, for example.

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.

From my prospective, if timer C fires, the first hook will be in

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