Hi Daniel<div><br></div><div>Just to let you know I followed your advice and we deployed kamailio 3.0.1. </div><div>We are still doing several tests, but I can say already we don't have anymroe errors with tcp connections ...</div>
<div><br></div><div>Cheers</div><div>Pascal</div><div><br><br><div class="gmail_quote">On Fri, Mar 12, 2010 at 6:04 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<div><div></div><div class="h5"><br>
<br>
On 03/11/2010 05:58 PM, Iņaki Baz Castillo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2010/3/11 Pascal Maugeri<<a href="mailto:pascal.maugeri@gmail.com" target="_blank">pascal.maugeri@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does such NOTIFY go to a TCP registered user? Of course if there is<br>
not an existing TCP connection between Kamailio and the final natted<br>
user then it's not possible to send such NOTIFY.<br>
<br>
<br>
</blockquote>
Do you mean that the user is sending "transport=tcp" in his Contact header ?<br>
<br>
</blockquote>
This must be present in the initial SUBSCRIBE. However if the client<br>
is behind NAT and uses TCP it's required some way to mantain the<br>
keepalive in the router, if not a future NOTIFY could not arrive. A<br>
common approach is the client sending some TCP data through the<br>
existing connection (i.e.<CRLF><CRLF> as defined in defat-oubound,<br>
now RFC XXXX).<br>
<br>
</blockquote></div></div>
I have seen clients sending registration over UDP requiring to be contacted via TCP.<br>
<br>
To be sure it registers via TCP check the configuration of the phone and watch the sip traffic with ngrep (or ethereal) to see the transport layer protocol.<br>
<br>
Connecting from server to a client behind nat is possible only if you have port forwarding on your nat box to phone IP address. Therefore, if the phone connects via tcp it must keep the connection open. If for some reason it closes, it must re-open it. Otherwise it becomes unreachable.<br>
<br>
In the server side there are lot of tcp options to tune the behavior and optimize. I do suggest using version 3.0 for a much improved TCP architecture and implementation (including asynchronous tcp -- in case you deal with lot of tcp connections, then this saves you).<br>
<a href="http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.0.x#tcp_parameters" target="_blank">http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.0.x#tcp_parameters</a><br>
<br>
Worth to mention as well that you can change the value of tcp parameters at runtime without need to restart (e.g., connecting timeout, send timeout, etc) using sercmd.<br>
<br>
Cheers,<br>
Daniel<br><font color="#888888">
<br>
-- <br>
Daniel-Constantin Mierla<br>
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010<br>
* <a href="http://www.asipto.com/index.php/sip-router-masterclass/" target="_blank">http://www.asipto.com/index.php/sip-router-masterclass/</a><br>
<br>
</font></blockquote></div><br></div>