Steve,
Read original note (down at the bottom in heavily-quoted and now possibly
difficult to wade through text).
It may very well be that avpops is not the best way to handle this, but it
seems to make sense given that I'm looking up db info.
If I'm woefully on the wrong track, if someone would be kind enough to beat me
with a stick until I get back on the path, I'd appreciate it. :)
N.
On Thu, 22 Sep 2005 10:08:07 -0400, Steve Blair wrote
Is there a specific task you would like to implement?
If so
please explain what you would like to accomplish and perhaps we can
help with the avp_ops statements.
-Steve
sip wrote:
>Yeah... the problem with this documentation is that it was clearly written by
>someone who doesn't WRITE documentation as a matter of course, but needed
>something to be out there just to say there's documentation.
>
>It's a little like a developer writing docs for his own code or API. VERY
>understandable to the developer himself, but not so crystal to anyone else.
>This is one of the primary reasons I never let my developers write their own
>API docs. They get with a tech writer, and the tech writer asks questions
>about what the API does, and then writes documentation in such a way that
>monkeys (such as myself) can understand.
>
>I was looking for something a little more... lucid.
>
>If it doesn't exist, cool. I'll keep muddling away and perhaps I'll hit
that
>eureka point of understanding somewhere, but I was hoping.
>
>N.
>
>
>On Thu, 22 Sep 2005 09:29:31 -0400, Paul Hazlett wrote
>
>
>>The offical documentation for AVPOPS (for SER-0.9.x) can be found here:
>>
>>http://www.voice-system.ro/docs/avpops/0.9.0/
>>
>>Regards,
>>Paul
>>
>>On 9/22/05, sip <sip(a)arcdiv.com> wrote:
>>
>>
>>>Is there any good, DETAILED information on AVPops usage that, say,
doesn't
>>>read like a developers API reference page? Currently, I'm cleaning up
portions
>>>of my ser.cfg which have horrid, ugly
hacks in them that I put in to handle
>>>this case or that case...
>>>
>>>For instance, I use the calls_forwarding table to handle call blocking and
>>>call forwarding info (since it seems a little more reasonable than
>>>usr_preferences as it simply has more relevant tables). For call blocking,
I
>>>can say give a purpose of 'blocking' and an action of relay or
reply... with
>>>parameters set to what kind of reply or where to relay (voicemail server?
>>>Alternate server? etc). For forwarding, I can give an action of forwarding
>>>with a parameter of where to forward and another to see if he has permission
>>>to forward to PSTN numbers. Seems like a very handy table for it.
>>>
>>>Now, my current method of doing this is with this horrid mixture of external
>>>scripts, stripping portions off the SIP_HF_FROM header (since it comes with
>>>additional info like tags and brackets and comments), and feeding the new
>>>stuff back into an SQL query to determine whether or not the call needs to
be
>>>blocked, forwarded, and if either, where it goes.
>>>
>>>It's a mess, I'll admit, but it's because I've been poring
over AVPops stuff
>>>and have yet to figure out what I'm actually DOING with any of it. I get
that
>>>it uses little i:XX constructs as
variables (which is bizarre, but
whatever --
>I imagine I could alias them to something
human-readable). And... well...
>that's about as far as I've gotten deciphering the API docs and making them
>into something usable.
>
>I imagine I would what... set the avp_table to be calls_forwarding, and then
>create some schemes for it (?)... but after that, actually doing things like
>taking just the sip:bob@fred.com portion of an incoming uri (which would look
>along the lines of "Ima Doofus"
><sip:bob@fred.com:5060;user=tel>tag=something;tag2=something else ) and then
>trying to determine if that user is on the list of blocked users and, if so,
>what should be the response action... or taking the callee info, and if the
>callee isn't available, checking to see if he has a forwarding number,
>checking to see where it goes, etc, etc.
>
>It all SEEMS like it should be elementary stuff, but I'm simply not getting
>it. Anyone have any good references, well-detailed documentation, long,
>in-depth books on the topic they could send me toward?
>
>I'd be your friend for, like, ever. :)
>
>N.
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@upenn.edu