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

[Michal Matyska]

Yes, select_core.h is the main source of all the calls.
Then each module can register it's own select tables, so you should look
for register_select_table calls in modules subdirectories....

Michal

On Wed, Jul 12, 2006 at 04:04:47PM +0200, samuel wrote:
> I looked into select_core.h and found quite a lot of possible vars for the
> core....
> 
> Samuel.
> 
> 2006/7/12, Greger V. Teigre <greger at teigre.com>:
> >
> >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" <greger at teigre.com>
> >>> To: sip <sip at arcdiv.com>
> >>> CC: serusers at 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 at lists.iptel
> >.orghttp://lists.iptel.org/mailman/listinfo/serusers
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>> _______________________________________________
> >>> Serusers mailing list
> >>> Serusers at lists.iptel.org
> >>> http://lists.iptel.org/mailman/listinfo/serusers
> >>
> >>
> >>
> >_______________________________________________
> >Serusers mailing list
> >Serusers at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serusers
> >

> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers