[Freeswitch-users] Presence Sanity Check

Wed Apr 10 05:24:50 MSD 2013

Indeed!

But we have a 2nd chance with WebRTC ... oh wait..... They're doing
what????

The secure-only guys you mentioned have come back from exile to seek their
revenge!

http://www.freeswitch.org/node/437

On Tue, Apr 9, 2013 at 8:09 PM, Lawrence Conroy <lconroy at insensate.co.uk>wrote:

> 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 at connectmevoice.com
> >
> >
> > On Mon, Apr 8, 2013 at 5:50 PM, Cal Leeming [Simplicity Media Ltd] <
> > cal.leeming at simplicitymedialtd.co.uk> wrote:
> >
> >> Hear hear!
> >>
> >> On Mon, Apr 8, 2013 at 10:17 PM, Anthony Minessale <
> >> anthony.minessale at 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 at connectmevoice.com
> >wrote:
> >>>
> >>>> Thank you for your information. It did help!
> >>>>
> >>>> Ira
> >>>>
> >>>> Ira Tessler
> >>>> Lead Software Engineer
> >>>> ConnectMe
> >>>> (732) 490-9007 x2
> >>>> ira at connectmevoice.com
> >>>>
> >>>>
> >>>> On Sun, Apr 7, 2013 at 12:49 PM, Cal Leeming [Simplicity Media Ltd] <
> >>>> cal.leeming at 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.html
> >>>>>
> >>>>>
> http://lists.freeswitch.org/pipermail/freeswitch-users/2011-February/068372.html
> >>>>>
> >>>>>
> http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05912.html
> >>>>>
> >>>>> 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.html
> >>>>>
> >>>>> 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 at 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 at connectmevoice.com
> >>>>>>
> >>>>>>
> >>>>>>
> _________________________________________________________________________
> >>>>>> Professional FreeSWITCH Consulting Services:
> >>>>>> consulting at freeswitch.org
> >>>>>> http://www.freeswitchsolutions.com
> >>>>>>
> >>>>>> 
> >>>>>> 
> >>>>>>
> >>>>>> Official FreeSWITCH Sites
> >>>>>> http://www.freeswitch.org
> >>>>>> http://wiki.freeswitch.org
> >>>>>> http://www.cluecon.com
> >>>>>>
> >>>>>> FreeSWITCH-users mailing list
> >>>>>> FreeSWITCH-users at 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 at freeswitch.org
> >>>>> http://www.freeswitchsolutions.com
> >>>>>
> >>>>> 
> >>>>> 
> >>>>>
> >>>>> Official FreeSWITCH Sites
> >>>>> http://www.freeswitch.org
> >>>>> http://wiki.freeswitch.org
> >>>>> http://www.cluecon.com
> >>>>>
> >>>>> FreeSWITCH-users mailing list
> >>>>> FreeSWITCH-users at 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 at freeswitch.org
> >>>> http://www.freeswitchsolutions.com
> >>>>
> >>>> 
> >>>> 
> >>>>
> >>>> Official FreeSWITCH Sites
> >>>> http://www.freeswitch.org
> >>>> http://wiki.freeswitch.org
> >>>> http://www.cluecon.com
> >>>>
> >>>> FreeSWITCH-users mailing list
> >>>> FreeSWITCH-users at 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 at hotmail.com
> >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> >>> IRC: irc.freenode.net #freeswitch
> >>>
> >>> FreeSWITCH Developer Conference
> >>> sip:888 at conference.freeswitch.org
> >>> googletalk:conf+888 at conference.freeswitch.org
> >>> pstn:+19193869900
> >>>
> >>>
> _________________________________________________________________________
> >>> Professional FreeSWITCH Consulting Services:
> >>> consulting at freeswitch.org
> >>> http://www.freeswitchsolutions.com
> >>>
> >>> 
> >>> 
> >>>
> >>> Official FreeSWITCH Sites
> >>> http://www.freeswitch.org
> >>> http://wiki.freeswitch.org
> >>> http://www.cluecon.com
> >>>
> >>> FreeSWITCH-users mailing list
> >>> FreeSWITCH-users at 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 at freeswitch.org
> >> http://www.freeswitchsolutions.com
> >>
> >> 
> >> 
> >>
> >> Official FreeSWITCH Sites
> >> http://www.freeswitch.org
> >> http://wiki.freeswitch.org
> >> http://www.cluecon.com
> >>
> >> FreeSWITCH-users mailing list
> >> FreeSWITCH-users at 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 at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > 
> > 
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at 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 at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130409/3207c7f5/attachment-0001.html 