Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Strange CallEv when one of the party is from outside the local cluster

Hi there! I have this strange thing here, generally when I use

CallEv.getCall().getConnetions()

The first element in the returned connection array would be the calling party, and the 2nd one the called party.

Now if a call involves a party outside the local cluster, either from a different cluster or not a cisco phone, CCM will always put the local luster party as the first element in the CallEv it sends out, and my code would have no idea who is calling whom.

Is it a configuration problem or this is the way it supposed to be? How can I tell who's calling from JTAPI code (i.e., other than retrieve http://PhoneIP/CGI/CallInfo)?

Thank you very much for your help!

2 ACCEPTED SOLUTIONS

Accepted Solutions

Re: Strange CallEv when one of the party is from outside the loc

Going by connections is a really dangerous ways. Starting from the CallerInfoServer I used to do it that way, too, and it was a mess at best. It's much better to register for CallCtlEvs (implement the CallControlObserver rather than just the CallObserver), and then from the CallControlCall use the

getCalledAddress()

getCallingAddress()

methods.. those really always return what the name says they should return.

Re: Strange CallEv when one of the party is from outside the loc

Can you run the Calltracer that is installed when you install the Cisco JTAPI and monitor such calls to see what kind of events you get.

It is rather weird and does sound like a bug though if you have the exact same scenario, and one time you do get the event and the next time you don't get it.

6 REPLIES

Re: Strange CallEv when one of the party is from outside the loc

Going by connections is a really dangerous ways. Starting from the CallerInfoServer I used to do it that way, too, and it was a mess at best. It's much better to register for CallCtlEvs (implement the CallControlObserver rather than just the CallObserver), and then from the CallControlCall use the

getCalledAddress()

getCallingAddress()

methods.. those really always return what the name says they should return.

New Member

Re: Strange CallEv when one of the party is from outside the loc

Thanks a lot!!! Now it works fine!

Just one more thing, when a call come in from a different cluster, sometimes (>50%) I won't be able to capture the CallCtlConnDisconnectedEv, in such case, the last event received will be CallCtlTermConnTalkingEv, any hints what might wrong here? Thank you very much for your help!

Re: Strange CallEv when one of the party is from outside the loc

Which phones are you monitoring in that case?

I don't have multiple clusters but I have another PBX connected via H.323 trunk and I'm not getting the same events back from that other PBX as well.. but I've never had to get this working for a customer so I can only make guesses.

If A is on your local cluster and B on your remote cluster and if you monitor A, is there any kind of regularity you can observer? Like do you not get the events if the remote party ends the call but you get them if the local party ends the call?

New Member

Re: Strange CallEv when one of the party is from outside the loc

In both cases the events are lost, now I can hardly get a CallCtlConnDisconnectedEv if B is calling from remtoe cluster....

Re: Strange CallEv when one of the party is from outside the loc

Can you run the Calltracer that is installed when you install the Cisco JTAPI and monitor such calls to see what kind of events you get.

It is rather weird and does sound like a bug though if you have the exact same scenario, and one time you do get the event and the next time you don't get it.

New Member

Re: Strange CallEv when one of the party is from outside the loc

You are right! It's bug in the code, thanks a lot for reminding JTrace!!!

133
Views
0
Helpful
6
Replies