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

Luis Silva lfs12 at hotmail.com
Wed Jul 12 16:30:52 CEST 2006


tks


>From: samuel <samu60 at gmail.com>
>To: "Greger V. Teigre" <greger at teigre.com>
>CC: "Luis Silva" <lfs12 at hotmail.com>, serusers at 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 <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
>>





More information about the sr-users mailing list