OT: Apple goes to great lengths to defeat NAT and firewalls with new Facetime
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
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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
It's all about SCTP anyway :) On 20 September 2013 14:55, Steven Ayre <steveayre@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@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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
Well SCTP operates at the same level as UDP and TCP. Unfortunately not enough systems support it, though I have done some work with SCTP in the lab in the past - even for media streams, not just sigtran. I never did the "send packets at the server until smoke comes out" type of load testing, so I don't know if the added complexity in sctp would be cause for lower capacity per server. However, another upshot is that it (sctp) can even mux multiple streams into a packet. I think that sofia itself supports sctp, but I don't think that mod_sofia does. I've not looked closely to see, though. I for one would welcome our new SCTP overlords if and when they ever get here. (I'm still waiting for our ipv6 overlords to arrive as well...) -Yossi On 09/20/2013 09:07 AM, Andrew Cassidy wrote:
It's all about SCTP anyway :)
On 20 September 2013 14:55, Steven Ayre <steveayre@gmail.com <mailto:steveayre@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@gmail.com <mailto:steveayre@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@gmail.com <mailto:steveayre@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@kriskinc.com <mailto:kris@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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 <mailto:info@cassidywebservices.co.uk> *03300 100 960 *F <mailto:info@cassidywebservices.co.uk> *03300 100 961 *E <mailto:info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk <mailto:andrew@cassidywebservices.co.uk> *W <mailto:info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk <http://www.cassidywebservices.co.uk>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Fri, Sep 20, 2013 at 9:49 AM, Steven Ayre <steveayre@gmail.com> wrote:
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.
I'm guessing you didn't read the post first :). My questions here were somewhat rhetorical and certainly not posed by me (seeing as I go into the same kind of detail you have). If you included it for list archival purposes, excellent!
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.
In my experience with a fairly large network and a number of endpoints TCP fragmentation is *much* more reliable than UDP fragmentation. Various stateful firewalls also handle TCP much better (connection oriented and used by most applications people care about - more testing, etc). Your points about keepalives and TLS are spot on although many devices don't have the "luxury" of keepalives due to issues with battery power.
Maybe support deflate encoding?
That wouldn't automatically work. It would need support by both ends and protocol changes to support it.
I'd hope by now you realize that I understand that - which is why I've raised this point simultaneously on the FreeSWITCH, Kamailio, Asterisk, and Wireshark mailing lists. I'm hoping to builder broader support for these kinds of "standard" features within the open source ecosystem. -- Kristian Kielhofner
I'm guessing you didn't read the post first :). My questions here
were somewhat rhetorical and certainly not posed by me (seeing as I go
into the same kind of detail you have). If you included it for list archival purposes, excellent!
Truth is I answered the mail as I went top-bottom... didn't actually read the blog post. ;) Apologies On 20 September 2013 15:11, Kristian Kielhofner <kris@kriskinc.com> wrote:
On Fri, Sep 20, 2013 at 9:49 AM, Steven Ayre <steveayre@gmail.com> wrote:
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.
I'm guessing you didn't read the post first :). My questions here were somewhat rhetorical and certainly not posed by me (seeing as I go into the same kind of detail you have). If you included it for list archival purposes, excellent!
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.
In my experience with a fairly large network and a number of endpoints TCP fragmentation is *much* more reliable than UDP fragmentation. Various stateful firewalls also handle TCP much better (connection oriented and used by most applications people care about - more testing, etc). Your points about keepalives and TLS are spot on although many devices don't have the "luxury" of keepalives due to issues with battery power.
Maybe support deflate encoding?
That wouldn't automatically work. It would need support by both ends and protocol changes to support it.
I'd hope by now you realize that I understand that - which is why I've raised this point simultaneously on the FreeSWITCH, Kamailio, Asterisk, and Wireshark mailing lists. I'm hoping to builder broader support for these kinds of "standard" features within the open source ecosystem.
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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. In my experience with a fairly large network and a number of endpoints TCP fragmentation is *much* more reliable than UDP fragmentation. Various stateful firewalls also handle TCP much better (connection oriented and used by most applications people care about - more testing, etc). Your points about keepalives and TLS are spot on although many devices don't have the "luxury" of keepalives due to issues with battery power.
For archival purposes (I suspect you know this)... It solves the signalling issues, but the reason I said "not a given" is that the RTP stream is still UDP. That means a call on hold can still lose the port mapping. You still have the signalling, but that isn't much use without the audio. You still need to obtain the correct ip:port for the SDP to setup the RTP - STUN or SIP ALG, and RTP auto-adjust as a workaround for bad addresses in some cases. SIP/TCP solves some of the issues, but not all. On 20 September 2013 15:11, Kristian Kielhofner <kris@kriskinc.com> wrote:
On Fri, Sep 20, 2013 at 9:49 AM, Steven Ayre <steveayre@gmail.com> wrote:
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.
I'm guessing you didn't read the post first :). My questions here were somewhat rhetorical and certainly not posed by me (seeing as I go into the same kind of detail you have). If you included it for list archival purposes, excellent!
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.
In my experience with a fairly large network and a number of endpoints TCP fragmentation is *much* more reliable than UDP fragmentation. Various stateful firewalls also handle TCP much better (connection oriented and used by most applications people care about - more testing, etc). Your points about keepalives and TLS are spot on although many devices don't have the "luxury" of keepalives due to issues with battery power.
Maybe support deflate encoding?
That wouldn't automatically work. It would need support by both ends and protocol changes to support it.
I'd hope by now you realize that I understand that - which is why I've raised this point simultaneously on the FreeSWITCH, Kamailio, Asterisk, and Wireshark mailing lists. I'm hoping to builder broader support for these kinds of "standard" features within the open source ecosystem.
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Andrew Cassidy
-
I put the Who? in Mishehu
-
Kristian Kielhofner
-
Steven Ayre