cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
557
Views
0
Helpful
3
Replies

Called DN "D" in RTMT Real-Time Data

automatyck
Level 1
Level 1

Does anyone know what is meant by a letter "D" in the "Called DN" column of RTMT Real Time Data? Please see the attached screenshot.

 

letterd.png

1 Accepted Solution

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame
DTMF includes [0-9\*#A-D] so technically that “D” is a dialable pattern. The unallocated number makes sense though since it’s highly unlikely that you have an actual pattern for it. I’m unaware of a special use case for that letter, especially by itself. The nearest example I’m aware of are recording call legs that start with “b” and have a UID after them (eg b1234567890). Unity Connection uses the A-D DTMF characters during cross-sever transfer/sign-in, but those are mid-call digits and shouldn’t appear as a call attempt on their own.

Did you spot this fast enough to pull CCM SDI logs and look for that call?

View solution in original post

3 Replies 3

Jonathan Schulenberg
Hall of Fame
Hall of Fame
DTMF includes [0-9\*#A-D] so technically that “D” is a dialable pattern. The unallocated number makes sense though since it’s highly unlikely that you have an actual pattern for it. I’m unaware of a special use case for that letter, especially by itself. The nearest example I’m aware of are recording call legs that start with “b” and have a UID after them (eg b1234567890). Unity Connection uses the A-D DTMF characters during cross-sever transfer/sign-in, but those are mid-call digits and shouldn’t appear as a call attempt on their own.

Did you spot this fast enough to pull CCM SDI logs and look for that call?

Thanks for the information Jonathan.

 

I wasn't aware that D was a legitimate DTMF code. The weird thing about these calls is that they are originating from a SCCP PLAR line on a VG310 voice gateway. The analog endpoint is not programmed to dial any numbers--it just triggers the PLAR when it goes off hook--so it's a mystery as to how the D is getting inserted.

 

The phone place a call like these a few times a day so I'll pull the SDI logs when I'm back in the office this week and take a look!

I was able to identify the source of the issue after further troubleshooting and wanted to report back in case it helps someone else.

 

In our use case, we have analog single-button intercom phones that are connected to a VG310 gateway with an SCCP PLAR configured on the line. The phone is used in an access control scenario, where the recipient of the call is able to remotely trigger one of the phone's external relays to unlock a door when a call in placed. After putting the call through a DTMF decoder, I discovered that the phone generates a "D" DTMF confirmation code when one of the relays is activated.
 

As to why "D" was showing up in the CDR logs, it appears that the CDR logs sometimes don't populate correctly for very brief calls (i.e., less than 5s in duration). During the testing, I found that if the call was answered very quickly, the relay activated, and the call terminated, the CDR logs would show that the analog phone had dialed "D" rather than the actual SCCP PLAR number.

 

Thanks for the tip about the SDI logs Jonathan--checking them helped to put us on the right track.