On Fri, Feb 08, 2008 at 01:38:09AM -0600, Ken Rice wrote: > I noticed in a recent commit there has been some issues w/ the DTMF on > TFGW..
DTMF in general rather than just TFGW :-). > I should point out (as the guy that runs TFGW) that FreeSwitch is not whats > actually interpreting the DTMF... Its either a MetaSwitch or a CopperCom > CSX... This being said, the fixed length DTMF the asterisk, and callweaver > are stricken with can cause some serious issues for these platform as well > as things like Sonus and others... > > The problem comes in that you are supposed to send a packet with the correct > ptime that you negotiated in the SDP... So with asterisk its 20ms... So for > 100ms DTMF you should have start, mid, mid, mid, end, end, end (you don¹t > have to agree w/ my interpretation of 2833 DTMF, I don¹t think the guys who > wrote it all agree on how the RFC should be interpreted) > > Unless its been changed since the original fork (and quite honestly I havent > paid that much attention) the issue comes in when on a jittery link packets > get out of order and this is easy to do with anything prior ot variable > length DTMF in asterisk 1.4 because the codebase prior to that did not space > the DTMF out correctly > It would blast the entire 100ms burst out at one time... If we are still > seeing that behaviour It will cause issues with all of the above listed > hardware if there is any thing that can cause out of order packet arrival at > the media gateway... (I¹ve seen double and tripple DTMF a few times) It's changed. CW now clocks out the 2833 event packets correctly. It used to use incrementing duration on the start and mid packets (i.e. 20ms, 40ms, 60ms, 80ms, 100ms, 100ms, 100ms) which seems to be what the RFC intended. However, like you say, it suffers badly if jitter is present. I don't get RTCP from TFGW but if I load my local connection up other peers tell me it goes to 80-100ms and over. That's enough for a peer to either see the whole lot in a single burst or to see a gap in the middle longer than the std min gap between DTMF events. If the peer isn't paying attention to start/duration and doing _massive_ de-jittering at the RTP level it's no surprise that DTMF gets dropped or doubled. The last change I did was to set the duration to the full 100ms on every packet (since CW uses a fixed length DTMF). The theory being that if the peer is looking at duration at all this will help it avoid timing out in the middle of an event because a packet was late. If the peer also pays attention to start it should avoid it doubling the DTMF when the rest of the packets finally arrive. It _seems_ to work for TFGW but not for voipmich (which claims to be Asterisk in its SIP/SDP). I can't think of anything else we can do on the sending side. Other than recommend SIP INFO :-) Mike -- Mike Jagdis Web: http://www.eris-associates.co.uk Eris Associates Limited Tel: +44 7780 608 368 Reading, England Fax: +44 118 926 6974 _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
