We are facing an issue with DTMF when using Survey application (Customer Satisfaction Module). The customer call hits the Genesys SIP server and the main application loaded on Route Point is executed. Its a menu based application and the customer can select the menu options, the DTMF is recognized at this stage. However, after reaching the agent and once the agent disconnects the call. The customer call is diverted to another Route point where Survey Application is loaded using the option after-call-divert-destination at the Route Point level. At this stage, the customer could hear the survey questions and when he press DTMF for answering the questions. The DTMF is not recognized.
Now, this scenario happens when a production call comes through Avaya SBC —> Session Manager —> Avaya CM ----> Genesys. On analyzing the wireshark traces, we can find that the initial INVITE message from SBC had negotiated a telephone-event payload type 116, 97 , 120 etc. And Genesys responds back with 200 OK with the same payload type.
However, internally Genesys sends INVITEs when transferring back to Route Point where survey application is loaded and in that INVITE the telephone-event payload type is changed to 101 for the same call (As far as SBC is concerned). So the subsequent DTMFs send by SBC is DynamicRTP-Type-116 ( or DynamicRTP-Type-97 or DynamicRTP-Type-120 etc) based on the payload type negotiated in the first INVITE.
Kindly please let me know if anyone has faced a similar issue in such an environment where Avaya SBC is used with Genesys.
Thanks for the response. I tried changing the option below from MCP application object but no luck.
[mpc].telephone_eventpayload=116
Even, i tried changing from SIPS application object, option dtmf-payload to 116. (Though this option is used in case of Stream Manager, but in our case it is MCP)
The main concern is we cannot hard code a particular payload type because the it may vary different for different calls coming from the carrier. SBC accepts dynamically whatever it receives from the carrier and even Genesys accepts it. However, when the same call is transferred to another route point for Survey the payload gets changed. So i believe SBC does not understand this change in payload type for the same call.
Maybe, we need to restrict Genesys from changing the payload type for the same call. It should negotiate with the same payload type which came from SBC in the first INVITE. Correct me if i am wrong.
What if you change the option “reuse-sdp-on-reinvite” to “false” on the trunk with the Avaya SM? Maybe this could help getting the SDP offer from the non-Genesys equipments (depends on your callflow, but it is probable that it would help)
the option “dtmf-payload” is set to 101 by default. I tried changing it to 116 and it was still the same. Like i said, we cannot hard code that value to any particular value right? The calls coming from SBC may have different payload type value for different calls. Correct me if wrong.
Remove telephone-event from the codec list to disable RFC 2833 DTMF (out of band). This should then cause DTMF to fallback to inband DTMF (you can hear the tones in RTP captures) to get around problems with dynamic payload types.
If I remember well, if you remove it from the codec list, you have also to enable the option sdp-codec-filter on the teunk dn ( I dont remember the exact name of the option, but it is something like this - confirm on sip server deployment guide)
