I second the hear hear!!! Ira Tessler Lead Software Engineer ConnectMe (732) 490-9007 x2 ira@connectmevoice.com On Mon, Apr 8, 2013 at 5:50 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hear hear!
On Mon, Apr 8, 2013 at 10:17 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
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:
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.
THEREFORE by virtue of this decree:
You MUST implement your sip stack to accept UDP packets of up to 65536 bytes.
AND
You MUST implement both TCP and UDP transports.
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.
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.
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.
P.S.
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 ;)
On Mon, Apr 8, 2013 at 4:02 PM, Ira Tessler <ira@connectmevoice.com>wrote:
Thank you for your information. It did help!
Ira
Ira Tessler Lead Software Engineer ConnectMe (732) 490-9007 x2 ira@connectmevoice.com
On Sun, Apr 7, 2013 at 12:49 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
In regards to the UDP fragmentation, this is an extremely good question.
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.
I've had a read through various documentation; http://www.rfc-ref.org/RFC-TEXTS/3261/chapter18.html http://www.ietf.org/rfc/rfc3428.txt
https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-August/013857....
http://lists.freeswitch.org/pipermail/freeswitch-users/2011-February/068372....
http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05912.h...
Anthony has stated the following; *"the only reliable answer is use TCP."*
There was also the option of enabling compact headers;
http://lists.freeswitch.org/pipermail/freeswitch-users/2011-December/078633....
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.
Hope this helps!
Cal
On Sat, Apr 6, 2013 at 2:28 PM, Ira Tessler <ira@connectmevoice.com>wrote:
I just need a little guidance with the way presence works. Forgive me if I am asking novice questions.
Background (simple version) We run Freeswitch in a hosted/cloud environment in a data center. We have IP phones in our office on our LAN.
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.
He is my questions/issue/confusion. 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??)
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)?
Thank you in advance!
Ira Tessler Lead Software Engineer ConnectMe (732) 490-9007 x2 ira@connectmevoice.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org