Has a very interesting problem with TMS and CMS integration piece. For any TMS meeting scheduled with dial out participants when the participant phone number had a zero prefix (Australian Standard for PSTN breakout), the TMS / CMS system would repeatedly dial the participant, even though the participant had already accepted the first TMS/CMS call out and had successfully joined the meeting.
This only occurred for phone numbers with a zero prefix. Hence phone number with +61 formation, or the straight 10 digit (again based in Australia).
Explanation
In CMS I have configured for user to dial a phone number using any standard means.. Straight 10-digit number, prefix with zero, plus e164 format, extension etc.. So catching all of the users dialling behaviours and making sure they route.. I transformed all of the above different dialling behaviours to a standard plus e164 format.. So essentially globalising the dialled number.
Any number leaving CMS is in a plus e164 format. Easy for the CUCM guys to manage routes.
TMS dialled number was in a zero prefix format. Example 00408842… so worries… TMS would make an API call to CMS to create a callleg for the above number. CMS would transform the number into a plus e164 number. So the number would become +61408842… CMS would route this to CUCM for PSTN breakout. CUCM would then localise the number into a compliant Telco format. The number now became 0408842…
The call would be dialled.. The participant would answer and be joined the CMS Meeting.. All good you say.. Well not quite yet.. While CMS had confirmed that indeed the participant had joined the meeting.. TMS never received such confirmation..
After CMS dials out to the participant, TMS will then send a GET request to CMS asking if a Call Leg has been established for the participant dialled. To break this down TMS sends a GET /api/v1/callLeg filter with 00408842… (notice this is the number TMS sent to CMS to be dialled originally). However.. CMS has no such Call Leg… TMS, then resends a POST request to CMS to create a Call Leg for the 00408842… so CMS the dials out to the participant again. The participant receives another call, even though they are already in the meeting!
This happens multiple times until TMS gives up.. (configurable).
Why is this So?
CMS contains a couple of key pieces of information in the Call Leg.
1. RemoteParty
2. OrginalRemoteParty
Remote Party is the connected Called Party ID. Remember how I was saying CUCM (or the CUBE) will localise the called number to comply with Telco Standards.. The CUCM (or CUBE) will send back the connected called ID to CMS.. This is then documented for the RemoteParty ID.
Original Remote Party ID is the dialled number from CMS to CUCM. Essentially this is the ‘Transformed’ number.
Following my case above.. The CMS Call Leg will have the below
remoteParty = 0408842…
orginalRemoteParty = +61408842…
By now, you’re probably putting the puzzle together.. The number TMS requested to be dialled is no where to be seen in the Call Leg, hence TMS believes the participant did not join the meeting (based in the results of the GET callLeg request by TMS), so TMS attempts a redial.
The Fix (for now)
To resolve this issue, allow the dialled number from TMS to be passed through CMS without transformation onto the CUCM Server. This reflects in the Original Remote Party field as being the number that TMS dialled.. Hence the GET request for TMS matches the dialled number.