<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello<br></blockquote><div><br></div><div>my mistake... I had written data="RTP_BUG_IGNORE_MARK_BIT" instead of value="RTP_BUG_IGNORE_MARK_BIT". It's working now. Keep this in mind if you ever happen to put a Huawei SBC in from of a FS!</div>
<div><br></div><div>Thanks</div><div><br></div><div>Javier</div><meta charset="utf-8"><meta charset="utf-8"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>---------- Forwarded message ----------<br>
From: Javier Gallart <<a href="mailto:jgallartm@gmail.com">jgallartm@gmail.com</a>><br>To: <a href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a><br>Date: Wed, 16 Feb 2011 13:28:35 +0100<br>
Subject: Re: [Freeswitch-users] g729 packets skipped in passthrough mode<br>Hello,<div><br></div><div>I've looked deeper into this issue and I might have hit a known problem:</div><div><br></div><div><div>RTP_BUG_IGNORE_MARK_BIT = (1 << 2)</div>
<div><br></div><div><span style="white-space:pre-wrap"> </span>/*</div>
<div><span style="white-space:pre-wrap"> </span> A Huawei SBC has been discovered that sends the mark bit on every single RTP packet.</div><div><span style="white-space:pre-wrap"> </span> Since this causes the RTP stack to flush it's buffers, it horribly messes up the timing on the channel.</div>
<div><br></div><div><span style="white-space:pre-wrap"> </span> This flag will do nothing when an inbound packet contains the mark bit.</div><div><br></div><div><span style="white-space:pre-wrap"> </span> */</div>
</div><div><br></div><div>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 </div><div><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?</div>
<div><br></div><div>Thanks</div><div><br></div><div>Javier<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>---------- Forwarded message ----------<br>
From: Anthony Minessale <<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>><br>To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>
Date: Tue, 15 Feb 2011 16:38:35 -0600<br>Subject: Re: [Freeswitch-users] FreeSWITCH-users Digest, Vol 56, Issue 177<br>Well that's all I could think of:<br>
<br>
passthrough is passthrough FS never modifies anything.<br>
you need to look harder at sip trace, pcaps or other diagnostics for<br>
some misconfiguration.<br>
many people use this daily.<br>
<br>
<br>
On Tue, Feb 15, 2011 at 1:12 AM, Javier Gallart <<a href="mailto:jgallartm@gmail.com" target="_blank">jgallartm@gmail.com</a>> wrote:<br>
><br>
> Anthony, thanks for the tip. I haven't seen any change though. I should have<br>
> mentioned that I'm focusing in the rtp stream coming form the callee to the<br>
> caller. The problem is that FS relays to the caller only half of the packets<br>
> received from the callee. The packets arrive at FS at a rate of 1 packet<br>
> every 20 ms, and with a payload of 20 bytes each. Packets from FS to the<br>
> caller are sent every 40 ms with a payload of 20 bytes, thus skipping half<br>
> of the information.<br>
><br>
> Thanks<br>
>><br>
>> ---------- Forwarded message ----------<br>
>> From: Anthony Minessale <<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>><br>
>> To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>
>> Date: Mon, 14 Feb 2011 10:38:57 -0600<br>
>> Subject: Re: [Freeswitch-users] g729 packets skipped in passthrough mode<br>
>> I bet its 20ms vs 30<br>
>> set passthru_ptime_mismatch to true either in vars.xml or in your<br>
>> dialplan both legs through export on the a leg or set in the a leg and<br>
>> in the {} on b.<br>
>><br>
>><br>
>> On Mon, Feb 14, 2011 at 10:28 AM, Brian West <<a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</a>> wrote:<br>
>> > What exactly is the problem? I see no issue here can you elaborate on<br>
>> > what you're seeing?<br>
>> ><br>
>> > /b<br>
>> ><br>
>> > On Feb 14, 2011, at 4:48 AM, Javier Gallart wrote:<br>
>> ><br>
>> >> I've tried to explicitly set ptime at 20ms at switch.conf -although<br>
>> >> it's not necessary afaik-. Has any one experienced this same issue?<br>
>> >><br>
>> >> Thanks in advance..<br>
>> >><br>
>> >> Regards<br>
>> ><br>
>> ><br><br></blockquote></div></div>
<br><br></blockquote></div>