<div dir="ltr">are you doing anything with bypass_media?<br>We had another guy with something similar and we have not been able to nail it down besides<br>he was doing a media call that shifted to bypass_media mode.<br><br>
If you have a situation where it happens every time a pcap and or FS console on debug of it happening would be nice.<br>It seems odd that the auto adjust code is being triggered considering the design says that if the leg from FS1 -&gt; C gets a packet<br>
from some other ip than that of C that it adjusts to that.&nbsp; So it would appear that somehow one of the packets from FS2 to FS1<br>ends up being picked up by the rtp socket that was meant for the FS1-&gt;C leg.&nbsp; (maybe a race in the port allocator giving both legs the same rtp port or something funny?)&nbsp; <br>
<br>say your phone is A<br><br>A -&gt; FS1 (recv port 1000)<br>FS1-&gt;FS2 (recv port 1002)<br>FS2-&gt;C (recv port 1004)<br><br>either port 1004 is somehow getting the packet meant for 1002 which would make no sense<br>or somewhere in here both boxes picked the same port or the packet is somehow multicasting to both ports which would make no sense either.<br>
<br>I would like to figure it out though if you could provide the details including the dp and all the attrs you set etc.<br><br><br>BTW, you can turn off RTP auto ADJ both with a channel varable and a profile param (i forgot the name but it&#39;s on the wiki)<br>
<br><br><br><br><br><br><br><br><br><div class="gmail_quote">On Mon, Oct 6, 2008 at 9:25 PM, David Knell <span dir="ltr">&lt;<a href="mailto:dave@3c.co.uk">dave@3c.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Going back a step, to where Jon was seeing more packets than there<div>should have been, I&#39;ve just encountered a similar issue having upgraded</div><div>to the latest, from what was probably a fairly old release - months old,</div>
<div>rather than weeks.</div><div><br></div><div>I&#39;ve got two FS boxes (let&#39;s call them FS1 and FS2), each of which are</div><div>plumbed in to carrier C. &nbsp;There&#39;s an IVR service running on FS1; FS2</div><div>
bridges any calls which it gets for said IVR over to FS1. &nbsp;What I&#39;ve just had</div><div>is:</div><div>- calls from C to FS1 directly work fine;</div><div>- calls from C to FS2, thence to FS1 were silent. &nbsp;Looking at a capture from</div>
<div>FS2, everything looks OK except the RTP between FS1 and FS2. &nbsp;On answer,</div><div>there&#39;s a prompt played. &nbsp;What I see is three packets in a lump from FS1, then</div><div>four packets sent back from FS2 to FS1, four packets in a lump from FS1, then</div>
<div>five going back from FS2 to FS1, and so on.</div><div><br></div><div>The lumps are 20ms apart (codec is G711 with 20ms packets) - what seems to be</div><div>happening is that FS2 sends FS1 back the packets received from it unchanged</div>
<div>plus an extra packet which has arrived from C in the meantime.</div><div><br></div><div>FS2 ought to be sending these packets to C instead; it sends C nothing.</div><div><br></div><div>I&#39;ve made the problem go away by commenting out the bit in switch_rtp.c which</div>
<div>auto-adjusts addresses (around line 1280.)</div><div><br></div><div>All of the machines have public IPs; there&#39;s not a NAT in sight.</div><div><br></div><div>I&#39;ll have a further look in the morning.</div><div>
<br></div><div>--Dave</div><div><br></div><div><div><br><blockquote type="cite"><div dir="ltr">%(60000,0,300) means to generate a 60 second long 300hz tone <br>%(5,0,300) means a 5 ms long 300hz tone<br><br>if you are just trying to send a tone you are better off with<br>
&lt;action application=&quot;gentones&quot; data=&quot;%(1000,0,300)|60&quot;/&gt;<br> <br>which only generates 1 second of audio then buffers and loops it via the application<br>rather than allocating enough room for 60 seconds of signed linear audio and generating<br>
the whole 60 seconds into memory for no reason vs 1 second sample looped 60 times.<br> <br>No matter what you do it will not effect the bandwidth used, it&#39;s a factor of what codec you are using.<br><br><br><div class="gmail_quote">
On Mon, Oct 6, 2008 at 4:15 AM, Jon Bruel <span dir="ltr">&lt;<a href="mailto:jbr@consiglia.dk" target="_blank">jbr@consiglia.dk</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Resolved: I have made further tests, and my final conclusion is that the<br> previous stated test results were screwed by the application &#39;gentones&#39;.<br> This application does in some cases send more rtp than expected. If I<br>
 used:<br> &lt;action application=&quot;gentones&quot; data=&quot;%(5,0,300)&quot;/&gt;<br> &lt;action application=&quot;gentones&quot; data=&quot;%(5,0,300)&quot;/&gt;<br> &lt;action application=&quot;gentones&quot; data=&quot;%(60000,0,300)&quot;/&gt;<br>
 the expected rtp of 8600 kB/s was transmitted. If I used<br> &lt;action application=&quot;gentones&quot; data=&quot;%(60000,0,300)&quot;/&gt;<br> &lt;action application=&quot;gentones&quot; data=&quot;%(5,0,300)&quot;/&gt;<br>
 &lt;action application=&quot;gentones&quot; data=&quot;%(5,0,300)&quot;/&gt;.<br> the rtp was 34600 kB/s, and the memory is heavily consumed. The only<br> difference being the sequence of the gentones commands. I don&#39;t know if<br>
 this is the expected behaviour of &#39;gentones&#39; or not, but it certainly<br> screwed up the results previously posted. /Jon<br> <div><div></div><div><br> <br> _______________________________________________<br> Freeswitch-users mailing list<br>
 <a href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a><br> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
 UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
 </div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
 <br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
 IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br> <a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br> </div> _______________________________________________<br>Freeswitch-users mailing list<br><a href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div></div><br>_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>
</div>