Re: SER CVS head, new select identifiers info - was - Re: [Serusers]Textops with AVPs?

From: samuel &lt;samu60(a)gmail.com&gt; To: "Greger V. Teigre" &lt;greger(a)teigre.com&gt; CC: "Luis Silva" &lt;lfs12(a)hotmail.com&gt;om>, serusers(a)iptel.org Subject: Re: SER CVS head, new select identifiers info - was - Re: [Serusers]Textops with AVPs? Date: Wed, 12 Jul 2006 16:04:47 +0200 I looked into select_core.h and found quite a lot of possible vars for the core.... Samuel. 2006/7/12, Greger V. Teigre &lt;greger(a)teigre.com&gt;om>: > >AFAIK, there is no single place to find all the @vars. It's still on the >to-do... >Jan: Could you provide some quick pointers? >g-) > >Luis Silva wrote: > > > > Hi Greger, where can I find the complete list of all the @vars? > > > > @from, @from.uri, @to, @to.uri, @from.tag, @from.name, @to.tag. > > @to.name, @from.params, @to.params, @contact, @contact.uri, > > @contact.params, @contact.expires, @contact.q, @via, and so on. <--- > > > > Regards,Luis Silva > > > > > > > > > >> From: "Greger V. Teigre" &lt;greger(a)teigre.com&gt; > >> To: sip &lt;sip(a)arcdiv.com&gt; > >> CC: serusers(a)lists.iptel.org > >> Subject: Re: SER CVS head, new select identifiers info - was - Re: > >> [Serusers]Textops with AVPs? > >> Date: Wed, 12 Jul 2006 08:47:11 +0200 > >> > >> It's in head only (0.10.x track) > >> g-) > >> > >> sip wrote: > >>> Greger, > >>> > >>> Sounds incredibly handy. Is this available only in SER head or is it > >>> something > >>> that's been around for a little while (i.e. do I have any hope of > >>> using it in > >>> ser 0.9.6) ? > >>> > >>> > >>> N. > >>> > >>> > >>> On Tue, 11 Jul 2006 21:18:38 +0200, Greger V. Teigre wrote > >>> > >>>> I repost Jan's original description of the "select identifier" > >>>> > >>> functionality. Since then, more select identifiers have been added, > >>> both from > >>> core and modules. > >>> g-) > >>> > >>> SER core can parse select identifiers using the configuration parser. > >>> A select identifiers begins with @ characters and contains several > >>> components/tokens delimited by . (unless it is integer component). > >>> Integer components are enclosed in [], for example: > >>> > >>> @contact[1].uri > >>> > >>> This identifier is converted into binary structure which contains the > >>> array of components. After that the parser tries to lookup function > >>> that matches the identifier. > >>> > >>> Available functions are arranged in a tree-like structure. When > >>> looking up a function the tree is traversed (starting at the root) > >>> until the parser finds corresponding function. The part of the tree > >>> containing TLS functions looks like: > >>> > >>> "tls"-+-"peer"-+-"subj"-+-"name" (select_peer_name()) > >>> | \ > >>> | "state" (select_peer_state()) > >>> | > >>> +-"issuer"-+-"name" (select_peer_issuer_name()) > >>> \ > >>> "state" (select_peer_issuer_state()) > >>> > >>> Thus when you write @tls.peer.subj.state in the configuration file > >>> then the parser will traverse the tree until it reaches > >>> select_peer_state() function and then it would remember that this > >>> function should be called. > >>> > >>> The tree of identifiers and functions is built dynamically at >runtime. > >>> This is a nice feature becase this way modules can register their >own > >>> functions or whole subtrees and make their functions available in >the > >>> configuration file. > >>> > >>> Thus if you load TLS module then all @tls.* selects become avaiable, > >>> if you do not load the module they are not available. Only a couple >of > >>> core functions and the framework is built in the core, the rest can >be > >>> in modules. > >>> > >>> This framework is currently used in tls and xmlrpc modules. XMLRPC > >>> module exports the name of the XML-RPC method to the script. TLS > >>> module exports information from TLS layer. > >>> > >>> The SER core itself contains a couple of functions that can retrieve > >>> various parts of a SIP message: > >>> > >>> @from, @from.uri, @to, @to.uri, @from.tag, @from.name, @to.tag. > >>> @to.name, @from.params, @to.params, @contact, @contact.uri, > >>> @contact.params, @contact.expires, @contact.q, @via, and so on. > >>> > >>> TLS related functions are described in a separate email. > >>> > >>>> sip wrote: Sounds like something I might look more into. Thanks, > >>>> Greger. Is > >>>> > >>> there > >>> anything written more about @var constructs? I checked the admin > >>> guide (I > >>> know... that was kind of silly considering how out of date it is ;) > >>> ), and > >>> tried to do a search in Google (it seems to ignore the @, so @var > >>> just gives > >>> me every message with the word 'var' in it) and didn't see anything. > >>> Is there > >>> anything over at OnSIP discussing it? > >>> > >>> N. > >>> > >>> On Tue, 11 Jul 2006 08:35:11 +0200, Greger V. Teigre wrote > >>> If this functionality was added in later openser versions than >0.9, > >>> it will most likely not be in SER. What you are describing is hard > >>> to do with the avpops version in 0.9. The avpops module was generic > >>> enough to do more than it was designed for; making some code > >>> operations quite dirty in 0.9 (using the ruri as a temporary storage > >>> while manipulating a variable). SER head uses @var to more directly > >>> access data instead of going through a module. You may want to have > >>> a look at it! g-) > >>> > >>> sip wrote: > >>> Is there a version of textops that can do substs with AVPs that > >>> will work on > >>> SER 0.9.6 or is that an openSER-only modification of the code? > >>> > >>> I'm curious because we're ALSO running into the issues of charging >the > >>> call-forwarding user for forwarding a call to the PSTN instead of > >>> charging the > >>> calling party. Ideally, I'd like to rewrite the from address solely > >>> for the > >>> purpose of authenticating the user who's doing the forwarding and > >>> charging him > >>> for the call, but that would likely break things as there'd be no > >>> way to get > >>> back to the original user if I just rewrote the from username. > >>> > >>> SO, I thought, why not let the b2bua handle the details and just > >>> forward a uri > >>> with a prefix string that includes the user who's forwarding the > >>> call (the > >>> original RURI instead of just the rewritten one). > >>> > >>> And there's the trick. How do I craft a RURI out of bits and pieces > >>> of things > >>> into one long RURI? > >>> > >>> If it were all the same number, I could use prefix, but it's dynamic > >>> (as is > >>> the nature of most things), so prefix won't work. > >>> > >>> How do I take > >>> > >>> RURI=1105 > >>> > >>> And add to it: > >>> > >>> The rewritten RURI from the call forwarding info: 18005551212 > >>> > >>> AND the prefix for the b2bua auth: 9999 > >>> > >>> To make: > >>> > >>> new ruri: 9999110518005551212 > >>> > >>> N. > >>> _______________________________________________ > >>> Serusers mailing list > >>> Serusers(a)lists.iptel >.orghttp://lists.iptel.org/mailman/listinfo/serusers > >>> > >>> > >>> > >>> > > > > > >> _______________________________________________ > >> Serusers mailing list > >> Serusers(a)lists.iptel.org > >> http://lists.iptel.org/mailman/listinfo/serusers > > > > > > >_______________________________________________ >Serusers mailing list &gt;Serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers >