I'm seeing some weirdness in my monitoring application where I am getting disconnect events to unknown call ID's. In this one example I have extension x with call ID 1 on a call and extension y with call ID 3 on a separate call. Right at the same time I get 2 disconnect events for each of the extensions with call ID 3. Call ID 3 doesn't exist anywhere else in my logs. Any clue as to what could be happening here?

Thanks,
Ben

My first guess is that you may have Bridge Call Appearances configured on/of one of the phones. This can lead to one phone being in a call even though it is not taking part in the call.

Do a "display station" of the extensions to see if they have a call appearance of another phone. It may also be that some other phone has a call appearance of one of these extensions which may be more difficult to pin down.

Martin

So it's possible to get a CLEARED event for a call without ever having received an ESTABLISHED event for it? Can you explain a little bit about what a bridged call appearance is? Or point me to some documentation?

Thanks,
Ben

The events you receive will depend on:
o What you are monitoring
o When you start the monitor
o What events you selected to receive
o The call flow

For example, say you monitor station A and it is in a call to station B. If B transfers the call to C, A will have been moved to a different call. If you do not monitor for Transferred events, you will not know this until the call is ended.

As for bridging, there are many documents that give information on it. For example, "Avaya Aura Communication Manager Feature Description and Implementation".

Martin

I think this may be causing me more issues than I thought. Basically our application listens for established events on a particular extension and then listens for an RTP stream to/from the IP address of that extension. It looks like for every established inbound call I am not seeing the RTP from the IP address of the extension that I'm getting the event for. If a bridged call appearance answers a call do I get the established event for the primary extension? If this is the case, is there a way to tell the extension of the actual station that answered the call?

-Ben

Bridging is a huge subject and I cannot go into it in detail here. There is a lot of information in various posts on these forums. The archive of these forums from before we moved to the new portal will be available soon so you will be able to search through it then.

In the mean time, you should have a look at the TSAPI Programmers guide. It will give some information of how bridging interacts with TSAPI (and therefore DMCC).

Also, you should use MediaStart events when triggering your recorder. These are directly tied to the RTP stream - Established events are only an indirect indication that media is available.

Martin

I think I'm now handling bridging better but I'm still seeing some weirdness that I'm having trouble explaining. This is the scenario: Extension that I'm monitoring is idle. I get a transferred event for that extension with the following info:

Primary old call ID: 25
Primary old device ID: 2034713
Secondary old call ID: 681
Secondary old device ID: 2034713
Local connection state: 2
Transferring device ID: 2034713
Transferred device ID: 1039991

After a few minutes I get 3 cleared events for that extension with the following information:

Call ID is 1192
Device ID is 2034544
Releasing device ID is 2034544
Connection state is 0

Call ID is 1473
Device ID is 2034544
Releasing device ID is 2034544
Connection state is 0

Call ID is 1902
Device ID is 2034544
Releasing device ID is 2034544
Connection state is 0

Can you explain what may have happened here? I never get a disconnect for that extension for either of the call ID's in the transfer event.

Thanks,
Ben

Hi Ben,

Unfortunately, I have no way of explaining what is happening without knowing the full station configurations, call flow and TSAPI traces. I cannot deal with such a detailed query on the forum.

If you want me to investigate further, you will need to open a Technical Support ticket. Please note, for non-paying members, there is a fee for this service.

Martin