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@pernau.at> wrote:
Once you know it you will find it :-)
http://www.kamailio.org/wiki/**cookbooks/3.3.x/**pseudovariables#avpshttp://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 Ifigured 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@pernau.at <mailto:klaus.mailinglists@**pernau.atklaus.mailinglists@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 onceI 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. moredynamic 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@lists.sip-router.org <mailto:sr-users@lists.sip-**router.org sr-users@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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users