<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">I'm guessing you didn't read the post first :). My questions here</span></blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">were somewhat rhetorical and certainly not posed by me (seeing as I go<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">into the same kind of detail you have). If you included it for list<br></span><span style="font-family:arial,sans-serif;font-size:13px">archival purposes, excellent!</span></blockquote>
<div><br></div><div>Truth is I answered the mail as I went top-bottom... didn't actually read the blog post. ;)</div><div><br></div><div>Apologies</div><div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 20 September 2013 15:11, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kris@kriskinc.com" target="_blank">kris@kriskinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Sep 20, 2013 at 9:49 AM, Steven Ayre <<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>> wrote:<br>
> Because SIP over UDP doesn't play well with fragmentation. SDP can make<br>
> packets large than the PMTU, leading to fragmented packets, which leads to<br>
> devices ignoring the packet. Removing the unnecessary rtpmap lines means<br>
> smaller SDP so smaller packet so less likelihood of that being an issue.<br>
><br>
> It shouldn't be such an issue over TCP.<br>
><br>
> Devices *should* support it since the standard explicitly say the rtpmap<br>
> isn't required for static types, but there are some manufacturers who<br>
> ignored that part so there's the verbose_sdp=true compatibility option for<br>
> them.<br>
<br>
</div> I'm guessing you didn't read the post first :). My questions here<br>
were somewhat rhetorical and certainly not posed by me (seeing as I go<br>
into the same kind of detail you have). If you included it for list<br>
archival purposes, excellent!<br>
<div class="im"><br>
> That's not necessarily a given.<br>
><br>
> In general though because the TCP connection explicitly signals the<br>
> connection closing the mapping will stay in the firewall. With UDP it is<br>
> removed after a long period of inactivity. That can cause problems with<br>
> signalling during a phone call unless the endpoints send keepalive packets<br>
> often enough.<br>
><br>
> TLS will prevent the router helping with SIP ALG - you must have endpoints<br>
> capable of doing NAT traversal themselves (STUN). Though that's a good idea<br>
> in all cases anyway.<br>
<br>
</div> In my experience with a fairly large network and a number of<br>
endpoints TCP fragmentation is *much* more reliable than UDP<br>
fragmentation. Various stateful firewalls also handle TCP much better<br>
(connection oriented and used by most applications people care about -<br>
more testing, etc). Your points about keepalives and TLS are spot on<br>
although many devices don't have the "luxury" of keepalives due to<br>
issues with battery power.<br>
<div class="im"><br>
>> Maybe support deflate encoding?<br>
><br>
><br>
> That wouldn't automatically work. It would need support by both ends and<br>
> protocol changes to support it.<br>
<br>
</div> I'd hope by now you realize that I understand that - which is why<br>
I've raised this point simultaneously on the FreeSWITCH, Kamailio,<br>
Asterisk, and Wireshark mailing lists. I'm hoping to builder broader<br>
support for these kinds of "standard" features within the open source<br>
ecosystem.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Kristian Kielhofner<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>