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

14 Jul 2006

Hi Luis, you forgot to copy the list :-)
I'm not the right person to ask these questions. I stay a bit behind the 
bleeding edge as I focus mostly on documentation from a "what everybody 
needs" perspective (i.e. ONsip.org best practice configurations).
There has been several threads lately addressing some of these. Maybe 
some of the developers can help out?!
g-)

Luis Silva wrote:
...
  Hi!
 can I just ask you 4 more things?

 1 - What is the difference between $ and % ?
 2 - is it possible to concatenate avps or strings?
 3 - is there another way for doing the same thing as avp_subst but 
 without using the avp module?
 4 - is it possible for doing this: @contact[1].uri = "sip:"; ?

 Tks for the answer. these are all my questions. please help me.  Tks 
 in advance
 Regards

  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
>
>
> 

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