[SR-Users] AVPOPS / TM behavior

[Brandon Armstead]

Klaus,

   I see the following:

AVPs are special variables that are attached to SIP transactions. It is a
list of pairs (name,value). Before the transaction is created, the AVP list
is attached to SIP request. Note that the AVP list works like a stack, last
added value is retrieved first, and there can be many values for same AVP
name, an assignment to the same AVP name does not overwrite old value, it
will add the new value in the list.
While this does *technically* describe the behavior - we may want to
explicitly point out this behavior when spiraling to the same proxy.  I
guess to me its not clear enough based off of this above copied text.
 Unless I am still missing the explanation somewhere else in the text?
 Thanks!

Sincerely,
Brandon Armstead
On Tue, Aug 7, 2012 at 12:00 PM, Klaus Darilion <
klaus.mailinglists at pernau.at> wrote:

> Once you know it you will find it :-)
>
> http://www.kamailio.org/wiki/**cookbooks/3.3.x/**pseudovariables#avps<http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#avps>
>
> regards
> Klaus
>
>
> On 07.08.2012 18:22, Brandon Armstead wrote:
>
>> Klaus,
>>
>>     Thank you for this detailed explanation.  This is essentially what I
>> figured was happening.  I was able to use htable to work around it.
>>
>> I guess however I am still confused as to where there is any public
>> documentation on this specific bit.  Had I've not been working with
>> Kamailio for years I would think this would confuse others.
>>
>> Let me know if it is somewhere else, otherwise I will add it to the
>> Kamailio wiki.
>>
>> Sincerely,
>> Brandon Armstead
>>
>> On Tue, Aug 7, 2012 at 2:32 AM, Klaus Darilion
>> <klaus.mailinglists at pernau.at <mailto:klaus.mailinglists@**pernau.at<klaus.mailinglists at pernau.at>>>
>> wrote:
>>
>>     AVPs are associated with the transaction. If you "spiral" a request
>>     through the same proxy, then for the proxy it is a new transaction.
>>     Thus, when processing the request a second time, there is a new
>>     transaction and you do not have access to the AVPs of the previous
>>     transaction.
>>
>>     Workarounds are:
>>     - store data in SIP headers and retrieve it later (ugly)
>>     - use htable module to store data during transaction 1 and retrieve
>>     it during transaction 2. Therefore you need a known "key" which is
>>     identical in this 2 transactions only (e.g. use "$ci$ft" as base for
>>     the key).
>>
>>     regards
>>     Klaus
>>
>>
>>
>>
>>
>>     On 07.08.2012 00:27, Brandon Armstead wrote:
>>
>>         Hello,
>>
>>              I am curious if there is any documentation on how AVP's
>>         processing
>>         works in the following scenario below.
>>
>>         UAC 1 -> KAMAILIO -> KAMAILIO -> DEST
>>
>>         It seems that AVP's I set between UAC 1 -> KAMAILIO are lost once
>> I
>>         relay back to the same KAMAILIO proxy (self)?
>>
>>         Is there any documentation on why or when this would occur?
>>
>>         Is there a better way to handle such a scenario?  i.e. more
>> dynamic
>>         internal routing, vs relaying to self.
>>
>>         Thanks as always in advance!
>>
>>         Sincerely,
>>         Brandon Armstead
>>
>>
>>         ______________________________**___________________
>>
>>         SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>>         mailing list
>>         sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-**
>> router.org <sr-users at lists.sip-router.org>>
>>         http://lists.sip-router.org/__**cgi-bin/mailman/listinfo/sr-__**
>> users <http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users><
>> http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>> >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120807/2ef1f014/attachment-0002.htm>