We want to inspire you for our UCC solution! To do this, we use cookies to provide you with an optimal and personalised website experience. Clicking on "Accept all" allows us to process this data and share it with third-party providers in accordance with our privacy policy. Here you can also adjust the cookie settings at any time.
DTMF analysis and troubleshooting (SIP)
There is always an up-to-date article in our handbook (linked here V8):
https://help.c4b.com/de/xphone-connect-8/admin/#8288.htm
Problem
It can happen that despite correct protocol negotiation between XCC and PBX via SDP, the outband DTMF signals (RTP event according to RFC 2833) are transmitted incorrectly by the PBX. The signals are then not recognised by the XCC and there is no reaction to DTMF inputs.
Cause
The SDP header contains the wrong DTMF payload type after protocol negotiation. The XCC default value for the DTMF payload type is 98, it can happen that either the PBX does not support this payload type or sends the RTP events with a different payload type.
Solution
The parameter XccDtmfPayloadType allows the manual correction of the transmitted payload type, the DTMF signals are recognised correctly again. This parameter can be set in the advanced settings of the SIP gateway.
Determine the payload type to be used there as follows (see also example below):
- Determine call direction (Inbound or Outbound)
- Determine the sender of the DTMF signals (AnyDevice or conversation partner).
- Create and evaluate network trace (Npcap, Wireshark)
- Determine payload type in the SIP message (depending on call direction in INVITE or 200 OK)
- Filter RTP events with udp.dstport == <port> && ip.dst == <IP address> && rtpevent
- Determine the payload type in the RTP event
- If necessary, correct the payload type for the XCC (parameter XccDtmfPayloadType).
Example of the procedure
Situation:
- Outbound call of an AnyDevice
- DTMF is sent by the AnyDevice
- DTMF Payload Type is to be checked
The procedure:
1. Negotiate the DTMF Payload Type in the SDP header:
In this case, the SDP header from the SIP message "200 OK" of the first call leg is to be analysed (AnyDevice side).
A payload type ("Media Format") of 98 was negotiated here, the default value of the XCC.
2. Determine the RTP events of the DTMF signals:
A filter rule in Wireshark lists the DTMF signals sent by the AnyDevice.
3. Determine the payload type of the RTP events:
Select one of the RTP events filtered above and read out the payload type in the area below.
Here, too, the payload type is 98 and thus correctly transmitted.
4. If the two determined types do not match, this can be corrected via the parameter XccDtmfPayloadType in the advanced settings of the SIP gateway. For this purpose, the payload type of the PBX determined in step 1 is passed on to the XCC via XccDtmfPayloadType and corrected there.
Information from the XCC Gateway Log
The following information can be taken from the log file of the XCC gateway, for example:
- Status of the AnyDevice lines
- Creation of network traces with the help of Npcap
- Status of the XCC gateway
Activating the logging
For an error analysis, the corresponding log files are always required. An essential advantage is to be able to read the network communication. The Npcap driver is required for recording the network traffic on the network card. This can be found in the installation directory of the server under Tools.
The corresponding logging can be started via the administration in XPhone Connect Server. The corresponding log levels (debug messages) can be set under System settings > Logging > Telephony gateways. Important here are the gateways XCC and the SIP gateway to the telephone system.
As soon as the log level settings have been saved, the log files are written to the specified file path.