Hi Daniel,
Thanks for the feedback - see my inline comments for the cases you
identified.
Regards,
Bogdan
Daniel-Constantin Mierla wrote:
> However, here is a list with what I find subject for discussion, to be
> broken, not properly behavior or misleading (considering the timeline of
> last Friday evening):
> - exit or drop have no effect, misleading because of their meaning
>
exit() works as in the other routes - it terminates the route execution
drop() is interpreted depending of the type of route:
REQUEST - does nothing
ONREPLY - depending of the reply code
BRANCH - drops the current brach
FAILURE - does nothing
for LOCAL, it does nothing by design , but I plan to add in the future
the possibility to drop the request.
> - setsflag() broken
> - resetsflag() broken
> - issflagset() broken
>
why are broken? the script flags are never reset before or after any
type of route.
So, the script flags behave in local route exactly as in any other type
of route.
> - setbflag() broken
> - resetbflag() broken
> - isbflagset() broken
>
This functions are not to be used from local route. But the core
functions do not have any flags to control the types of routes they are
called from (like the module exported functions).
It is exactly the same case as for the onreply route.
> - initial scripts flags are lost, last local_route script flags are
> getting into initial route script flags
>
the script flags are inherited from route to route by design - they are
not ever reset - same behaviour as for script variables.
> - assignments of following pseudo variables is broken
> - $bf/$bF - branch flags
> - $sf/$sF - script flags
> - $br - adding branch
>
As I said in the local route description email, the RURI, DSTURI and
BRANCHES are not to be changed (by design). Any such changes are simple
discarded or ignored.
It is not broken - it simply does not work as not supposed to.
> - usage of following pseudo-variables is broken
> - $Ts - time stamp
> - $Tf - formatted time
>
they are not broken - as there is another msg->id, the function behind
these PVs will simply make a new lib call for time() in order to return
the current time - nothing is broken.
> - $br - branch
> - $bR - all branches
>
I think these were already listed - branches are not allowed to be used
from the local route. You can add branches, you can see them via PVs,
but there will be not used.
> - $time(...) PV class from cfgutils is broken
>
not broken - same comment as for $Ts and $Tf.
> - avp_pushto("$br", ...) is broken
> - avp_pushto("$ru", ...) with many avps for the second parameter is broken
>
Again, changing RURI/DSTURI or adding branches is not allowed in the
route by design. See the above arguments for the corresponding PVs.
Unfortunately the "avp_pushto" function can operate with other PVs
(than $br and $ru), so it had to be enabled for local_route. But if you
use it for the above PVs, nothing will get broken - it will just not do
anything.
> - setdebug() is broken
>
it is not broken - it works exactly as in the other types of routes.
Have in mind that the debug level is set or reset only from script and
it is not ever automatically reset.
> - append_branch() is broken
>
This function should not be used in local_route, but as it is a core
function, it cannot be explicitly blocked. Anyhow, even if you use it,
it will have no effect. It is exactly the same case as for BRANCH ROUTE.
> - pv_printf(br, ...) (avp_printf(br, ...)) is broken
>
branches are not supposed to work in the local route, as in some other
routes (like branch route). If you found that using them may brake
something, please let me know.
> - have no time to check all the source code, but other developers can
> see if they use that -- the sip_msg->id is changed, so if you call a
> function that checks it to see if some cached data is still valid
> because it is same message you processed by the call of same function or
> another one, once in the initial route, then in the nested local_route,
> when you need it again in the initial route, the cached value is
> considered invalid although it is the message in current processing
>
>
That is the whole purpose with the msg->id - if the message is other,
refresh the cache. If you identified some cases (other than the one
listed) where things get broken, please let me know.
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
