[asterisk-dev] [feature requests]: 'zap answer confirmation info' and 'different clis on forking'

[Christian B]

hello folks!

there are two features that i'm looking for since nearly a year now but
so far i can't fullfill them with asterisk(afaik), both have the same
cause:

in my setup there are extensions similar to this:

exten => s,1,SetCallerID(0023123456 <0023123456>)
exten => s,n,Dial(SIP/88888 at sipproxy.domain.com&Zap/G1c/0023777777)


1.Feature: Answer Confirmation Info
======================================
The second call leg to Zap-0012777777 needs 'answer confirmation', as
it is a cell phone and we don't want the caller to
hear the cellphone-mailbox of the callee in case it is active. 
However, when the callee himself is trying to pickup, he has to know
that this call is coming via asterisk and he has to press the '#'-key
to be connected after picking up. 
The experience has shown that it is very confusing and annoying if you
forget to press the '#'-key and in the end you might miss the call.
I could use a workaround which is to modify the callerid so the callee
remembers to press the '#' after picking up, e.g. prefixing the
callerid by '999'. 
Unfortunately, nobody always looks at the display before picking up a
call and secondly, it is illegal to send wrong callerid's via the pstn
(at least in my country).

There's a patch by bweschke[1] called "follow_me-find_me", which plays a
message to the callee to accept the call by pressing a key, if he
doesn't, the next extension that has been configured in the
followme.conf is dialed.

unfortunately this patch is not ready for 1.2 atm, also in it's current
form it will not work for scenarios where you provision with a
database, as you have to add the extensions to a flat-file.

So basically what i would like to see is an addition to the
"answer confirmation"-option:
If the confirmation option is activated, tell the callee, after he has
picked up, that he has to press '#' to be connected.
I don't know if this is a possible addition to the "answer
confirmation"-option within the identifier-parameter in zap-calls,
guess this has to be implemented as a "normal" option which would have
to be set for all legs. 
However, i think something like this would make a lot of sense cause
our customers are not supposed to know when to press '#' - imho the
"answer confirmation"-option doesn't even make much sense if it is not
possible to inform a enduser that he has to confirm the call. 

i'm looking forward to bweschke's update of the patch and i will again
use it when it works for 1.2. However, this patch is kind of
exaggerating my real needs and it is difficult to maintain for many
users (flatfile).


2.Feature: Different CallerID's on Forking
==========================================
The second feature is a bit more abstract - same setup as above:

exten => s,1,SetCallerID(0023123456 <0023123456>)
exten => s,n,Dial(SIP/88888 at sipproxy.domain.com&Zap/G1c/0023777777)

Assume that the call from "0023123456" comes from the PSTN.
Asterisk receives the call in the international format which
looks like "23123456".
When i would send it like this(23...) to my customers, they would think
it is a regional call or simply be confused where it comes from, as they
are used to "+23"(with cell phones) or "0023"(with pstn-phones) for
international calls. And even if they recognize that it is
international format, this is not very pretty and is not conform to
what thei're used to(and unfortunately, it is important to keep
consistent with what thei're used to)

Therefore i have to set the callerid to "0023123456" so it is shown on
their sip-phones in the format they already know from the pstn.
However, this is problematic in the forking scenario above:
When i send 0023123456 via the pstn to the cellphone, the
cellphone-carrier does not interpret the "00" correctly and simply
prefixes it with the countrycode, which is displayed as
"+230023123456" at the cellphone we call above(0023777777). 
Additionally this is illegal, as it is not a "correct" cli. The only way
to prevent this, is to send the callerid in a proper international
format as we receive it, like this:

exten => s,1,SetCallerID(23123456 <23123456>)

But again, this would result in the confusion i wrote about already,
our (european) customers are not used to international formats which
don't begin with '+' or '00'. So either the customers get used to the
"proper" international format(which unfortunately is not an option for
some sales-managers and the customers) or i find a way to send different
cli's to the two call-legs. 
Maybe this is possible with some freaky dialplan-setup and other apps
than dial, but currently i don't know how i could realize this. 
So my feature request goes like this:
I need a flexible way to set the callerid within a dial-command which
forks to different technologies. So in the example above, the
SIP-Destination receives '0023123456' and the Zap-Destination receives
'23123456'.
I know that this is a pretty simplistic proposal which will
hardly be solved in this way - on the other hand, my example is a real
world requirement and i'm pretty sure that i'm not the only one who
forks a call to SIP and PSTN and needs proper (=differing) CLIs on both
ends.


Conlusion
=========
Both of the described features are real world requirements, maybe
there's a simple solution for both of them i have not stumbled upon
yet. Excuse me for stealing your time if that is the case(and maybe let
me steal even more of your time by pointing me to the solution),
however, i believe that my requests have a solid base(Especially for
the 1.). The "answer confirmation" makes little sense for endusers who
don't want to be alerted everytime they receive calls on their
cell-phones, having to think that they might have to press 'pound' to
accept the call - which consequently requires a information beeing
sent to the callee. 
Also it's a requirement of convenience to be able to recognize a call
as international at first glance(Identified by two leading zeros, in
Europe) and if the call goes to the pstn, to send it in the proper
format(And if both needs to happen on the same call, the ability to set
the cli according to the situation).

Thanks for your interest and answers!

Best regards
Christian Benke



Links:
[1]http://bugs.digium.com/view.php?id=5574