In the callIntercepted method inside a CallListener, call.getCalledParty().getHandle() returns the extension of the person being called. How do I identify the DID that was actually dialed?

Hi Walter, unfortunately at this point that information is not available to snap-in developers. Depending on the configuration of Communication Manager and Session Manager, the called handle will match the DID. In other cases (such as yours, evidently), they will not match.

Darn. That is going to be a problem for me. My service communicates back to our cloud application. It sends in the caller phone number and who was called to do some approval processing. Since multiple unassociated companies will be utilizing it, an extension alone will not allow me to identify who was called.

There is one thing that might help you. The method UserData.getAllCommunicationAddresses returns the list of all addresses that have been provisioned in System Manager for the given address. If the E.164 number has been provisioned, then you'll be able to retrieve it from the list.

https://www.devconnectprogram.com/media/global/products_resources/avaya_aura_collaboration_environment/releases/2_0_2/javadoc/com/avaya/collaboration/data/api/UserData.html#getAllCommunicationAddresses(java.lang.String)

Thanks for the suggestion. I'm giving this a shot.

Is there something I can use from the Call object that is the enterprise id? It seems to want the user's login name, which I thought might be the handle (extension). But that ends up returning null for the results of the getAllCommunicationAddresses method.

OK, figured out I needed to add "@collaborator.avay.com" to the extension. Unfortunately what I got back was one record named "Primary" with and Address Type of "AVAYA_SIP" and the address of exactly what I sent in for the enterprise id.

Did I make a left turn somewhere?

Well, that's because the Collaboratory system hasn't been administered with E.164 numbers. In a production system, the users will often (but not always) be administered in System Manager with an E.164 handle.

Regarding the domain, I forgot to mention a step. What you did only worked because the login "name" of the "users" in Collaboratory is the same as their handle. In a real enterprise situation, that won't be the case. The handle will be the extension number and the login will be something alphanumeric like an email address. So you need to do two steps:

1. getLoginNameByParticipant() returns the login name.
2. pass this login name to getAllCommunicationAddresses()

One other point. This sort of resolution of SIP handle to E.164 won't be required depending on CM (or other SIP trunk gateway / SBC) configuration. CM can be configured such that all calling / called numbers are in E.164 format when they are sent to SM. It can similarly do adaptation on incoming calls to convert them back to the extensions. If our mutual customers' systems are provisioned as such, and if E.164 is provisioned as a handle for the user in SMGR, then you'll get what you want without having to use the User Data class.

One other point. This sort of resolution of SIP handle to E.164 won't be required depending on CM (or other SIP trunk gateway / SBC) configuration. CM can be configured such that all calling / called numbers are in 10 digit format when they are sent to SM. It can similarly do adaptation on incoming calls to convert them back to the extensions. If our mutual customers' systems are provisioned as such, and if the 10 digit number is provisioned as a handle for the user in SMGR, then you'll get what you want without having to use the User Data class.

We're looking into whether we can configure Collaboratory in this fashion.

OK, so for the following scenario. I have a direct DID line of 123-456-7890 and the company has a main line of 098-765-4321 and my ext. is 999. If I receive a call over my direct DID, just receiving the 123-456-7890 is fine. That is a unique number. When I receive a call through the company line of 098-765-4321, I would still need that number and my 999 extension to be able to identify (from my system) who is really being called.

Does that sound like it is going to be possible?

That depends on what is doing the auto-attendant function to map to extension 999. We'd really have to look at the particular call flow. If it's CM auto-attendant, it might be difficult (and is perhaps a non-supported configuration) to get CM to send the call out to SM between auto-attendant and terming to the station.