In regards to the UDP fragmentation, this is an extremely good question.<div><br></div><div>Only yesterday I started to build a simple forwarding SBC in Python using UDP sockets, however I came up against the same theoretical problem of packets being larger than 1500 bytes.</div>
<div><br></div><div>I've had a read through various documentation;</div><div><a href="http://www.rfc-ref.org/RFC-TEXTS/3261/chapter18.html">http://www.rfc-ref.org/RFC-TEXTS/3261/chapter18.html</a></div><div><a href="http://www.ietf.org/rfc/rfc3428.txt">http://www.ietf.org/rfc/rfc3428.txt</a></div>
<div><a href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-August/013857.html">https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-August/013857.html</a></div><div><a href="http://lists.freeswitch.org/pipermail/freeswitch-users/2011-February/068372.html">http://lists.freeswitch.org/pipermail/freeswitch-users/2011-February/068372.html</a></div>
<div><a href="http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05912.html">http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05912.html</a></div><div><br></div><div>Anthony has stated the following;</div>
<i>"the only reliable answer is use TCP."</i><div><br></div><div>There was also the option of enabling compact headers;</div><div><a href="http://lists.freeswitch.org/pipermail/freeswitch-users/2011-December/078633.html">http://lists.freeswitch.org/pipermail/freeswitch-users/2011-December/078633.html</a></div>
<div><br></div><div>From what I can tell, there is no way to guarantee this problem won't happen unless you use TCP. You could reduce the packet size by compacting headers or removing codecs, but this would be on the assumption that every hop is running at 1500 MTU. </div>
<div><br></div><div>Hope this helps!</div><div><br></div><div>Cal</div><div><br><div><div class="gmail_quote">On Sat, Apr 6, 2013 at 2:28 PM, Ira Tessler <span dir="ltr"><<a href="mailto:ira@connectmevoice.com" target="_blank">ira@connectmevoice.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I just need a little guidance with the way presence works. Forgive me if I am asking novice questions.</div>
<div><br></div><div>Background (simple version)</div><div>We run Freeswitch in a hosted/cloud environment in a data center. We have IP phones in our office on our LAN.</div>
<div><br></div><div>That way I am understanding how Presence works, I am just learning this, is that when a BLF button is programmed on a phone, that phone will send a "Subscribe" message to Freeswitch. The subscriptions are stored in the sip_subscriptions table (i think) in the sofia database for the sip profile. When calls come in for that subscription, Freeswitch will send out a NOTIFY message to the phone that subscribed in order to change the state of the BLF Light.</div>
<div><br></div><div>He is my questions/issue/confusion.</div><div>All our phones use UDP which has a maximum packet size of 1500 bytes. When doing a sofia global siptrace on, I notice that most of the NOTIFY messages are greater then 1500 bytes. That will cause packet fragmentation. So if the NOTIFY message is fragmented, will it get to the phone correctly? (all the time, some of the time, never??)</div>
<div><br></div><div>If the the answer is other then ("all the time"), how do I fix this? The only solution I can come up with is having my phones use TCP instead of UDP. Is that the correctly solution? Did anyone else out there run into this issue and if so, what is the "best practice" solution (if there is one)?</div>
<div><br></div><div>Thank you in advance!</div><span class="HOEnZb"><font color="#888888"><br clear="all"><div>Ira Tessler<br>Lead Software Engineer<br>ConnectMe<br><a href="tel:%28732%29%20490-9007%20x2" value="+17324909007" target="_blank">(732) 490-9007 x2</a><br>
<a href="mailto:ira@connectmevoice.com" target="_blank">ira@connectmevoice.com</a></div>
</font></span></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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></div></div>