[Asterisk-Dev] Privacy Code -- need reviews

[Steve Murphy]

[I tried to submit this last night, but it was too big. I'm splitting my
post now into two
halves, hope they fit. -- SM]

Hello---

Got the itch today, been thinking about it for a while... so I made an
attempt at 
finishing the privacy code that Mark started a while back.

I don't know if someone else has already submitted this / is working on
this / will be 
insulted if I present this /  etc.  but here we go...

Caveats:

I just finished writing this stuff up. I haven't really even compiled
the stuff yet. I'm submitting
it just to see if I'm approaching the problem correctly. I could be way
off, and before I start 
debugging and spend a week wasting my time on it, I'd at least like to
know I'm in the
ball park! If you think you can just plug this in and recompile
asterisk, and it will work, 
you are totally wrong! I'm certain it's full of gaffers so big, I'll be
laughed out of programming
school forever. Don't waste your time. But, if you want to, and tell me
about my flaws,
I'll be thankful. Or, if you think you could do better, feel free to do
so, whether you use
my stuff for a start, or just toss it and recode it up your way, it
matters not to me.


Explanations:

After thinking things thru, I began to fully (perhaps) comprehend why
Mark added the privacy
option in the dial command. It became clear to me that the point to make
a decision about how
to handle the call would occur after the incoming caller chose an actual
extension, and before the
person being called was actually bridged to the incoming caller channel.
This is in the bowels
of app_dial.c.

So, if the privacy option is set, there are two places in the dial_exec
function where you want to
handle things. The first is near the beginning, where there is already
code for the privacy option.
In this spot, you can check the privacy db against the caller id. If it
is KILL or TORTURE, there is 
no point in continuing the dial process. The called person is just not
interested in getting this call.
If the setting is DENY, then, return as if the dial returned with no
answer.  If UNKNOWN, then here is a
good time to prompt the caller for his "introduction", and record his
intro to a file, if they haven't
already done so.

Then, the next place to put code, is just before you bridge the two
channels together. At this point, 
the called extension has been rung, and the called person has picked up
the line. At this point, the
"Announce" file is played, and if the Privacy option was set, here is a
good point to insert these actions:
    1. Tell the called person a caller is present, who is not in the
database. Play their
      introduction we just recorded. 
    2. Give the called person a list of options:
       1. Caller is OK, mark as ALLOW in db, and finish the bridge.
       2. Send this caller to VM now, and forevermore.
       3. Send this caller to the Torture Script context now, and
forevermore.
       4. Send this caller a more brief and humane telemarketer "go away
and don't come back" 
         context now, and forevermore.
       5. Mark this caller as ALLOW in the db, but send them to
voicemail  right now.
    3. Collect the user response, loop the prompt until they give a
correct response. Then apply
       the proper action to the response. Let the call bridge for
ALLOW.  Act like the line was
       unanswered for DENY (should go to VM). Switch context to the
"kill_context" for KILL,
       or the "torture_context" if it is TORTURE. 

I added two variables to the privacy.conf file, the "kill_context" and
"torture_context" variables. These
specify a string that should be a defined context in extensions.conf.

Uh, don't think I followed the existing formatting totally, but that's
pretty cosmetic. I used existing
examples in other files to do some tasks, and may have included unnecc.
code insodoing.

And, I may be making spectacularly bad structural mistakes, and for this
I beg your review, to make
sure I'm just not hacking it the wrong way, and making a mess of the
whole thing for myself.

I don't know what the caller will hear while Asterisk converses with the
target called person. Will they 
hear the ringing/ moh?  or just Nothing? I'm hoping ringing or moh,
because the called user might
be a bit slow to make a decision... maybe listening to the options two
or three times, etc. I haven't coded anything around this, but it may
require attention,
I don't know.

Haven't recorded the prompts yet, but that will be pretty simple, and
won't take long... although for 
the sake of Asterisk, getting the same HQ female voice as the voicemail
stuff might make it much
more palatable.

So, is this the right approach, everyone?

murf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20040104/66c0cf20/attachment.htm