<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">What you're after is probably something like <a href="http://tools.ietf.org/html/rfc5761" target="_blank">http://tools.ietf.org/html/rfc5761</a> - patches welcome ;)</blockquote>
<div><br></div><div>... that wasn't the document I was after. I think I had seen a draft about multiplexing SIP+RTP, but I may be mistaken.</div><div class="" style="font-family:arial,sans-serif;font-size:13px"></div>
<div class="" style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 September 2013 14:49, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><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">Wondering why the FS developers default to not including rtpmap lines<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">for statically defined RTP payload types?</span></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>It shouldn't be such an issue over TCP.</div><div><br></div><div>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.</div>
<div><br></div><div><div class="im"><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">Wonder why SIP signalling over TCP or TLS is much more reliable</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">through various NAT and firewall devices?</span></blockquote>
<div><br></div></div><div>That's not necessarily a given.</div></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
<div class="im">
<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 wonder if FS could multiplex SIP and RTP over the same port someday?</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">Maybe support deflate encoding?</span></blockquote>
<div><br></div></div><div>That wouldn't automatically work. It would need support by both ends and protocol changes to support it.</div></div><div><br></div><div>What you're after is probably something like <a href="http://tools.ietf.org/html/rfc5761" target="_blank">http://tools.ietf.org/html/rfc5761</a> - patches welcome ;)</div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On 20 September 2013 14:07, 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">
Somewhat off-topic but because it comes up here regularly.<br>
<br>
Wondering why the FS developers default to not including rtpmap lines<br>
for statically defined RTP payload types?<br>
<br>
Wonder why SIP signalling over TCP or TLS is much more reliable<br>
through various NAT and firewall devices?<br>
<br>
Apple has put a significant amount of effort into redesigning Facetime<br>
to better handle NAT and firewall devices. More details here:<br>
<br>
<a href="http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html" target="_blank">http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html</a><br>
<br>
I wonder if FS could multiplex SIP and RTP over the same port someday?<br>
Maybe support deflate encoding?<br>
<br>
--<br>
Kristian Kielhofner<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">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" target="_blank">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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>