Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: ryusuf on May 03, 2016, 11:01:21 AM
-
Hello,
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 [b]after-call-divert-destination[/b] 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.
Appreciate your help as usual.
Thank You
Best Regards
-
Change the payload of used codesc to be same on both sites
-
Hi Kubig,
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.
Thank You
Best Regards
-
On SIP Server, which type of dtmf mode is configured?
Enviado de meu E6633 usando Tapatalk
-
What if you change the option "reuse-sdp-on-reinvite" to "false" on the trunk with the Avaya SM? [b]Maybe[/b] this could help getting the SDP offer from the non-Genesys equipments (depends on your callflow, but it is probable that it would help)
-
[quote author=hsujdik link=topic=9574.msg43212#msg43212 date=1462281664]
What if you change the option "reuse-sdp-on-reinvite" to "false" on the trunk with the Avaya SM? [b]Maybe[/b] this could help getting the SDP offer from the non-Genesys equipments (depends on your callflow, but it is probable that it would help)
[/quote]
It did not help. It is still not recognizing the DTMF.
[quote author=cavagnaro link=topic=9574.msg43211#msg43211 date=1462280583]
On SIP Server, which type of dtmf mode is configured?
Enviado de meu E6633 usando Tapatalk
[/quote]
Can you please tell me where can i check that?
Thank You
Best Regards
-
Check the option "dtmf-payload" under "TServer" section on SIP server application object
-
[quote author=Kubig link=topic=9574.msg43215#msg43215 date=1462353544]
Check the option "dtmf-payload" under "TServer" section on SIP server application object
[/quote]
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.
-
Yes, because this option is obsolete and SM related according to the documentation. I think you have three choices:
[list]
[li]Change the payload on SBC[/li]
[li]Set the SIP server to disable SDP renegotiation[/li]
[li]Try to reconfigure the option "audio-codec" on SIP server. This option, according to the documentation, should offer to change the PT or clock[/li]
[/list]
-
[quote author=Kubig link=topic=9574.msg43217#msg43217 date=1462363664]
Yes, because this option is obsolete and SM related according to the documentation. I think you have three choices:
[list]
[li]Change the payload on SBC[/li][/list]
[b]As per the Avaya SBC engineer, this is not possible. Whatever the carrier sends, Avaya SBC sends it to the SM and then to Genesys. But i heard Sangoma SBC is intelligent enough to change the payload type compared to Avaya SBC.[/b]
[list][li]Set the SIP server to disable SDP renegotiation[/li][/list]
[b]the option "sip-enable-sdp-codec-filter" is already set to "false". So i believe SIPS will not modify the SDP message during renegotiation.
[/b]
[list][li]Try to reconfigure the option "audio-codec" on SIP server. This option, according to the documentation, should offer to change the PT or clock[/li][/list]
[b]
This option has the follwoing values "telephone-event,PCMU,PCMA,G723,G729,GSM". the telephone-event is the one which is used for DTMF. And also the description of this option mentions that, it is used when Stream Manager 7.0.2 (or earlier) uses to play treatments. In our case MCP is the one who plays the treatments.[/b]
[/list]
[/quote]
-
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.
Regards
Craig
-
[quote author=genesysguru link=topic=9574.msg43219#msg43219 date=1462368570]
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.
Regards
Craig
[/quote]
I tried that too. Still no luck.
Checked the wireshark traces and found that the first INVITE is negotiating "telephone-event" itself even after removing it from the codec lists.
Thank you
Best Regads
-
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)
-
Hi Henrique,
It did WORK now ! ! ! :) :) :)
So what i did was the following.
1) Removed [b]telephone-event[/b] codec from SIPS option [b]audio-codecs[/b]
2) Set the option [b]sip-enable-sdp-codec-filter[/b] value to [b]True[/b] in the Trunk DN.
3) The option [b]sip-enable-sdp-codec-filter[/b] value in the SIPS application object is set to [b]False[/b].
4) Removed the [b]telephone-event[/b] codec from the MCP option [b]codec[/b] under the [b]mpc[/b] section.
Tested few calls and it was successful. The DTMF was detected in both the main application and the Survey application.
Also appreciate the support of Craig and Kubig. It was helpful :) :) :)
Thank You
Best Regards