[Devel] Branch flags

[Bogdan-Andrei Iancu]

Hi Klaus,

I would say it should work. Not sure about mediaproxy behaviour, but I 
can tell about rtpproxy: Even if you call force_rtp_proxy() more than 
once for a request (from branch route), it will be ok (it will be like 
refreshing). Anyhow you may use global flags (visible between branches) 
to mark and avoid this -  see my reply to Juha.

regards,
bogdan

Klaus Darilion wrote:

> 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
>>
>>
>
>