Summary: | ASTERISK-08685: DTMF modes are bot getting translated in P2P bridging mode | ||
Reporter: | mdu113 (mdu113) | Labels: | |
Date Opened: | 2007-01-29 14:43:54.000-0600 | Date Closed: | 2007-01-30 13:37:20.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 2833-to-inband.txt ( 1) 2833-to-inband-8936patch.txt ( 2) 8936.patch ( 3) chan_sip.c.diff ( 4) inband-to-2833.txt ( 5) inband-to-2833-8936patch.txt | |
Description: | If 2 call-legs have different DTMF modes and P2P bridging (and probably native) is used then DTMFs are not getting translated and as such are not recognized by the peer. File 2833-to-inband.txt show debugging output for calls when originating peer has dtmfmode set to rfc2833 and terminating peer has dtmfmode set to inband. DTMF digits are recognized by terminating peer. Relevant part of sip.conf: [general] disallow=all ; First disallow all codecs allow=ulaw ; Allow codecs in order of preference [pbx2] type=friend username=pbxtest permit=66.114.83.0/255.255.255.192 deny=0.0.0.0/0.0.0.0 host=66.114.83.12 context=pbxes sendrpid=yes dtmfmode=inband nat=yes [xyz011101] type=friend username=xyz011101 md5secret=7c7bad2e3d3bb30bbfb413ec14755db2 context=xyz host=dynamic dtmfmode=rfc2833 callerid=111 mailbox=111@xyz mohsuggest=xyz File inband-to-2833.txt show debugging output for call when originating peer has dtmfmode set to inband and terminating peer has dtmfmode set to rfc2833. DTMF digits are recognized by terminating peer. Relevant part of sip.conf: [general] disallow=all ; First disallow all codecs allow=ulaw ; Allow codecs in order of preference [pbx2] type=friend username=pbxtest permit=66.114.83.0/255.255.255.192 deny=0.0.0.0/0.0.0.0 host=66.114.83.12 context=pbxes sendrpid=yes rfc2833compensate=yes dtmfmode=rfc2833 nat=yes [xyz011101] ;ext_id=1599, station_id=394, Polycom IP500 type=friend username=xyz011101 md5secret=7c7bad2e3d3bb30bbfb413ec14755db2 context=xyz host=dynamic dtmfmode=inband callerid=111 mailbox=111@xyz mohsuggest=xyz The only way I could get DTMF recognized by the peer is to make dtmfmode equal on both endpoints. It's not an option on my production system and I believe pbx should translate digits anyway. The other way I could get it work is to completely disable native bridging (by making codecs incompatible). If generic bridging is used then everything works fine. | ||
Comments: | By: Russell Bryant (russell) 2007-01-29 15:27:49.000-0600 This should be fixed in the 1.4 branch and trunk in revisions 52645 and 52646. Thanks! By: mdu113 (mdu113) 2007-01-29 17:27:00.000-0600 It still doesn't work and debug output looks identical to what I posted. I spend some time reading the code and if my limited understanding is correct then I guess the problem is the following line in chan_sip.c: ast_rtp_setdtmf(dialog->rtp, ast_test_flag(&dialog->flags[0], SIP_DTMF) != SIP_DTMF_INFO); To correspond to the following table from rtp.c: * -------------------------------------------------- * | DTMF Mode | HAS_DTMF | Accepts Begin Frames | * |-----------|------------|-----------------------| * | Inband | False | True | * | RFC2833 | True | True | * | SIP INFO | False | False | * -------------------------------------------------- it has to be changed to ast_rtp_setdtmf(dialog->rtp, ast_test_flag(&dialog->flags[0], SIP_DTMF) == SIP_DTMF_RFC2833); I've attached the patch. With this patch P2P bridging is not enabled if DTMF modes don't match and as far as I can tell it works correctly. On a separate note, is it a good idea to completely disable native bridging in this case? Isn't it better to make sure that core always monitor channels for DTMF if their modes don't match? By: Russell Bryant (russell) 2007-01-29 18:27:25.000-0600 Originally, I had thought that implementing this such that DTMF always went through the core with P2P bridging when the modes didn't match wouldn't work. But, now that I look again, I think it's a simple change. Would you mind trying my attached patch? By: mdu113 (mdu113) 2007-01-30 12:27:53.000-0600 Still no good. I uploaded 2 more files with debugging output from asterisk with your patch applied. When translation is supposed to be from rfc2833 to inband then digits are recognized by the core (according to the log), but still are not recognized by the peer. My guess is core still doesn't replay them in outbound stream. When translation is supposed to be from inband to rfc2833 then digits are not recognized by the core and debug looks identical to me. Again looking in the code I don't see how it's supposed to recognize the inband digits. The following line in rtp.c:bridge_p2p_rtp_write(): /* If the payload is DTMF, and we are listening for DTMF - then feed it into the core */ if (ast_test_flag(rtp, FLAG_P2P_NEED_DTMF) && !rtpPT.isAstFormat && rtpPT.code == AST_RTP_DTMF) return -1; suggests that it will work for rfc2833 digits only. To recognize inband DTMF I think it should be something like the following written in human language: if (dtmfmode is inband and we watch for dtmf and rtp frame type is voice ) return -1; This probably also means that whatever is configured in features.conf won't work with inband dtmf in P2P-bridged calls. What do you think? By: Russell Bryant (russell) 2007-01-30 13:32:20.000-0600 Your analysis is correct. While bridged in P2P mode, there is no DTMF detector used on the incoming audio. In fact, doing so is more than I'm willing to do to solve this bug in the release branch. However, it would certainly be a nice feature to have in the trunk. But, that's really a separate issue. Thanks for all of the thorough logs and analysis of the problems! By: Russell Bryant (russell) 2007-01-30 13:37:20.000-0600 I have fixed the errors in chan_sip for setting the HAS_DTMF flag on the rtp structure in 1.4 and the trunk in revisions 52952 and 52953. Thanks! |