[Asterisk-Users] CallerID retain on internal transfer

[Steve Davies]

On 5/16/06, Avi Miller <avi.miller at squiz.net> wrote:
> Michael J. Tubby B.Sc (Hons) G8TIC wrote:
> > call then transfers it on to another extension transferee (recipeient)
> > sees the Caller*ID
>
> This behaviour changed in Asterisk 1.2 -- add "o" to your Dial options
> and Asterisk will retain the original Caller ID on transfer.
>

This does not sound like quite the same thing "o" reverts to 1.0.x
behaviour, which is still not presenting the original number after an
attended transfer that is managed from the phone handset (perhaps it
does work if the *2 feature is used?)

In the cases previously mentioned, the user is doing an attended
transfer using the handset features, and not Asterisk. I do not know
whether SIP even allows the Caller ID to be changed at the point when
two separate calls are bridged to one...

i.e. The current behaviour (on our system) is:

  Caller -> Phone A (Caller's ID)

  Caller -> On Hold
               Phone A -> Phone B (A's ID)

  Phone A disconnected
  Caller -> Phone B (A's ID)

But the desired behaviour is:

  Caller -> Phone A (Caller's ID)

  Caller -> On Hold
               Phone A -> Phone B (A's ID)

  Phone A disconnected
  Caller -> Phone B (Caller's ID)

The "o" option looks as if it changes the number that is initially
presented on Phone B, and is only under Asterisk's control if you use
Asterisk's built-in attended transfer facility, otherwise the 'Phone
A' handset is responsible for the change. I suspect that the desired
behaviour is also only possible if 'Phone A' does the "Right Thing
(tm)"

*THINKS* In fact, when the phone is doing the attended transfer, the
caller-ID that should be presented AFTER a transfer will depend
entirely upon the final destination of the call. It may not even be
possible to change the CID upon transfer if the attended call went
(for example) out of a ZAP channel.

Looks like this is not an easy one to solve, but I am not 100% sure of
which party is responsible for what during this type of transfer so I
may be wrong...

Cheers,
Steve