[Freeswitch-users] Presence Sanity Check

Tue Apr 9 01:17:31 MSD 2013

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