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

From: "Greger V. Teigre" &lt;greger(a)teigre.com&gt; To: Luis Silva &lt;lfs12(a)hotmail.com&gt; CC: serusers(a)iptel.org, jan(a)iptel.org Subject: Re: SER CVS head, new select identifiers info - was - Re: [Serusers]Textops with AVPs? Date: Wed, 12 Jul 2006 13:41:36 +0200 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@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers >>> >>> >>> >>> >>> > > >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers > > >