Interaction Parking is the preferred method for passing metadata — interaction context, console URLs, destination routing — when handing a call from the Voice AI system to your contact centre. It replaces the Mitel Transfer Tool approach.

Parking spaces are allocated and managed within the Voice AI service. When a call is transferred, a free slot is claimed, interaction metadata is stored against it, and the slot identifier is used to retrieve that data and route the call correctly.

On OpenScape Contact Center Enterprise (OSCC-E) the handoff is built from standard OSCC components plus one small additional component:

When the bot transfers a call it SIP Refers to one of the parking numbers. OSCC sees the call arrive and reports the number that was dialled. The parking function uses that number as the parking slot to retrieve the interaction data from the Voice AI service, and the call is queued to an agent with the console link on the agent's screen.

Setup overview:

Each parking space is a number that the Voice AI system can transfer a call to. For the handoff to work, each parking number must meet three requirements:

On OS4K a pilot number is a number whose entry passes calls to Automatic Call Distribution (ACD), shown as ACD=YES, and names a route control group (RCG). OSCC monitors the route control group and decides, for each call that arrives, where it goes. Each parking number needs two things. All the parking numbers can share the route control group that your existing OSCC pilot number already uses:

Create both in the same way as for your existing OSCC pilot number, which is the best template for the values on your system. The commands below are examples for parking number 8100 and route control group 200. Use your own numbers, and consult the Mitel AMO descriptions listed under References at the end of this guide for the full reference on how to build each command.

An example command to add the dial code looks like this:

ADD-WABE adds the dial code. CD is the number, and DAR=STN is the digit analysis result: the number is treated as a station, as it is for your existing pilot.

An example command to add the pilot number entry looks like this:

In this example:

What this creates: a dial code that the switch accepts for 8100, and a pilot number entry that sends calls dialled to 8100 into route control group 200. The full parameter reference is in the AMO DNIT description under References.

Save the OS4K configuration with EXE-UPDAT:BP,ALL;. Anything entered since the last save is lost if the switch restarts. See the AMO UPDAT description under References.

The route control group. Point the parking numbers at the route control group that your existing OSCC pilot number already names (the RCG value in its pilot number entry). That group already has its call flow built and is already known to OSCC, so the new parking numbers need no changes in OSCC's Telephony Center. OSCC reports the number that was dialled as the call's destination, not the group's main pilot number, so each parking number is still told apart.

If you prefer a separate route control group for the parking numbers, build it the same way as your existing one, following the OpenScape Contact Center Communication Platform Integration Guide, and add it in the Manager's Telephony Center by hand, because Config Sync is not supported on OS4K.

A parking slot is only occupied for the moment it takes the transfer to arrive and the parking function to retrieve the interaction data. The number of parking numbers you need depends on how many handoffs are in progress at the same moment, which is usually fewer than you might expect.

Choose a contiguous block of numbers with the same number of digits as your existing numbers, to avoid number analysis conflicts, and leave room to expand. For example, if you use 8100 to 8109, keep 8110 to 8199 free. On OS4K each extra number is one more dial code and one more pilot number entry on the same route control group, so widening the block later is quick.

Navigate to Settings → Parking Lots.

Click Create Parking Lot.

The Execute Workflow Setup section on the parking lot page shows the exact API addresses for your lot, with your region and parking lot ID already filled in. The live address looks like this:

In this example the region is eu and the parking lot ID is 39. Note both: you need them in step 5. Your region is one of eu, us, au or euc.

The {dnis} at the end stands for the Dialled Number Identification Service (DNIS) number: the number that was dialled. The parking function fills it in for you.

The same section also shows an example address, which ends in /parking-lot-slot/example and always returns sample data. Step 9 uses the example slot for testing.

Navigate to Settings → API Tokens and create a new token. This key is used by the parking function (step 5) to retrieve interaction metadata from the Voice AI service.

The parking function is a small Windows DLL that the OSCC Routing Server loads, plus a settings file. They are provided as one download, which contains the DLLs, a sample settings file (parking.ini.example) and the test tools: oscce-parking.zip. If Windows warns about the files, right-click the downloaded zip, choose Properties, tick Unblock and click OK before you extract it. The DLL needs nothing else installed on the server.

The DLL must match the Routing Server process. The OSCC Routing Server is the program trssrvr.exe. In Task Manager, open the Details tab, right-click a column heading, choose Select columns and tick Platform. The Platform column shows whether trssrvr.exe is 32-bit or 64-bit. It is normally 32-bit, so use parking_x86.dll. If it is 64-bit, use parking_x64.dll. A DLL of the wrong type fails to load, and the Custom Function's Test button reports that the function does not exist.

Create a folder on the OSCC server, for example C:\ParkingFunction\, and copy the DLL and the sample settings file from the download into it. Rename the copy of the sample file to parking.ini and edit its values. It holds these three settings, plus comments that explain them:

The file is read on every call, so you can change a setting, or replace the token, without restarting anything.

Open parking.ini in Notepad and replace the example values with your own. Check that the file name is exactly parking.ini. If Windows is hiding file extensions, it is easy to end up with parking.ini.txt, so tick File name extensions on the View tab of File Explorer to see the full names. Save the file as plain text with the default encoding (ANSI or UTF-8). Do not save it as Unicode (UTF-16) or as UTF-8 with BOM, because the function cannot read those.

The Windows account that the OSCC Routing Server runs as needs:

To find the account, look at the User name column for trssrvr.exe on Task Manager's Details tab. parking.ini holds the API token, so allow only that account and your administrators to read it.

Every call writes a block to a daily file, C:\ParkingLogs\parking-yyyy-MM-dd.log. The first line shows which program loaded the DLL and whether it is 32-bit. The token is never written to the log.

If the log folder cannot be written, the function writes to a ParkingLogs folder in the Routing Server account's temporary folder instead, and marks the entry [FALLBACK].

The Routing Server keeps the DLL loaded, so Windows will not let you replace it while OSCC is running. Stop the OSCC server service, wait until it shows Stopped, copy the new file over the old one, and start the service again. Changes to parking.ini do not need a restart.

An example command to stop the service looks like this, where HppcServer is the Windows service name of the OSCC server:

An example command to start it again looks like this:

You can equally use the Windows Services tool. Allow a short while after the service stops before you copy the file, and stop and start the service rather than restarting it in one step.

The workflow is short: it runs the parking function, then queues the call.

Create the workflow. In the Manager, choose File → New → Design Center → Voice → Routing Strategy Workflow. Name it, for example, Interaction Parking, and open it in the Design Editor.

Add the Custom Function. Right-click the canvas, point to Add New Component, and add a Custom Function (under Contact Data). Configure it as follows:

OSCC passes the function only the contact data keys listed under Input Parameters. DESTINATION is supplied by OSCC and holds the number that was dialled. Click Test. It should say "The specified function exists in the specified location." The test checks that OSCC can load the DLL and find the function. It does not call it.

What the function returns. The function makes one request to the Voice AI service and adds the following to the call's contact data:

Reading a live slot clears it in the Voice AI service, so the function makes exactly one request per call and never retries. If the lookup fails, the function still returns normally with LOOKUP_STATUS set, and the call carries on to the queue so the caller is not dropped. Values are limited to 127 characters.

Add the Enqueue. Add an Enqueue component (under Routing). Choose the queue you create in step 7. The Description you give it is what the agent sees as the call's description, for example Voice AI handoff.

Link the components. Select a component and drag from the small square at its centre to the next component: Start to Parking Lookup, and Parking Lookup to Enqueue. A red number in brackets on a component shows how many links it still needs. When none remain, save the workflow (File → Save) and check that the status bar says Complete.

OSCC-E does not dial the destination that the Voice AI service returns. A call reaches an agent, with the console link, through a queue, so PARK_DEST works as a routing key: a value that your workflow turns into a queue.

In the Voice AI service. A bot's Transfer Tool can hold several destinations that share one parking lot. For each place a call can go, such as Sales or Support, add a destination (Voice Bots → your bot → Tools → Transfer Tool → Add Destination):

Use digits for the codes. The Destination field is described as an extension number for parking, so a number is the safest value, and numbers are also the safest values to compare in a decision. The Transfer Tool guide covers the other fields.

In the workflow. After the Parking Lookup, add a Contact Data Decision for each code. It tests one contact data key against one value, and sends the call down a Yes exit or a No exit:

The Operator list offers Equal, Not equal to, Exists, Over and Under. There is no wildcard operator, so each code needs its own Equal test. Because the codes are numbers, a block of codes can instead be covered with Over and Under, for example Over 99 and Under 200 for the codes 100 to 199.

Start the chain with an Exists test on PARK_DEST, whose No exit goes to the fallback queue. Then chain one Equal test for each code: the Yes exit goes to an Enqueue for that queue, and the No exit goes to the next test. End the chain with an Enqueue to the fallback queue:

Always end with a fallback. If the lookup fails, PARK_DEST is not set, so the Exists test sends the call to the fallback and the caller is not dropped. Choose a queue that is staffed at all times.

Your contact centre already has rules for opening hours, priorities, overflow and skills. Reuse them instead of copying them into the parking workflow. There are two ways to do it:

The second way keeps the parking-specific part in one place and leaves your department workflows as they are, which makes it easier to change or remove later. Link to a workflow, or a part of one, that starts after any menu or prompt, so a parked caller is not asked again what the bot has already asked. Whichever way you choose, the queue that finally takes the call needs the supplemental information address from step 7.

OSCC can display an address to the agent when a call is delivered from a queue. This is the queue's supplemental information address, and it can contain contact data keys written between tildes. OSCC fills them in when the call is queued, which is why the parking function has already set CONSOLE_URL by then.

We recommend a dedicated queue for handed-off calls, so that only those calls show a console link. Create one, or use an existing queue:

A new queue also needs its steps set up (the group of agents that handle these calls), in the same way as your other voice queues.

What the agent sees. In Agent Portal Web, the call's Active Voice panel shows the queue name and the Description from the Enqueue, the Address as a clickable link to the live interaction in the console, and CONSOLE_URL, HIST_URL and PARK_DEST as rows in the Contact data table, alongside a DESTINATION row with the number that was dialled. The agent needs to be able to sign in to the console to use the link.

OSCC runs one voice routing strategy for every call. Choose one of the following.

Option A: make the parking workflow the default. Use this only if all voice calls on this OSCC system are parking calls, for example on a dedicated or test system. In the Manager choose Tools → Options → System Settings → Voice → General, and under Default select your parking workflow as the Routing strategy. This applies to every voice call.

Option B: link to it from your existing default workflow. Use this when the contact centre also handles other calls.

To reuse your existing department workflows instead of queueing inside the parking workflow, see Fit the workflow into your existing design in step 6.

Before you wire the function into a workflow, run it directly. The test tool calltest_x86.exe, supplied with the DLL, calls the function the way OSCC does. Use the 64-bit tool with the 64-bit DLL. An example command looks like this, run from the folder that holds the DLL and parking.ini:

It calls ParkingLookup in parking_x86.dll and passes PARK_SLOT=example, as if a workflow had set it. The example slot returns sample data, so no real parked interaction is used. A working setup prints three pairs: CONSOLE_URL, HIST_URL and PARK_DEST. A single LOOKUP_STATUS pair means something is wrong: see Troubleshooting. The day's log shows the full request.

The example slot always returns sample data and can be used as many times as you like, so no real parked interaction is needed.

To check that a failed lookup does not lose the call, temporarily put a wrong value in BearerToken in parking.ini and call a parking number. The call should reach the fallback queue, the contact data should show LOOKUP_STATUS = AUTH, and the log should show the failed lookup. Put the correct token back afterwards.

Make a call to the Voice AI bot and ask it to transfer you. The agent should receive the call with the console link for that interaction. Check the day's log: it should show a lookup with http 200 and result : OK. The slot is cleared when the function reads it, so a second lookup of the same slot returns NOT_FOUND until another call is parked in it.

The log (C:\ParkingLogs\parking-yyyy-MM-dd.log) is the first place to look: it shows what OSCC passed in, the request made and the result.

Once the workflow has been set up, you should configure your transfer tools to use the parking lots and destination information.

For more information, please view the Interaction Parking transfer tool guides here

Once this guide is complete, proceed to:

If you encounter issues after setup, refer to:

The commands and settings in this guide come from the Mitel documents below. Page numbers refer to the V12 PDF guides. The AMO examples in step 1 were also run on an OpenScape 4000 V11 R1 system.

All the V12 guides are listed in the OpenScape Contact Center Enterprise administration index, and the OpenScape 4000 documentation in the OpenScape 4000 index of the Mitel Document Center.

Plain-English meanings of the abbreviations and technical terms used in this guide.