Hello, I've looked deeper into this issue and I might have hit a known problem: RTP_BUG_IGNORE_MARK_BIT = (1 << 2) /* A Huawei SBC has been discovered that sends the mark bit on every single RTP packet. Since this causes the RTP stack to flush it's buffers, it horribly messes up the timing on the channel. This flag will do nothing when an inbound packet contains the mark bit. */ The carrier is actually a Huawei SBC, and the problem I reported only happens when it sends the marker bit = true in all the rtp packets. I've tried <param name="auto-rtp-bugs" data="RTP_BUG_IGNORE_MARK_BIT"/> in the profile but the problem is still there, is this the right way to override this nonsense from the Huawei? Thanks Javier

---------- Forwarded message ---------- From: Anthony Minessale <anthony.minessale@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Date: Tue, 15 Feb 2011 16:38:35 -0600 Subject: Re: [Freeswitch-users] FreeSWITCH-users Digest, Vol 56, Issue 177 Well that's all I could think of:

passthrough is passthrough FS never modifies anything. you need to look harder at sip trace, pcaps or other diagnostics for some misconfiguration. many people use this daily.

On Tue, Feb 15, 2011 at 1:12 AM, Javier Gallart <jgallartm@gmail.com> wrote:

...

Anthony, thanks for the tip. I haven't seen any change though. I should

have

...

mentioned that I'm focusing in the rtp stream coming form the callee to the caller. The problem is that FS relays to the caller only half of the packets received from the callee. The packets arrive at FS at a rate of 1 packet every 20 ms, and with a payload of 20 bytes each. Packets from FS to the caller are sent every 40 ms with a payload of 20 bytes, thus skipping half of the information.

Thanks

...

---------- Forwarded message ---------- From: Anthony Minessale <anthony.minessale@gmail.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Date: Mon, 14 Feb 2011 10:38:57 -0600 Subject: Re: [Freeswitch-users] g729 packets skipped in passthrough mode I bet its 20ms vs 30 set passthru_ptime_mismatch to true either in vars.xml or in your dialplan both legs through export on the a leg or set in the a leg and in the {} on b.

On Mon, Feb 14, 2011 at 10:28 AM, Brian West <brian@freeswitch.org>

wrote:

...

...

What exactly is the problem? I see no issue here can you elaborate on what you're seeing?

/b

On Feb 14, 2011, at 4:48 AM, Javier Gallart wrote:

...

I've tried to explicitly set ptime at 20ms at switch.conf -although it's not necessary afaik-. Has any one experienced this same issue?

Thanks in advance..

Regards