Our DMCC application uses Call Control Services on AES 4.1 and CM 5.0.

In the case of external parties involved in a call, we've noticed that the call control events sometimes deliver only a dynamic device identifiert (Txxx#y) instaed of the real external party number.

Is there another way to determine the real number of the external party?
Or is there a configuration parameter on the CM to generally enable the submission of external party numbers?

Regards,
Claus

Hi, Claus:

For incoming calls, the DeliveredEvent gives the ANI in the callingDevice. For incoming calls over PRI facilities, "calling number" from the ISDN SETUP message or its assigned trunk identifier is specified. If the "calling number" does not exist, it is NULL in the DeliveredEvent.

For outgoing calls, it's a little more complicated. When you've made a call to an external number, the NetworkReachedEvent has both the called number and the trunk ID (i.e. "Txxx#y"). However, that event is not supported in AES 4.1. It will be supported in AES 5.0. A possible workaround is that since in MakeCall or ConsultationCall you know the digits of the external number you're calling, and since the MakeCallResponse and ConsultationCallResponse contain the call ID of the new call, you can save the new call ID somewhere along with that external number, and when you get, say, an EstablishedEvent when someone answers the external number, use the call ID to determine the digits of the external number.

Hope that helps.

Regards,

Nick

Sorry to steal the thread but what about application that just monitor and don't originate calls is there a way to get the called number?

Hi, Ilana:

Good question. I was just about to follow up about that with something I just found out. It may not address your question completely, but it's useful information nonetheless. As you probably know, an application monitoring a device will get events pertaining to calls that the device is on. For calls to external numbers, some events other than NetworkReachedEvent can be used to correlate called numbers with trunk IDs. For example, both a DeliveredEvent and an EstablishedEvent contain a calledDevice element, and the DeviceID in the calledDevice has the called party's number.

However, the amount of signaling information available when making external calls will vary depending on the type of the trunk. For example, in my tests, calls to a nearby land line resulted in both Delivered and Established events, but calls to a mobile number resulted only in an EstablishedEvent. I am told that analog trunks lack even this amount of signaling, so your mileage may vary depending on the operating environment.

That being said, Ilana, are you also wondering how to discover the number of the external party in cases such as transferred or conferenced calls?

Regards,

Nick

Yes I guess it's a big mistery for transfered devices as well any suggestions? I just wish there was an easy way to assocoate the display with the callid

Hi Nick,

our application also just monitors calls via SO or SSC.

For incoming external calls, we can use the'callingDevice' information of the EstablihedEvent which contains the complete external number.

In the case of outgoing calls, the content of Established event's 'celledDevice' is simply '<notknown>'.
So, in contrast to your last post, we cannot retrieve any information about the called external party number.

Any hints?

Reagrds,
Claus

Hi, Claus:

The calledDevice included in the Established event actually comes from the ISDN SETUP message that your trunk service provider sends back to CM, even in the case of outgoing calls. If the service provider doesn't include the called number their SETUP message, it shows up as "not known" in the Established event.

Hope that helps.

Regards,

Nick

Hi Nick,

I'm a colleage of Claus. We do not understand, why the external number of an outgoing call will be read out of the setup message of the service provider. For an outgoing call the external number has to be avilable to originate the call.
The PBX sends the number to sevice provider via. a setup message. Not the service provider the PBX.

Please could you give us more details?

Regards
Kay

Hi, Kay:

What I said about the ISDN SETUP message is from the TSAPI programmer's reference. I agree that it's confusing, but there are a lot of factors at work in the implementation, and it's difficult to describe how they affect the programmer without going into too much detail.

One situation in which CM doesn't know the calledDevice number at all is when the leading digits of a dialed number cause CM to seize a trunk early, before all of the digits are dialed (i.e. an ISDN SETUP message without the called number). ISDN is not my area of expertise, but I would be happy to look into this more for you. So I can be prepared when I consult an expert, can you tell me about your environment? It would be useful to know the trunk types and the country or countries in which the trunks exist. Also, is the calledDevice "<not known>" in all of your Established events, or only in some of them? If only in some of them, can you see what is different about those calls? Are the calls where the Established event's calledDevice is "<not known>" going over the same trunk? Are they going to places that don't have end-to-end ISDN?

Regards,

Nick

Hi Nick,

we've traced the ISDN protocol of our outgoing calls with an ISDN analyzer.

It seems that you're right as the CM sends out the ISDN SETUP very early, without containing the dialed digits. So looking for the called party number in SETUP ACK would never lead to success.

Is thera a chance to retrieve the called party number from another ISDN mesage, e.g. ALERTING or CONNECT?

You've announced the implementation of NetworkReachedEvent for AES 5.0. Is there already a scheled release date for this version of AES?

With respect to your questions, I can give the the following information:
We are located in Germany, but we've seen similiar problems at our customers in Switzerland and the Netherlands.
Trunk type is ISDN S0.
CalledDevice is set to '>notknown>' in every EstablishedEvent for outgoing calls.

Regards,
Claus

Hi, Claus:

Thanks for providing that information. I'm asking around to find out about possible workarounds for you. I'll post a follow-up response when I find out more.

Regards,

Nick

Hi, Claus:

Does the ISDN SETUP message contain no digits at all? Or does it contain the first few digits dialed, but not the complete number? Are you using trunk access code (TAC) dialing?

Regards,

Nick

Hi Nick,

the SETUP message does not contain any dialed digits.
The digits are transmitted via subsequent INFORMATION messages.

If needed, I can send you the analyzer protocols via email.

Yes, we are using TAC dialing.

Regards,
Claus

Hi, Claus:

Thanks for your response. The ISDN trace isn't necessary. It is useful to know that you're doing TAC dialing. I'm in a somewhat involved conversation with some experts in TSAPI, ASAI, and ISDN about your situation. It might be a few more days before I have the conclusion of the conversation for you, as one of the experts is out of the office until Monday. What I know so far is that ASAI (the protocol that TSAPI uses to communicate with CM) isn't aware of the contents of the ISDN INFORMATION messages, but CM clearly is. In short, I'm still investigating and will respond with more information as soon as I can.

Regards,

Nick

Hi, Claus:

Just posting to let you know that we are still working on this issue. I'll respond again when I know more. I hope that will be within a day or two, but wait and see.

Regards,

Nick