Hi Folks, ignition on> You have to be there to get your way. When all this was being nailed down, no-one spoke up. Trust me, I was listening. I was there during this phase -- the SIP crowd who came up with the standards *were* open to well argued ideas, so if you all had been there, you could well have deflected the dumb schemes as they came up. [OK, you'd have argued with a bunch of folk from MoFoCos, who *really* wanted to get SIP working as they know that circuit switched infrastructures just were not going to cut it, and had their own priorities; frankly, they were the main ones speaking and there wasn't anyone else to argue against them]. SIP was always designed as a "single packet per message" scheme. IIRC, there were always two SIP camps -- those who required secure signalling (and thus TCP/SRTP and so on), and those who wanted a really lightweight scheme with low bandwidth overheads [remember, this all came up in the '90s, when bandwidth was NOT cheap]. Drop back to TCP was seen as a rare event, as the SIP main body was tight (very tight, if you used the short forms), and you simply wouldn't have sub-parts that big with *sane* SIP messages so that MTU was going to hurt. If you WERE going to send something that was over the MTU, you'd start with or switch over to TCP -- the assumption being that this latter would only happen in rare situations (even when carrying all kinds of piggy-backed ISUP data). As for messaging -- remember that the IETF was stuck in the grinder between the big IM providers, who were trying to find a common protocol between their networks. This looked like being some IMPP-style mung. In parallel with that, the SIP folks were initially content with MESSAGE; after all, who in their right mind would send an HTML page full of mung, when it was just for display on a phone -- thus we had an SMS style scheme that worked fine, and all was cool. IIRC, MESSAGE (and sending in-signalling channel messages) was knocked up overnight during an IETF meeting, just to point out to the IMPP folk and the "data architects" that it didn't need to be hard if you have a sensible signalling scheme. Then the XMPP stuff arose from the ashes of the IM network interop work (which had crashed and burned fairly spectacularly in the IETF). The XMPP folk had already drunk far too much of the XML cool aid. By this time, SIP had already produced a Presence model that was rapidly getting complex, and choosing to switch over to XML as the one true representation made the SIP sub-parts expand really quickly. At this point, I personally lost interest. Even the names were getting beyond me: I mean, a "presentity" -- had the 400 pound Gorilla who specified this lot not been taught English? In particular, the MoFoCos wanted to be able to provide "rich presence" and something at least as good as IM, which had become fashionable even they had heard of it. As they'd just rearranged their networks to use SIP at the core, that meant that they needed some serious work done. Recall that a lot of the parameters and extra mung in the headers was introduced just for commercial providers (and both 3GPP and 3GPP2 were using SIP to carry everything including the kitchen sink inside the signalling packets -- i.e., SIP, which gave the main body a heck of a bloat, before we start on the sub-parts). If SIP was to be able to carry these kind of bloated HTML-like monstrosities both as headers AND to cover the kind of "rich presence" and IM stuff we all have grown to love, the clean -- single packet -- model started to creak, and the transition from UDP to TCP was no longer going to be a rare event for loons who just couldn't control themselves and hadn't heard of sigcomp. As for the 1500 byte limit (i.e. the typical MTU) for UDP messages, that's a reflection of the original model of single packet messages. Going for a scheme that sends out > MTU messages (i.e. sends fragments out over the net), was and is a hideous kludge, and falls over with a lot of the cheap home routers people seem to use. So ... if you're going to do complex headers and messaging or the 15 million different variants on presence (as they are now, i.e. XML to the hilt), then start out with TCP -- don't even bother trying to use god's own protocol in a session. If you're doing voice and -basic- presence, UDP is fine (and don't forget, sigcomp exists to keep the bandwidth down, particularly between servers). <flame off all the best, Lawrence On 10 Apr 2013, at 00:48, Ira Tessler wrote:
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
_________________________________________________________________________ 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