Discussion:
Problem with getting the right ConnectedId while call redirection
(too old to reply)
p***@gmail.com
2014-02-20 08:59:50 UTC
Permalink
Hello,

I got an ATAPI-problem with redirected calls.

Imagine employee Dick gets an extern call from the outside und redirects that call to employee George.
In the CallInfoChanged-event of the TapiLine i can detect the phone number of the extern caller by the ConnectedId.

There are two scenarios now:

Case 1:
A new call comes to Dick's phone and Dick redirects it to George without picking up his telephone receiver.
When George picks up his receiver, the CallInfoChanged-event is raised with CallState=Connected and in the ConnectedId we can see the phone number of the extern caller.
That's what i want!
But there is still...

Case 2:
A new call comes to Dick's phone, Dick picks up his receiver and redirects the call to George.
George picks up his receiver.
Then the CallInfoChanged-event is raised for the first time.
In the CalledId as long in the ConnectId we see the phone number of Dick and no hint, that there is an extern caller on the line.
When Dick hang up his receiver and George gets the extern caller, the CallInfoChanged-event is raised once again.
This time we see the phone number of Dick in the CallerId and the phone number of the extern caller in the ConnectedId.

My problem is, that i have programmed an application which opens a form with information about caller when i get connected call over ATAPI.
As You can see in case 2, the CallInfoChanged-event is raised twice and it makes no sense to open the form with the different ConnectedIds twice.
Do i have any possibility to detect in the first raising of the event with CallState=Connected, that i'm getting a call which is redirected?

Thanks in advance and have a nice day!
Patrick
Andreas Marschall [exMVP TAPI]
2014-02-21 13:40:24 UTC
Permalink
Post by p***@gmail.com
A new call comes to Dick's phone, Dick picks up his receiver and redirects the call to George.
George picks up his receiver.
Then the CallInfoChanged-event is raised for the first time.
In the CalledId as long in the ConnectId we see the phone number of Dick and no hint, that there is an extern caller on the line.
When Dick hang up his receiver and George gets the extern caller, the CallInfoChanged-event is raised once again.
This time we see the phone number of Dick in the CallerId and the phone number of the extern caller in the ConnectedId.
My problem is, that i have programmed an application which opens a form with information about caller when i get connected call over ATAPI.
As You can see in case 2, the CallInfoChanged-event is raised twice and it makes no sense to open the form with the different ConnectedIds twice.
Do i have any possibility to detect in the first raising of the event with CallState=Connected, that i'm getting a call which is redirected?
Patrick,
at the time of the 1st event the supervised transfer has not taken place,
i.e. Dick hast still the choice not to transfer the external caller to Georg!
Hence George can never get the external caller ID as ConnectedID at this time!

What about just updating the ID in your (1st) form after is has changed and not opening a 2nd form?

In the 2nd event there should be enough info to detetct that it is an update of the initial call info. E.g. there should be RedirectingID (Dick) and RedirectionID (George) set. In addition LINECALLINFO.dwReason should be equal to LINECALLREASON_REDIRECT.
You may want to test this scenario with JulMar's Phone.exe to see what LINECALLINFO is present at each stage.
--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK / Visual C++ 2003-2008
TAPI / TSP Developer and Tester
My TAPI and TSPI FAQ:
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
My Toto® Tools (a collection of free, mostly TAPI related tools):
http://www.I-B-A-M.de/Andreas_Marschall's_Toto_Tools.htm
* Please post all messages and replies to the group / forum so all may
* benefit from the discussion. Private mail is usually not replied to.
* This posting is provided "AS IS" with no warranties, and confers no rights.
Loading...