Forgive me if I failed to follow a recent discussion to its conclusion, but what is the bottom line on calling uac_replace_from() consecutively, in the course of processing one request?
Is it possible, while using restore_mode 'auto'? Is there a correct way to do it, such as calling msg_apply_changes() after the first call but not the second one?
If not, what is the alternative?
-- Alex
P.S.
I realise that one logical possibility is to store the desired value in a variable, manipulate it as needed throughout the request processing flow, and just call uac_replace_from() once, at the end.
However, the problem in this case is that I am doing multiple branches -- first to a directory service provider that replies with redirects, and then onward to the desired endpoint. These endpoints require different From domain values from me. So, I cannot do that.
-- Alex
On 03/07/2013 06:11 AM, Alex Balashov wrote:
Forgive me if I failed to follow a recent discussion to its conclusion, but what is the bottom line on calling uac_replace_from() consecutively, in the course of processing one request?
Is it possible, while using restore_mode 'auto'? Is there a correct way to do it, such as calling msg_apply_changes() after the first call but not the second one?
If not, what is the alternative?
-- Alex
On Thursday 07 March 2013 12:13:50 Alex Balashov wrote:
I realise that one logical possibility is to store the desired value in a variable, manipulate it as needed throughout the request processing flow, and just call uac_replace_from() once, at the end.
That was the conclusion for my question with multiple calls to uac_replace* Both from and to may only be called once, else the results will be unpredictable.
On 3/11/13 11:37 AM, Daniel Tryba wrote:
On Thursday 07 March 2013 12:13:50 Alex Balashov wrote:
I realise that one logical possibility is to store the desired value in a variable, manipulate it as needed throughout the request processing flow, and just call uac_replace_from() once, at the end.
That was the conclusion for my question with multiple calls to uac_replace* Both from and to may only be called once, else the results will be unpredictable.
Calling multiple times is ok with msg_apply_changes(), if you don-t break something else. Otherwise, the safe way is to use variables and update the header in branch route.
Cheers, Daniel
Calling multiple times with msg_apply_changes() will still result in the stateful restoration of the original From in requests and replies going back to the originating side?
Daniel-Constantin Mierla miconda@gmail.com wrote:
On 3/11/13 11:37 AM, Daniel Tryba wrote:
On Thursday 07 March 2013 12:13:50 Alex Balashov wrote:
I realise that one logical possibility is to store the desired value
in
a variable, manipulate it as needed throughout the request
processing
flow, and just call uac_replace_from() once, at the end.
That was the conclusion for my question with multiple calls to
uac_replace*
Both from and to may only be called once, else the results will be unpredictable.
Calling multiple times is ok with msg_apply_changes(), if you don-t break something else. Otherwise, the safe way is to use variables and update the header in branch route.
Cheers, Daniel
On 3/11/13 1:42 PM, Alex Balashov wrote:
Calling multiple times with msg_apply_changes() will still result in the stateful restoration of the original From in requests and replies going back to the originating side?
ah, ok, I see what you meant. The restore will be to the previously updated value. So maybe you store that in a variable, restore it in config with msg_apply_changes(), then re-update with a new value.
Cheers, Daniel
Daniel-Constantin Mierla miconda@gmail.com wrote:
On 3/11/13 11:37 AM, Daniel Tryba wrote:
On Thursday 07 March 2013 12:13:50 Alex Balashov wrote:
I realise that one logical possibility is to store the desired value
in
a variable, manipulate it as needed throughout the request
processing
flow, and just call uac_replace_from() once, at the end.
That was the conclusion for my question with multiple calls to
uac_replace*
Both from and to may only be called once, else the results will be unpredictable.
Calling multiple times is ok with msg_apply_changes(), if you don-t break something else. Otherwise, the safe way is to use variables and update the header in branch route.
Cheers, Daniel
Hi Alex,
If you create dialog before and use the implementation that relies on dialog variables [1], it is safe to call uac_replace_from() multiple times on the same message, or even the same initial message but looped. The module will detect that uac_replace_from() was called multiple times on the same dialog by searching after the dialog vars it has stored and it will work correctly. This is the usage that we tested and is ok. With the old implementation based on RR param, I don't think it works right calling it multiple times on the same message.
Regards, Anca
[1] http://www.kamailio.org/docs/modules/devel/modules/uac.html#id2495082
On 03/07/2013 01:11 PM, Alex Balashov wrote:
Forgive me if I failed to follow a recent discussion to its conclusion, but what is the bottom line on calling uac_replace_from() consecutively, in the course of processing one request?
Is it possible, while using restore_mode 'auto'? Is there a correct way to do it, such as calling msg_apply_changes() after the first call but not the second one?
If not, what is the alternative?
-- Alex
Hello Anca,
On 03/19/2013 06:00 AM, Anca Vamanu wrote:
If you create dialog before and use the implementation that relies on dialog variables [1], it is safe to call uac_replace_from() multiple times on the same message, or even the same initial message but looped. The module will detect that uac_replace_from() was called multiple times on the same dialog by searching after the dialog vars it has stored and it will work correctly. This is the usage that we tested and is ok. With the old implementation based on RR param, I don't think it works right calling it multiple times on the same message.
Thank you kindly for that edifying information!
-- Alex
-
Alex Balashov -
Anca Vamanu -
Daniel Tryba -
Daniel-Constantin Mierla