Hello Team,

I am developing one Snap-In which has need to capture Authorization Code entered by user, below is the brief description of my requirement -

Any external call (via PRI) will be routed to the Session Manager and the Session Manager will sequence a Breeze Snap-In that will refer to a database and check if the Authorization Code entered by the user has the required permission to dial out (Local/STD/ISD). Based on that the Snap-In should send the request to the CM and the call should be routed accordingly via the PRI.

The Snap-In should be able to monitor the call from start to finish to be able to create a record for the call with details (start time, end time, duration, extension, auth code used, trunk used, user name etc.)

Please suggest me on following things-

1) How can I get Authorization code entered by user into my Snap-In? ( more about Authorization Code- https://downloads.avaya.com/elmodocs2/merlin/r1_5/html/features/authorization%20codes/1.htm)

2) How to find which trunk is used by particular call etc?

Regards,
Tanaji Bhale.

Can anyone please suggest me on this? it is blocker for me and I don't find any relevant information on internet.

Are you looking to do this via a Breeze Platform Snap-in (written in Java) or Engagement Designer (workflow created via ED)? That would be the first info we would need?

How important is it to capture the trunk information? Chances are that will be very difficult to get because of all the different systems you will have to jump through.

Thanks for reply.

I am planning to use Breeze Platform Snap-In(written in Java). The trunk information is needed as part of CDR(Call detail records) records used for some business purpose that I'm not aware.

The CDR records need to have information such as call start time, end time, duration, authorization code used, extension, trunk used, username etc. Can you please suggest the best way to get this information into my snap-in? I'm planning to do this using snap-in callbacks but I believe this can be achieved by processing CDR files generated by Session Manager. Please suggest better option.

Regards,
Tanaji Bhale.

Start time, end-time, duration, auth code, and extension should be easy enough. Most of that can be captured by subscribing to the events sub-system and recording those events. Not sure what username you are thinking about -- but you might need to match that yourself.

The way you can get the auth code is by doing a "play and collect" command via the AMS. There is a play and collect class you can call in the SDK for this. It's pretty straight forward.

The TAC is the most difficult part. I imagine the way you could collect that would be to do an OSSI connection to CM, and somehow match the latest trunk call on the SIP trunk to ASM with the incoming trunk from your ISDN. Another option would be to collect the raw CDR data from CM via the RSP Protocol and somehow parse out the TAC information you need. That would most likely be the most accurate way to do it, but it will probably involve a lot more work.

-Nick

OSSI is a proprietary protocol and is not documented/supported for third party use. Even utilizing OSSI (or the pubically available AE Services System Management Service) I don't know how one could discern the 'most recent' trunk call. I feel using the CDR information provided by CM (assuming there is an available port, or one can get this application the data stream via some mechanism) is the right approach - assuming the outbound call runs through CM. The calling/called number can be matched, and the actual trunk group (TAC) used determined.

SMGR also has a CDR output stream. I know less about that stream and how one can access it. If one used the SMGR CDR stream, I do not believe SMGR knows the trunk group used by CM. However please be cognizant that depending on how the routing is setup in SMGR, the call may not route out to through CM, the call may go direct to the PSTN via a SIP trunk on SM/SMGR. If that is possible in your environment given how routing occurs (now or in the future) it would have major impact on your application.

Thank you guys for the reply.

@Nick, You said authorization code can be captured by "play and collect" command via the AMS. => Do you mean I should collect it as DTMF numbers? please correct me if I'm wrong.

@John, I will follow the second approach you guys suggested for trunk information(parsing CDR files generated by CM).

Now I'm finding some way to pass this Authorization Code captured by Snap-In to CM -
Why this is needed-->because in normal flow(without snap-in interception) CM send this authorization code field to some call billing software or it writes to CDR files and then call billing software fetches this information for billing purpose (this is what I understood so far). now if we intercept the call at breeze/in snap-in to put some business logic then CM will not have this authorization code field to be send to call billing software or to write into CDR files, hence billing software will not work that's why somehow I need to pass this authorization code to CM thus not to impact on billing things.

Approaches I looked for-
1) putting authorization code, UCID into context store or as context id of call and then call billing software should be able to retrieve authorization code & UCID for its billing purpose, but this require additional change in call billing software which is not possible I guess. (so this the last approach or even not possible)

So my question is what would be the best/simple way to pass this authorization code to CM? so that CM will continue to send this authorization code to call billing software or continue to write authorization code to CDR files for billing purpose.

I hope this helps to understand what I'm looking for, waiting for earlier response.

Regards,
Tanaji Bhale.

Can someone please suggest me on my last question? I'm blocked due to this and not able to find relevant information on internet.

Regards,
Tanaji Bhale.

Consider how authorization codes are dealt with if your application was not in the call path. A SIP trunk or station connects to CM and dials a digit sequence that indicates an outbound trunk call. As CM analyzes the route out of the PBX, the inbound trunk/station FRL is insufficient to seize the outbound trunk(s) identified for the call. CM looks and auth codes are enabled/provisioned and prompts the caller for an auth code (stutter dial tone IIRP). That prompts the caller to provide an auth code. CM is willing to collect the auth code based on the DTMF signaling properties setup for the originating party (depending on the interface: DTMF in band, or RTP payload). This approach is only viable if CM is configured to collect authorization codes, and the inbound trunk FRL is insufficient to seize outbound resources, otherwise CM will not prompt/collect an auth code, nor report one to CDR.

I don't believe CM has any allowance to receive the auth code within the initial SIP signalling. If it does it would be via some form of address that would include an end of dialing indication to separate the PSTN destination from the auth code... e.g. 912125551212#987654321@avaya.com

yes I think Nick meant you need to prompt the caller and then collect the user's auth code as DTMF. and I am implying your application needs to transmit the auth code to CM as DTMF. That is assuming that the Breeze collect step does a filtered DTMF collect, which would be normal behavior by most collectors in this day and age.

Thanks John for the information.