Sounds like the rtp stream has the sync AND your fs is sending 2833 to your upstream. So the upstream is accepting your 2833 AND doing their own tone detection. Have a look here , http://wiki.freeswitch.org/wiki/RTP_Issues Maybe you can't send 2833 to your upstream ?? Jay On 13/08/2010, at 3:29 AM, Giovanni Maruzzelli <gmaruzz@celliax.org> wrote:

On Thu, Aug 12, 2010 at 7:02 PM, Dennis <odermann@googlemail.com> wrote:

...

hi there,

at the moment we have a serious and urgent problem with transmitting

While you probably will receive a good answer here on the mailing list, if your problem is urgent (and maybe will require exchanges of questions and answers), I would counsel you to join the #freeswitch IRC channel in the irc.freenode.net IRC server, and pose your question again there, so you'll have a quick interaction with the "gurus".

-giovanni

-- Sincerely,

Giovanni Maruzzelli Cell : +39-347-2665618

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Bear in mind that when a carrier says they 'filtered' inband DTMF, they probably mean they have clamped it. There is still DTMF on the line - a few ms, but it is there. Some devices see that clamped DTMF and will use it. For instance, HMP in rfc-2833 mode, will take the rfc-2833 and recreate the DTMF tones - so it always has to be listening for inband even thought it has negociated rfc-2833. In our situation - this resulted in echoed digits - 77227799 - etc just as you are seeing. There only way of diagnosing this IMO, and that is with wireshark (tshark) and listening to the line - that way you know exactly what you are dealing with. Our issue was solved btw, by using inband DTMF exclusively. Not ideal bt any means. On Fri, Aug 13, 2010 at 4:24 AM, Dennis <odermann@googlemail.com> wrote:

thanks for your help!

just as a short info inbetween, while we are still trying to fix the problem.

the cirpack of our carrier always receives dtmf-inputs as inband tones (because, at least in germany, all dtmf-inputs are sent over the landline as inband tones). because we always had problems with the carriers cirpack and fs in conjunction with inband tones (sometimes they where sent two or three times), our carrier added rfc-2833 to their cirpack. now the carrier sends both: rfc-2833 AND inband tones. the problem is, that the carrier tells us, that the cirpack can not filter the inband tones, so that they just can send rfc-2833. but they tell us, that they add some stops (or something like this) to the inband tones, so that the inband tones are not functional anymore. but this does not seem to work correctly.

if we listen to dtmf-inputs only on fs, we do not have any problems, because fs ignores the inband tones and only reacts to the rfc-2833 signal. therefor we never had any problems. now, we have a project, where not fs listens to the dtmf-inputs, but a callcenter on the other side (outbound). therefor the cirpack has to send clean dtmf-inputs to the callcenter. but we believe, that the cirpack on the outgoing side is receiving his own inband tones AND rfc-2833 signals from the incoming side of the cirpack. so the cirpack on the outgoing side send his own inband tones PLUS the converted rfc-2833 signals to the other side (callcenter). we have to go on testing.

we spoke with someone from nokia about their iwsd and they told us, that they filter all inband tones, so that we only receive rfc-2833. we will do some testing with them. but i wonder, why the nokia iwsd can filter inband tones and the cirpack can't.

any ideas?

will keep you informed, what we found out.

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

On Mon, Aug 16, 2010 at 5:56 AM, Dennis <odermann@googlemail.com> wrote:

phillip, it seems that we have somehow the same problem, but we have an additional strange behavior.

we used wireshark on the incoming network-card and on the outgoing side. there we see two strange things, we can not figure out:

1.) on the incoming side, we receive the in-band tone from the cirpack with a tiny gap, but fs recognizes them as 2 tones. in wireshark it look something like this: | |||||||| as i said, fs sees this as two tones.

2.) fs sends the tone above to the outgoing side as two tones, but seems to cut the first ms of the second part. in wireshark it looks something like this: | |||

i feel, that we have to find out the following:

1.) why does the tone already have a gap, when we receive it?

That would probably be better answered by looking at the sending side. I would capture the packets leaving the sending side to see what they look like.

2.) why does fs not leave the tone untouched? something happens with the tone, while passing fs. is there a setting to avoid this?

3.) why is there no easy way to completely delete dtmf tones, if it is possible with vuvuzela-noise? ;-)

I'll defer to those more knowledgeable than I on these other two questions... -MC

Hi Dennis, Regarding change in RTP data.. 1. Which codecs are being used? Do you perform any transcoding in FS? 2. If no transcoding is done, maybe you could enable "proxy-media" for a moment http://wiki.freeswitch.org/wiki/Proxy_Media and check again whether the RTP is changed or not by FS, at this time. Regards, Vitalie

hi all, thanks a lot for your support! the codec we are using is G711a, so normally using inband should work. no transcoding is done. we get G711, fs works with G711 and G711 leaves our servers. although the only short way, we are using voip is a 10 meter long CAT7 wire connected to a cirpack, we would prefer to use rfc-2833 for signaling dtmf inputs. the dtmf detector is off. we spoke to someone from the cirpack-support and he told us, that they do not filter the inband tone, if G711 is used, because we do not need rfc-2833 when using G711. if a lower quality codec is used (like G729), cirpack will filter the inband tone and send rfc-2833 instead. we have the following scenarios: 1.) we set dtmf to "info": cirpack sends us a clean tone and fs sees one clean tone (both: ||||||||||) conclusion: we could drop rfc-2833 and only use inband. 2.) we set dtmf to "rfc-2833": cirpack send us the tone with a tiny gap (2ms) and rfc-2833 (|| |||||||||). the guy from cirpack told us, that this is not a real gap, but only wireshark sees it as a gap. the gap is where cipack adds the requested rfc-2833 information. but, fs hears the inband tone as if it were 2 tones and the rfc-2833. this worked for us before, because we only reacted on the rfc-2833 signal. now we have to send the audio to another side. on the other side the 2 inband (one splitted) tones are heard, which leads to problems. under the following url you can see a screenshot taken from wireshark. the first row is, how cirpack sends the inband and rfc-2833. to last row shows, how fs sees the tone. https://photos-1.dropbox.com/i/o/uy03PGj0ZEtxIi3r7RV9dBkXXvRoxmJ-KlcBi1i9ovg... are there some timing-settings in fs, we could play with to make the tiny gap dissaper or something like that, or should we just switch completely to inband? thanks dennis