[OpenSER-Devel] discussion: issues with local_route

[Bogdan-Andrei Iancu]

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.