No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

How to analyze secondary dial problem on U1910

Publication Date:  2016-10-07 Views:  238 Downloads:  0
Issue Description
Customer has an U1910 and reports a strange behavior with the Automatic Switchboard.

When he calls the switchboard from an IMS network, the “Please enter the extension number” message is received.

The extension 102# is typed and then the response is “Sorry, the requested number doesn’t exist Please check the number and try again”.

The number actually exists in the database.

U1910 firmware version: V200R003C20SPC200
Handling Process

1. Turn on the RFC2833 switch on U1910

First step is to make sure the RFC2833 is activated on the U1910, so we need to input the following commands:

[%eSpace U1911(config)]#config cdsp rfc2833 switch on

 

====  Command executed success !  ====

// This command activates the RFC2833

 

[%eSpace U1911(config)]#show cdsp argu

 

CDSP Arguments

 

Faxmode: 1

T38RedIEPNum: 3

T38TCFMode: 0

CheckRTPPackIP: 0

CheckRTPPackUDP: 0

ECAN: 6

gain: 14

dtmfpowerlevel: 9

DTMFOnTime: 100

DTMFOffTime: 100

RFC2833Flag: 1

RedAudioFlag: 0

RedFaxFlag: 0

RedModemFlag: 0

 

====  Command executed success !  ====

 

// CSDP arguments display

 

2. Debug log analysis

 

The debug logs from U1910 are exported and analyzed.

As it can be seen, the called extension was 1102, which is wrong.

Search by "The called Number is:"

In the next part we analyze why this unwanted number was sent to the Automatic Switchboard.

3. Capture analysis 

Analyzing the 200OK message we can confirm the both parts negotiated the use of RFC2833:

Analyzing each RTP pachet sent by the IMS, we found that the extention 102# is correctly sent to the U1910:

 

Each RTP packet detailed:

 

4. Inboud DTMF analysis

 

On the above graph, generated from the network capture, it can be seen that the U1910 received the first DTMF signal 1 and then it received the RFC2833 signal 1.

The both signal protocols were implemented on the U1910 in order to achieve a fault-tolerance which lead to the analysis of the first DTMF signal 1.

So this signal was added to the RFC2833 signal that was negotiated on the beginning.

 

 

Root Cause

The both signal protocols were implemented on the U1910 in order to achieve a fault-tolerance which lead to the analysis of the first DTMF signal 1.

Therefore, this signal was added to the RFC2833 signal that was negotiated on the beginning. 

Having two signal protocols configured on the U1910, the receiving signal was mixed up and the extension became 1102.

Solution
Because on the U1910 it is not recommended to disable one of the two signal protocols, the proper solution is to disable one on the IMS side.

So, on the IMS side was chosen the DTMF shortinfo on the trunk and the RFC2833 was disabled.

END