[OpenSIPS-Users] [OpenSIPS-Devel] [Request for Brain[storming]] New types of routes in config

[Bogdan-Andrei Iancu]

Hi Thomas,

Thomas Gelf wrote:
> Hi Bogdan,
>
> here my 2 Euro Cents, following your brainstorm request:
>
>
>   
>> 1. Init Route (new)
>>     
>
> Personally I do not have immmediate need for this feature, but as soon
> as I start digging into memcache support it will be really useful. As
> it also shouldn't be that hard to implement: please do it!
>   
yes, it is not hard to do it, and as time as it brings some added value, 
why not :)
>   
>> 2. Reply Route (change)
>>     
>
> I have encountered some issues, for example with uac_replace_from calls
> for specific branches - I'm pretty sure such an enhancement would clean
> up such scenarios / make them easier to implement.
>
> The following should IMO be possible:
>
> route[] {
>     t_on_reply(1);
> }
>
> branch_route[] {
>     if (whatever) {
>         # this will not affect other branches
>         t_on_reply(2);
>     }
> }
>
> If this is how it would work: great, I would really welcome such an
> enhancement.
>   

yes, that's my idea - if you set onreply_route from request_route -> it 
will be used for all branches; but if you set it from Branch_route -> 
only for that branch.

>
>   
>> 3. Reply Route (change) versus branch_completed Route
>>     
>
> To summarize my questions / your explainations on IRC:
>
> - branch_completed[] will be triggered when a branch is completed = when
>   a final response is received on that branch (reply >=200)
> - Calling drop() in branch_completed[] will prevent failure_route from
>   being triggered for replies >=400
> - When triggering a new branch in branch_completed[], minor branches
>   will still remain active and are not going to be CANCELed
>
> This seems very useful and would allow clean routing scripts for complex
> scenarios. I would welcome also this addition!
>   

so you are in favour of branch_complete route, instead of chaginf the 
reply_route to allow new branch creation? Actually, thinking more on 
this, these 2 approaches do not exclude one each other :D
>
>   
>> 4. Timer based route
>>     
>
> This ould be a nice feature. It's not something I have immediate need
> for - and I guess it could be tricky to implement it, probably with some
> side effects... If you want to face the challenge: feel free to do so ;)
>
> My personal favourites are 2. and 3. - 1. should not be that hard, and
> if there is enough time and interest for 4.: I'm absolutely not against
> it. Can someone provide a concrete example where this could make sense?
>   
An example was on the mailing list - asyncron parallel forking (instead 
of firing all branches in the same time, they will fired with some delays).
> And: we would also need individual timeouts for each delayed branch,
> correct?
>   
timeout per branch during parallel forking? interesting.....I guess it 
can be done....

Regards,
Bogdan