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

From: "Greger V. Teigre" <greger(a)teigre.com> To: sip <sip(a)arcdiv.com> 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