[SR-Users] uac From restore not working in 3.3?

Tue Oct 2 21:37:10 CEST 2012

Those originated locally were never using the original value if you 
called msg apply changes -- you can try with an older version, if it 
does that, then it is a bug somewhere :-).

Btw, if you called msg apply changes after creating the transaction, 
then SL is out of scope and tm local reply is using the initial values, 
but that means the changes are only for that branch, a failure route 
will get the initial request content.

Cheers,
Daniel

On 10/2/12 9:30 PM, Alex Balashov wrote:
> The expected behaviour is that all replies, both relayed and 
> endogenously originated (via SL or TM), as well as sequential requests 
> directed back to the caller, will preserve the original headers.
>
>
> -- Alex
>
> --
> Sent from my Samsung mobile, and thus lacking in the refinement one 
> might expect from a proper keyboard.
>
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Web: http://www.evaristesys.com/
>
> Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> Not sure what is 'work as you expect', provided the details I gave in 
> the previous mail related to local replies.
>
> Otherwise, if you don't track all dialogs, could be an issue if some 
> of the replies are ok and some are not.
>
> I will check the uac module and add a parameter to not use dialog 
> module even if loaded, if such option is not already there.
>
> Cheers,
> Daniel
>
> On 10/2/12 9:11 PM, Alex Balashov wrote:
>> So, you're saying that if all the dialogs were tracked, everything 
>> would work as I expect it to?
>>
>>
>> -- Alex
>>
>> --
>> Sent from my Samsung mobile, and thus lacking in the refinement one 
>> might expect from a proper keyboard.
>>
>> Alex Balashov - Principal
>> Evariste Systems LLC
>> 235 E Ponce de Leon Ave
>> Suite 106
>> Decatur, GA 30030
>> Tel: +1-678-954-0670
>> Web: http://www.evaristesys.com/
>>
>> Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>> I think there was an addition to use dialog module to store initial 
>> and new values. I don't know if it can be turned off or is 
>> automatically when the dialog module is loaded - just to see if that 
>> is the cause.
>>
>> However, if you do msg_apply_changes(), local replies will use the 
>> new headers. I'm pretty sure it happened the same before -- e.g., it 
>> was no way to revert back so that sl can use older values of the 
>> headers. Perhaps you can revert from config, changing the header to 
>> initial value that you store in an avp, apply changes and send the reply.
>>
>> Received and relayed replies should be converted.
>>
>> Cheers,
>> Daniel
>>
>> On 10/2/12 8:57 PM, Alex Balashov wrote:
>>> I should be clearer: when I say "internally generated", I don't mean 
>>> it in the sense of 408 or something else opaquely generated by the 
>>> proxy. I mean internally generated as in originating from the proxy, 
>>> e.g. something sent with sl_send_reply() or t_reply().
>>>
>>>
>>> -- Alex
>>>
>>> --
>>> Sent from my Samsung mobile, and thus lacking in the refinement one 
>>> might expect from a proper keyboard.
>>>
>>> Alex Balashov - Principal
>>> Evariste Systems LLC
>>> 235 E Ponce de Leon Ave
>>> Suite 106
>>> Decatur, GA 30030
>>> Tel: +1-678-954-0670
>>> Web: http://www.evaristesys.com/
>>>
>>> Alex Balashov <abalashov at evaristesys.com> wrote:
>>> Hello,
>>>
>>> I am using the latest cloned 3.3 branch and performing a
>>> uac_replace_from() operation.  After the operation, I do
>>> msg_apply_changes().
>>>
>>> My 'uac' modparams are:
>>>
>>> modparam("uac", "rr_from_store_param", "vsfc")
>>> modparam("uac", "restore_mode", "auto")
>>> modparam("uac", "restore_passwd", "xxxxxxxxx")
>>>
>>> However, the modified From URI is getting back to the originator, both
>>> in internally generated errors, and in relayed replies.
>>>
>>> This didn't used to happen before 3.3, but has been outstanding for
>>> quite some time (I didn't look at it much until now).  Is there some
>>> possibility that there is a >= 3.3 bug?  Or, have I simply 
>>> misconfigured
>>> something?
>>>
>>> Thanks!
>>>
>>> -- Alex
>>>
>>> -- 
>>> Alex Balashov - Principal
>>> Evariste Systems LLC
>>> 235 E Ponce de Leon Ave
>>> Suite 106
>>> Decatur, GA 30030
>>> Tel: +1-678-954-0670
>>> Fax: +1-404-961-1892
>>> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> -- 
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
>> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
>
> -- 
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121002/e82fdc87/attachment.htm>