> > can you explain what the differences are when you say "avp stored in the > transaction" and process variables ? > do you literally mean variables in my module here, or are these some kind > of structure attached to the sip_msg ? > > Read the docs on AVPs, shared variables (shv) process variables (var). > They are all stored in different memory and related to different things. >
Thanks, Ill look into these. > effectively what im looking to do is store some custom data > against sip_msg* that I can use later if I need to. > > When is later? In another request or in the response to the same request? > If there's a stateful transaction, > AVPs are reachable in response processing. > Sorry... by later, I mean, later while processing the same message. Not later on in the call, in that case I know it must be persisted in a dialog. my reason for doing a module is that I had a few things I wanted to do in a > module ( looking up large data structures for performance reasons ), and im > implementing a few other bits of business logic in this module. > > Still doesn't explain why you need to code it in c and make it a modules. > You can do a lot in the existing > logic. > Fair call, I know I can do a lot in kamailio, its quite surprising actually what you can do. Ill re-evaluate my reasons for writing a module. > im happy to discuss further if you want to gtalk me ( on this email > address ) > > I would suggest that you read up on the available docs and then find us in > the IRC channel where we try to be available and answer when it works for > us. If you really need fast help and responses, many of us are available as > consultants. > Ill try IRC again, but yea... there were not many people around last I was on there :) I understand maybe time zones didnt work, or people were too busy. > In general, you have to be a bit more exact in your questions to get good > answers on -dev, a bit less on -users. Your original e-mail was a bit too > inexact so it wasn't easy to answer, which lead to everyone thinking that > someone else may understand and may answer... Before reposting to a > mailing list, try to figure out why no one answered and add information to > make it easier to answer. > Fair enough, sorry for being vague.
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
