[Freeswitch-users] Sonus possibly stomping all over DTMFs that *it* sends out...

[Mahesh Paolini-Subramanya]

This doesnt directly apply to Freeswitch, but I just wanted to know if anybody else has noticed anything along these lines.
The specific problem applies to the path below, for rfc2833 DTMFs
	Cell Phone --------> Sonus SIP Provider --------> Freeswitch   
In particular, if the user on the Cellphone hammers home a bunch-a DTMFs really really rapidly, only a few of them get to Freeswitch.
I *think* I know where the problem lies (hint:  S***s).

Lets see, where do I begin.  
Sonus does DTMF handling *differently* from normal people.  e.g., anybody who cares should know about  http://www.submityoursip.com/wiki/Sonus_NBS), 
In addition to that, Sonus seems to have set their Minimum DTMF Duration to 320ms.  Which would be fine and dandy, except that due to the miracle of How Sonus Works, it just stomps all over data when it extends the duration of the DTMF.

e.g., Consider the situation where the Cell Phone user hammers home a couple of DTMFs (987) really really rapidly.  Just for arguments sake, consider that each DTMF that was entered was around 130ms in length, and had, oh, 50ms between them.
Here is what  *should* be sent from Sonus to FS
	Time: 0 -->  DTMF 9
	Time: 130 --> DTMF 9 ends
	Time: 180 --> DTMF 8
	Time: 310 --> DTMF 8 ends
	Time: 360 --> DTMF 7
	Time: 490 --> DTMF 7 ends

i.e., FS should actually receive 987

However, here is what actually happens when Sonus decides to do *its* version of Minimum DTMF Duration.
	Time: 0 -->  DTMF 9
	Time:320 --> DTMF 9 ends
		*******  There is no DTMF 8 here. Ever, given the above durations.  *******
	Time:  360 --> DTMF 7
	Time: 490 --> DTMF 7 ends
i.e., FS actually receives 97

To recap, what Sonus seems to do is t
	1) Look at the incoming DTMF stream
	2) If the DTMF is greater than Minimum DTMF Duration, leave it alone
	3) If the DTMF is less than Minimum DTMF duration, then create additional RTP EVENT packets to make up the difference, and (this is the goofy part) replace the packets in the original stream with the ones it created.

For outbound DTMF through Sonus, this is rarely a problem since most people leave their min_dtmf_duration as the default (400ms). If, however, you reduce min_dtmf_duration to, say, 150ms, you *will* have issues on outbound DTMF!
That said, for SIP calls *from* Sonus *to* Freeswitch, you have no such guarantees on the originator of the DTMFs - especially if that is the PSTN.

There is probably no real solution to this, apart from either dumping your Sonus based provider for someone else, or getting them to change their configuration (yeah, likely)

So, back to the original question - anyone else noticed this?



Mahesh Paolini-Subramanya | CTO | mahesh at aptela.com | 703.386.1500 Ext. 9100
2250 Corporate Park Drive | Suite 150 | Herndon, VA | www.aptela.com
Check out our Blog | Follow us on Twitter | Refer a Friend 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 1296 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100925/918df31c/attachment-0001.jpg 
-------------- next part --------------