[Freeswitch-users] Presence Sanity Check

Wed Apr 10 03:48:00 MSD 2013

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