×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CallCtlConnAlertingEv vs. CallCtlTermConnRingingEvImpl

Unanswered Question
Jun 27th, 2006
User Badges:

Hello there! I have this problem caused by call forwarding. Say if someone forwarded calls to extension 1234 to another extension 9876, and a call comes in, it rings at 9876, but my code, who response to CallCtlConnAlertlingEv will pickup a called number 1234. By observation it seems that if use CallCtlTermConnRingingEvImpl instead, I can use getTerminalConnection() to get the terminal where it actually rings. Just want to know if that's worth pursuing, and any potential disadvantage of such a approach?


Thank you very much for your help!!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
stephan.steiner Tue, 06/27/2006 - 22:42
User Badges:
  • Silver, 250 points or more

I would stay as far away as you can from anything Termconn related.. it gets a heck of a lot more complex as soon as you enter transfer/park/conference scenarios.

It is rather easy to figure out if you get a CallCtlConnAlertingEv due to a transfered call, or a call that is directly routed to you, all you need to do is check if CallControlConnAlertingEv.getLastRedirectedAddress() is null or not (null = direct call, not null = transfered call)


And there's always the Address callDestination = ccall.getCurrentCalledAddress(); which gives you the number that's currently being called (versus ccall.getCalledAddress() which gives you the number that was dialled)


I have recently contemplated switching events for a particular scenario as well but when I tried I ran into all kinds of unforeseen consequences so I went back and instead looked at why my scenario didn't always work out and tried to solve it with the existing events.

minatcisco Fri, 06/30/2006 - 16:26
User Badges:

Thanks a lot Stephan!! yes getCurrentCalledAddress() addresses the issue!! Thanks!


As for transfer/conference, I saw this paragrah in the Cisco JTAPI Guide:


The system does not support Call.getCurrentCalledAddress() and call.getCurrentCallingAddress() for

conference calls. Also, the system does not support call.getCurrentCalledPartyDisplayName() and

call.getCurrentCallingPartyDisplayName() for a conference call.


http://www.cisco.com/application/pdf/en/us/guest/products/ps6164/c1674/ccmigration_09186a008062b45b.pdf


Just curious....

stephan.steiner Sun, 07/02/2006 - 22:54
User Badges:
  • Silver, 250 points or more

Each conference starts with a single call.. after that it's kinda natural that the abovementioned methods don't work.. each participant could add other participants to the conference.. and what would the above methods then have to show? the intial call? the last placed call (from somebody adding somebody else to the conference)?

You can still go with connections though but you need to track the conference in memory since JTAPI doesn't keep a history of what's going on with a call.. you just get snapshots as something has happened.

Actions

This Discussion