[Freeswitch-users] Presence Sanity Check

Tue Apr 9 01:50:44 MSD 2013

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130408/a66bc6cd/attachment-0001.html 