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

Wed Jul 12 16:04:47 CEST 2006

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060712/c76f2f76/attachment.htm>