Hear hear!<div><div><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 10:17 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.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">Its actually somewhat ridiculous and one of my personal favorites in terms of RFC smoke and mirrors in SIP to try and cover up a flaw with more specs. They basically say:<div>
<br></div><div><br></div><div>
If the total packet including the sip headers and the payload exceeds the MTU and you are using the UDP transport, you MUST try sending the packet over TCP instead. If that times out or fails then you SHOULD send it over UDP anyway.</div>
<div><br></div><div><br></div><div>THEREFORE by virtue of this decree:</div><div><br></div><div>You MUST implement your sip stack to accept UDP packets of up to 65536 bytes.</div><div><br>
</div><div>AND</div><div><br></div><div>You MUST implement both TCP and UDP transports.</div><div><br></div><div><br></div><div>So in short, you are not supposed to send anything over udp that exceeds the mtu yet you are required to implement it so its possible.</div>
<div><br></div><div>Many stacks, including Asterisk for many of the first half of FS existence, did not implement TCP so with this rule being enforced, the packets would sit there for 2-5 min then give up and change to UDP. How's that for PDD.</div>
<div><br></div><div>Anyway, we choose to ignore this rule intentionally and just stick with the negotiated protocol. If you find yourself in this situation the solution is to use TCP.</div><div><br></div>
<div><br></div><div>P.S.</div><div><br></div><div>If they did not use 2k of XML to transmit about 12 bytes worth of useful info regarding the state of the presence, we would not have this problem to begin with ;)</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>
<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>
<br></div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 4:02 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">Thank you for your information. It did help!<span><font color="#888888"><div><br></div><div>
Ira</div></font></span></div><div class="gmail_extra"><div><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>
<br><br></div><div><div><div class="gmail_quote">On Sun, Apr 7, 2013 at 12:49 PM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr"><<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" target="_blank">http://www.rfc-ref.org/RFC-TEXTS/3261/chapter18.html</a></div>
<div><a href="http://www.ietf.org/rfc/rfc3428.txt" target="_blank">http://www.ietf.org/rfc/rfc3428.txt</a></div>
<div><a href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-August/013857.html" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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><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" target="_blank">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" 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>
<br></blockquote></div><br></div></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">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" 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>
<br></blockquote></div><br></div></div></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">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" 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>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div>-- <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>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</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="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:<a href="tel:%2B19193869900" value="+19193869900" target="_blank">+19193869900</a>
</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>