[Devel] Branch flags

[Klaus Darilion]

Hi Bogdan!

How can we make usage of the NAT flag per branch once it is implemented?

If I want to enforce rtpproxy only for NATed branches, I must not use 
mediaproxy in route, but in branch_route. Thus, If several branches are 
NATed I will call the mediaproxy multiple times for on transaction - 
this might confuses the rtpproxy (or at least creates additional delay 
because of the communciation with rtpproxy).


regards
klaus


Bogdan-Andrei Iancu wrote:
> Hi everybody,
> 
> there were couple of discussion threads around the issue of per-branch 
> flags. Before approaching the final step (per-branch flags prior 
> transaction creation), I would like to debate with everybody some 
> logical issues about the behaviour of per-branch flags.
> 
> The main idea is:
>    - before transaction creation, the additional branches will have 
> their own flags stored in dset table. These flags will not be accessible 
> via script (at least now), but only by modules.
>    - registrar will set the NAT flag per branch - for the RURI, the flag 
> will be set in the msg->flags, for additional branches, in the dset 
> flags; maybe a second flag will be needed to be set in msg->flags to 
> tell if at least one dset branch or RURI is nated.
>    - branch route will be run - what flags will be visible here? 
> logically should be an OR between the common flags (msg->flags) and the 
> dset branch flags (from dset)....but this is not quite OK since the 
> msg->flags will contain the the particular NAT flag for the RURI 
> branch...so msg->flags does not actually contain only the common flags, 
> but also the particular flags for the RURI branch....that's *issue 
> number one*.
>    - the flags resulted after the branch route are saved in the 
> transaction for each branch. The msg->flags remains unchanged...
>    - in onreply route, the per-branch flags will be made visible (the 
> ones stored in transaction by branch route)....
>    - in failure route...again what flags should be visible? right now, 
> the msg->flags flags are...the common ones...but doing this makes 
> impossible to pass any flags from onreply route to failure route (and 
> this is not good)....and that's *issue number two*...
> 
> 
> any comments are welcomed... I prefer to have this done before the cvs 
> freeze to get into the next release.
> 
> regards,
> bogdan
> 
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
> 
>