Re: [asterisk-users] DTMF not being heard correctly by far end conference system
Hi Duncan, On Wed, Jan 12, 2011 at 10:13 AM, Duncan Turnbull dun...@e-simple.co.nz wrote: Hi Thorsten Thanks very much, at this point my preference is rfc2833 but I will try some other options. The system is generating audible tones (that I can hear), although I think the audio is generated by the last sip device in the network so if thats so I don't have any control of it. Probably then I have to go to inband to get some control back, I am not sure what I lose from this, or change upstream provider (although the current provider works from a different system) In my DTMF experience I have found a few IVRs and conference systems out there that won't accept my DTMF, even though its DTMF that I can see going out over PRI channels. My guess is that these systems use too tight of a duration window on their DTMF detectors. In your case I'm guessing that for some reason the SIP DTMF tones are coming out with too short of a duration. I believe you can fiddle with the dtmf tone duration and spacing in channel.c but I don't know if that will fix the issue. Is it possible to get the DTMF specs from the manufacturer of the conference system? -- James -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] DTMF not being heard correctly by far end conference system
Hi there I have two different asterisk systems (both 1.4) whose dtmf tones are not being picked up by a particular conference system users are dialling into. I can call myself with the phones and hear the tones, but I am guessing perhaps they are too short or somehow different. I have looked and looked but can't nail down the reason. I don't believe this is a general issue, rather some specific conference systems that they need. I am sure I saw this covered a few years ago but can't find it in the lists. The phones and the system are using rfc2833 and either alaw or ulaw, I have stayed away from in band dtmf, but may need to consider it. They also use *1 to turn on call recording and I am not sure how that will go with inband. Another 1.6 system has no problem with being detected and it uses SIP trunks from the same supplier as the customer. The first system is a 1.4.38 box, it has sip trunks as the primary outbound route, the secondary route is iax to another box then via analogue lines. Almost all the handsets are sip and a re a mix of polycom and yealink. The sip trunks routed out through the iax link via analogue lines seem to work okay too. I am wondering if the iax handling of dtmf matches whatever the far end is expecting a little better For now I have routed everything via the iax / analogue lines which may cause some problems in terms of line availability but gets past the issue. I am considering upgrading the box to 1.6 as the working one is 1.6 The other box is a digium AA50 appliance so I can't do much with it, other than find the right settings. I have on the first one relaxdtmf=yes - relates to old issues too as far as I can tell rfc2833compensate=yes - this only appears to matter for inbound I'm not sure these do anything useful From what I can tell it could be the toneduration, but don't know what it should be, and while technically its probably the IVR being fussy that doesn't help me and I want to see why one system works and one doesn't This is dtmf debug from an iax handset sending digit 4 [Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-0639 to write format slin [Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 160 sample intervals [Jan 12 23:13:55] DEBUG[8717]: channel.c:5297 ast_channel_start_silence_generator: Started silence generator on 'SIP/xtreme-0639' [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2796 ast_rtp_raw_write: Difference is 1736, ms is 237 [Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 0 sample intervals [Jan 12 23:13:55] DEBUG[8717]: channel.c:5310 ast_channel_stop_silence_generator: Stopped silence generator on 'SIP/xtreme-0639' [Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-0639 to write format alaw [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 1713844722 to 565606422 due to a source change [Jan 12 23:13:55] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF begin on channel (IAX2/419-13088) [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update [Jan 12 23:13:55] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-0639 [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 565606422 to 226872656 due to a source change [Jan 12 23:13:56] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF end on channel (IAX2/419-13088) [Jan 12 23:13:56] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update [Jan 12 23:13:56] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-0639 [Jan 12 23:13:56] DEBUG[8717]: res_features.c:1399 feature_interpret: Feature interpret: chan=IAX2/419-13088, peer=SIP/xtreme-0639, code=4, sense=1 I will get a sip dump but am remote for now and don't have sip access All pointers and knowledge appreciated Cheers Duncan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DTMF not being heard correctly by far end conference system
Am 12.01.2011 11:37, schrieb Duncan Turnbull: Hi there I have two different asterisk systems (both 1.4) whose dtmf tones are not being picked up by a particular conference system users are dialling into. I can call myself with the phones and hear the tones, but I am guessing perhaps they are too short or somehow different. I have looked and looked but can't nail down the reason. I don't believe this is a general issue, rather some specific conference systems that they need. I am sure I saw this covered a few years ago but can't find it in the lists. The phones and the system are using rfc2833 and either alaw or ulaw, I have stayed away from in band dtmf, but may need to consider it. They also use *1 to turn on call recording and I am not sure how that will go with inband. Another 1.6 system has no problem with being detected and it uses SIP trunks from the same supplier as the customer. The first system is a 1.4.38 box, it has sip trunks as the primary outbound route, the secondary route is iax to another box then via analogue lines. Almost all the handsets are sip and a re a mix of polycom and yealink. The sip trunks routed out through the iax link via analogue lines seem to work okay too. I am wondering if the iax handling of dtmf matches whatever the far end is expecting a little better For now I have routed everything via the iax / analogue lines which may cause some problems in terms of line availability but gets past the issue. I am considering upgrading the box to 1.6 as the working one is 1.6 The other box is a digium AA50 appliance so I can't do much with it, other than find the right settings. I have on the first one relaxdtmf=yes - relates to old issues too as far as I can tell rfc2833compensate=yes - this only appears to matter for inbound I'm not sure these do anything useful From what I can tell it could be the toneduration, but don't know what it should be, and while technically its probably the IVR being fussy that doesn't help me and I want to see why one system works and one doesn't This is dtmf debug from an iax handset sending digit 4 [Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-0639 to write format slin [Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 160 sample intervals [Jan 12 23:13:55] DEBUG[8717]: channel.c:5297 ast_channel_start_silence_generator: Started silence generator on 'SIP/xtreme-0639' [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2796 ast_rtp_raw_write: Difference is 1736, ms is 237 [Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 0 sample intervals [Jan 12 23:13:55] DEBUG[8717]: channel.c:5310 ast_channel_stop_silence_generator: Stopped silence generator on 'SIP/xtreme-0639' [Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-0639 to write format alaw [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 1713844722 to 565606422 due to a source change [Jan 12 23:13:55] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF begin on channel (IAX2/419-13088) [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update [Jan 12 23:13:55] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-0639 [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 565606422 to 226872656 due to a source change [Jan 12 23:13:56] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF end on channel (IAX2/419-13088) [Jan 12 23:13:56] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update [Jan 12 23:13:56] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-0639 [Jan 12 23:13:56] DEBUG[8717]: res_features.c:1399 feature_interpret: Feature interpret: chan=IAX2/419-13088, peer=SIP/xtreme-0639, code=4, sense=1 I will get a sip dump but am remote for now and don't have sip access All pointers and knowledge appreciated Cheers Duncan As far as I can remember you should take a look at the used codec and this here: http://www.voip-info.org/wiki/view/Asterisk+sip+dtmfmode Some codecs do not feel happy with some seetings for dtmfmode. Perhaps you may comapre these on your 2 boxes. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DTMF not being heard correctly by far end conference system
Hi Thorsten Thanks very much, at this point my preference is rfc2833 but I will try some other options. The system is generating audible tones (that I can hear), although I think the audio is generated by the last sip device in the network so if thats so I don't have any control of it. Probably then I have to go to inband to get some control back, I am not sure what I lose from this, or change upstream provider (although the current provider works from a different system) Cheers Duncan On 12/01/2011, at 11:42 PM, Thorsten Göllner wrote: As far as I can remember you should take a look at the used codec and this here: http://www.voip-info.org/wiki/view/Asterisk+sip+dtmfmode Some codecs do not feel happy with some seetings for dtmfmode. Perhaps you may comapre these on your 2 boxes. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
