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@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=teltag=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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@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-8001fax: 215-898-9348
sip:blairs@upenn.edu