CM: DTMF tones do not go through when transferring call from external SIP caller to external ISDN survey system

Doc ID    SOLN298012
Version:    2.0
Status:    Published
Published date:    10 May 2018
Created Date:    11 Oct 2016
Author:   
Levente Szabo
 

Details

CM: 6.3.10.0-SP10
G450: 36 .13 .0

Avaya's SBC and the deep World SIP Gateway connection, feedback Inbound can receive DTMF messages, but the exhaled message is not received DTMF.

Problem Clarification

External caller via SIP trunk is connected to agent, call is OK. After the agent finished with the call, transfers the external caller to an external survey system which is reachable via an ISDN trunk. So after the agent complets the transfer, only the external caller over the SIP trunk and the external survey system over the ISDN trunk are connected. The ISDN trunk is hanging off a G450 branch gateway. So at this point the agent is already dropped from the call and only the SIP and the ISDN trunks are connected and the RTP flows from the SIP provider (via an SBC) to the G450 where it is converted to from IP to TDM and sent to the survey system over the ISDN B-channel, however, the survey system does not recognize the DTMF tones thus the caller cannot leave a feedback.

Cause

Provider issue, as the provider's third party SIP device (SBC) does not use the negotiated Dynamic RTP type. Initially SBC and CM negotiates the Dynamic RTP type in SIP SDP, we can see both in the INVITE and the corresponding 200OK:  "a=rtpmap:96 telephone-event/8000" so type 96 is agreed but in a Wireshark packet capture trace on the same call captured on the network we can notice that the SBC sends the DTMF using a different Dynamic RTP type:
Payload type: DynamicRTP-type-101 (101)
Even though the digits are arriving to CM’s media gateway from SIP provider’s SBC, as the SBC is not using the negotiated RTP event-type of 96, rather the SBC is sending payload type 101, which is the actual cause of the problem, hence CM won’t relay the digits to the ISDN trunk (no e-sig):

- 15:28:28: CM sending re-INVITE with SDP:
v=0
o=- 1474036070 4 IN IP4 10.44.54.100
s=-
c=IN IP4 10.44.54.20
b=AS:64
t=0 0
m=audio 16574 RTP/AVP 18 96
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=ptime:20

- 15:28:28: far end (SBC) sends SDP in SIP 200-OK:
v=0
o=Redwood_INX 562038301 520710 IN IP4 10.251.0.36
s=Redwood Media Server
c=IN IP4 10.251.0.36
t=0 0
m=audio 50404 RTP/AVP 18 96
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=ptime:20

- 15:29:55: SIP trunk releases the call

So between 15:28:28 and 15:29:55 the SIP user’s DTMF must be arriving from 10.251.0.36:50404 (SBC) to 10.44.54.20:16574 (CM’s G450 media gateway) in RTP telephony-event (payload) type 96.

Based on the Wireshark capture:
We can see that indeed the SIP trunk’s far end sends the following DTMF sequence in RTP event: 9 9 8 7 6

However, even though the digits are arriving to CM’s media gateway from SIP provider’s SBC, it’s not using the negotiated RTP event-type of 96, rather the SBC is sending payload type 101, which is the actual cause of the problem, hence CM won’t relay the digits to the ISDN trunk (no e-sig):

Solution

Refer the problem to SIP provider.

A possible workaround:
In CM trunk group settings `Telephone Event Payload Type: 120` on page#4 of the SIP  trunk form defines what payload type CM should offer in SDP when CM sends the INVITE (eg originates a call). However, this value is not acting in this case because the original INVITE message comes from provider's SBC and also comes with type 96 therefore CM is sending the Re-Invite with 96 also and still later on SBC uses type 101.

So the only possible workaround can be to set payload type 101 on both provider's SBC side and CM SIP trunk side.
 


Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy