Hi,
OpenSER has a new type of route: local route. This route is to be executed when a brand new request is internally generated (openser being the UAC) ; such requests are result of : - t_uac_dlg MI command - msilo, sms, presence, cpl-c, dialog (and others) modules
Purpose ========
This need route was added to meet the need to do dynamic manipulation (do some checking, adding headers, logging, etc) of the internally generated requests; without this new route, these requests were totally transparent for the openser script.
Some strong cases there were debated for a long time on the lists:
- adding new headers into internally generated requests - so far all kind of hacks were used to do it (like defining module parameters with predefined headers to be added in the request - see presence modules)
- logging (log or xlog) information about the outgoing requests - see the discussion about the presence internal logging
- accounting - there was no way to account these requests (as accounting can be triggered only from script) - see the discussion around the dialog module for how to account the BYEs generated by this module
How to use ===========
there is a single instance of this route allowed in the configuration: local_route { ...... }
Note that not all the functions are allowed to be called from this route (better check the docs before)
Example:
local_route { .... if (is_method("NOTIFY")) { xlog("new $rm sent out for $ru via $du\n"); } .... if (is_method("BYE")) { acc_log_request("internal bye"); append_hf("X-note: terminated by dialog module"); } .... }
Limitations ============
- you can access RURI and destination uri ($ru and $du), but any change of these value will be discarded - you cannot change the destination of the request
- there is no transaction persistence (yet) - you cannot set onreply or failure routes, flags are not pushed into transaction ; this will be probably available in the next version.
- accounting via flags do not work - as this requires transaction persistence (see above)
Regards, Bogdan
On Friday 06 June 2008, Bogdan-Andrei Iancu wrote:
OpenSER has a new type of route: local route. This route is to be executed when a brand new request is internally generated (openser being the UAC) ; such requests are result of : - t_uac_dlg MI command - msilo, sms, presence, cpl-c, dialog (and others) modules [..]
Hello all,
the addition of this feature short before the code freeze caused some conflicts, which could not resolved sufficently in time for this release. Thus the OpenSER board was asked to decide in this matter. The majority of the board voted for decativating this feature in the 1.4 release series.
For more details please take a look at the developer mailing list at [1], [2] and [3]. Details about the "dectivate" commit can be found at [4]
The local route functionality is still available, but its not activated in the default installation. In order to use this feature its necessary to set the "USE_LOCAL_ROUTE" define in the "Makefile.defs" file and compile your own binary from the source. Then it will possible to use this feature.
In the 1.5.0 release this functionality (or something resemble this) will be present, fully usable and supported.
With best regards,
Henning Westerholt
[1] http://lists.openser.org/pipermail/devel/2008-June/014028.html [2] http://lists.openser.org/pipermail/devel/2008-June/014122.html [3] http://lists.openser.org/pipermail/devel/2008-June/014204.html [4] http://lists.openser.org/pipermail/devel/2008-June/014444.html
Hi everybody,
As Henning said, there was a voting and a decision on the management board and I would like to post my comments about how the board took this decision:
1) I personally had no opportunity to express a point of view and to explain the local_route case to the board. This decision was made in a huge hurry (posted on 24 of June and the decision was already taken on 25 of June, time when I was not available).
2) the debate had no technical base (only opinions with no arguments to sustain them). For me is clear that most of the board members did not understood all the technical implication of the issue they voted on, and they were influenced by "big empty words" opinions of other members. All technical arguments and explanation from the devel list were simply ignored.
3) by involving in this decision, the board exceeded its attributions - the board is incharged with the management responsibilities and not technical ones - http://www.openser.org/mos/view/Management/
I'm afraid I start to see a lack of self-respect and fair-play in this project.
Regards, Bogdan
Henning Westerholt wrote:
On Friday 06 June 2008, Bogdan-Andrei Iancu wrote:
OpenSER has a new type of route: local route. This route is to be executed when a brand new request is internally generated (openser being the UAC) ; such requests are result of : - t_uac_dlg MI command - msilo, sms, presence, cpl-c, dialog (and others) modules [..]
Hello all,
the addition of this feature short before the code freeze caused some conflicts, which could not resolved sufficently in time for this release. Thus the OpenSER board was asked to decide in this matter. The majority of the board voted for decativating this feature in the 1.4 release series.
On Friday 27 June 2008, Bogdan-Andrei Iancu wrote:
3) by involving in this decision, the board exceeded its attributions -the board is incharged with the management responsibilities and not technical ones - http://www.openser.org/mos/view/Management/
Hello Bogdan,
if problems like this start to affect our goals, i.e. causing issues with regards to our release schedule, then this belongs to the management of the project. So the descision of the board was justified in this case.
Cheers,
Henning
I'm surprised that the board considered judging the effects, but not the cause. Did the board considered to analyse why the release was delayed and why the goal of the project compromised??? Not really.....
There is no justification to judge the effects without judging the cause? and judging with incomplete evidence ?- this is simply a prove of superficiality.
Bogdan
Henning Westerholt wrote:
On Friday 27 June 2008, Bogdan-Andrei Iancu wrote:
- by involving in this decision, the board exceeded its attributions -
the board is incharged with the management responsibilities and not
technical ones - http://www.openser.org/mos/view/Management/
Hello Bogdan,
if problems like this start to affect our goals, i.e. causing issues with regards to our release schedule, then this belongs to the management of the project. So the descision of the board was justified in this case.
Cheers,
Henning
-
Bogdan-Andrei Iancu -
Henning Westerholt