Hi,

I'm trying to determine if a call is inbound, outbound, or internal. When receiving an EstablishedEvent, let's call it evt, I check whether each end of the call is internal or not, with this code:

evt.getCallingDevice().getDeviceIdentifier().getTypeOfNumber()

evt.getAnsweringDevice().getDeviceIdentifier().getTypeOfNumber()

The result, though, depends on which device the call control listener is. For example, for an internal call, calling a station extension, with the call control listener:

- on the calling device: type of calling device is 'other', type of answering device is 'explicitPrivate:localNumber'
- on the answering device: type of calling device is 'explicitPrivate:localNumber', type of answering device is 'other'

Is there a different, more reliable way of finding out if a call is inbound, outbound, or internal?

We are using CM 4, AES 6.1, and DMCC SDK 6.3.1.

Thanks,
Gilles

The values in getTypeOfNumber() will depend on how your dialplan is configured on the Communication Manager. Setting up a dialplan correctly is not a trivial task. You will probably find that using getTypeOfNumber() will work better on a properly maintained production environment than it will in a lab.

There are other cues that you can use which you will probably find more consistent:

o If e.getTrunkGroup is empty, the call is internal. If there is a value, the call is incoming/outgoing
o If e.getCallingDeviceId matches the monitored device, then this is an outgoing call

Martin

Hi Martin,

I guess it works in most cases. For example, there's the tricky case of an incoming call going to a VDN, and the call ends up at a station which is not monitored, which will look just the same as the case of an outgoing call from an unmonitored station to a VDN, and the call ends up going outside. In both cases, the calling device, as well as the called device, will not match any monitored device, so all I'll be able to say is that it's either an incoming or outgoing call.

I don't think it is going to be an issue, though, and it's much better than getTypeOfNumber(). And if it happens, then I can always try getTypeOfNumber()...

Thank you for the help!

Gilles

Martin,

The documentation for the DeliveredEvent and EstablishedEvent classes indicates that the property networkCallingDevice is provided only for external incoming calls. Is it always set for external calls? If so, I could rely on this property, combined with getTrunkGroup(), to classify the call as either incoming or outgoing.

Thanks,
Gilles

I haven't come across that parameter before. I made an inter-switch call in my lab and it was not populated so I don't think you can rely on receiving it.

I suspect that it is generated at the far switch so you will only receive it if the other switch generates it and the trunks in between are able & willing to transport it.

Martin

Oh well. Thanks for your help!

Gilles

I actually have one more question. I just noticed the DeliveredEvent has another property, 'associatedCallingDevice', which, according to the documentation 'is mandatory for all external incoming calls and shall not be provided otherwise'. Could you please confirm this is the case.

Thanks,
Gilles

Never heard of it. I also don't see it in the delivered event I get in the Dashboard. Where did you read about it?

Martin

It's in the DMCC API Javadoc documentation for ch.ecma.csta.binding.DeliveredEvent. The page is docs/xml/ch/ecma/csta/binding/DeliveredEvent.html in the DMCC sdk.

Thanks,
Gilles

It looks like it is defined in te eCSTA standard. However, that information is not available in TSAPI so there is no way for DMCC to provide it.

Martin

I've implemented your suggestions. I'm adding another check, just to be on the safe side, in case I'm getting a call going through a monitored VDN, but the calling or answering device is not monitored: I'm getting the list of all stations, agents, splits, and VDNs through SMS, and I'm checking if the calling or answering device is one of them. Could they be something else? Should I check against the list of all extensions on the PBX?

Thanks,
Gilles