[Freeswitch-users] OT: Apple goes to great lengths to defeat NAT and firewalls with new Facetime

[Andrew Cassidy]

It's all about SCTP anyway :)


On 20 September 2013 14:55, Steven Ayre <steveayre at gmail.com> wrote:

> Separating SIP and RTP messages is probably actually fairly easy since SIP
> messages start "SIP/2.0" and RTP will not.
>
> Architecturally the SIP and RTP stacks are implemented by separate
> libraries though, and having them both bound to the same port would be far
> from trivial (both libraries would need to be rewritten to go via some
> abstraction layer). It'd also only be possible to do it for UDP.
>
> -Steve
>
>
> On 20 September 2013 14:50, Steven Ayre <steveayre at gmail.com> wrote:
>
>> What you're after is probably something like
>>> http://tools.ietf.org/html/rfc5761 - patches welcome ;)
>>
>>
>> ... that wasn't the document I was after. I think I had seen a draft
>> about multiplexing SIP+RTP, but I may be mistaken.
>>
>>
>>
>> On 20 September 2013 14:49, Steven Ayre <steveayre at gmail.com> wrote:
>>
>>> Wondering why the FS developers default to not including rtpmap lines
>>>> for statically defined RTP payload types?
>>>
>>>
>>> Because SIP over UDP doesn't play well with fragmentation. SDP can make
>>> packets large than the PMTU, leading to fragmented packets, which leads to
>>> devices ignoring the packet. Removing the unnecessary rtpmap lines means
>>> smaller SDP so smaller packet so less likelihood of that being an issue.
>>>
>>> It shouldn't be such an issue over TCP.
>>>
>>> Devices *should* support it since the standard explicitly say the rtpmap
>>> isn't required for static types, but there are some manufacturers who
>>> ignored that part so there's the verbose_sdp=true compatibility option for
>>> them.
>>>
>>> Wonder why SIP signalling over TCP or TLS is much more reliable
>>>
>>> through various NAT and firewall devices?
>>>
>>>
>>> That's not necessarily a given.
>>>
>>> In general though because the TCP connection explicitly signals the
>>> connection closing the mapping will stay in the firewall. With UDP it is
>>> removed after a long period of inactivity. That can cause problems with
>>> signalling during a phone call unless the endpoints send keepalive packets
>>> often enough.
>>>
>>> TLS will prevent the router helping with SIP ALG - you must have
>>> endpoints capable of doing NAT traversal themselves (STUN). Though that's a
>>> good idea in all cases anyway.
>>>
>>>  I wonder if FS could multiplex SIP and RTP over the same port someday?
>>>
>>> Maybe support deflate encoding?
>>>
>>>
>>> That wouldn't automatically work. It would need support by both ends and
>>> protocol changes to support it.
>>>
>>> What you're after is probably something like
>>> http://tools.ietf.org/html/rfc5761 - patches welcome ;)
>>>
>>>
>>>
>>>
>>>
>>> On 20 September 2013 14:07, Kristian Kielhofner <kris at kriskinc.com>wrote:
>>>
>>>> Somewhat off-topic but because it comes up here regularly.
>>>>
>>>> Wondering why the FS developers default to not including rtpmap lines
>>>> for statically defined RTP payload types?
>>>>
>>>> Wonder why SIP signalling over TCP or TLS is much more reliable
>>>> through various NAT and firewall devices?
>>>>
>>>> Apple has put a significant amount of effort into redesigning Facetime
>>>> to better handle NAT and firewall devices.  More details here:
>>>>
>>>> http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html
>>>>
>>>> I wonder if FS could multiplex SIP and RTP over the same port someday?
>>>>  Maybe support deflate encoding?
>>>>
>>>> --
>>>> Kristian Kielhofner
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> 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
>
>


-- 
*Andrew Cassidy BSc (Hons) MBCS SSCA*
Managing Director


*T <info at cassidywebservices.co.uk> *03300 100 960
*F<info at cassidywebservices.co.uk>
 *03300 100 961
*E <info at cassidywebservices.co.uk> *andrew at cassidywebservices.co.uk
*W <info at cassidywebservices.co.uk> *www.cassidywebservices.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130920/331a3533/attachment-0001.html