Yes indeed, we mainly use TCP as our SIP INVITE conveys a XML document with list of callees (>UDP MTU) and our presence notfications are also big messages. Pascal
On Wed, Apr 14, 2010 at 11:51 AM, Daniel-Constantin Mierla < mico...@gmail.com> wrote: > Hi Pascal, > > > On 4/14/10 11:42 AM, Pascal Maugeri wrote: > > Hi Daniel > > Just to let you know I followed your advice and we deployed kamailio > 3.0.1. > We are still doing several tests, but I can say already we don't have > anymroe errors with tcp connections ... > > ok, thanks for feedback. Indeed, 3.0+ is far more improved than what was in > openser/kamailio 1.0 to 1.5 in respect to tcp, therefore anyone facing heavy > tcp needs should consider this 3.0+. > > Cheers, > Daniel > > > > Cheers > Pascal > > > On Fri, Mar 12, 2010 at 6:04 PM, Daniel-Constantin Mierla < > mico...@gmail.com> wrote: > >> Hello, >> >> >> On 03/11/2010 05:58 PM, Iñaki Baz Castillo wrote: >> >>> 2010/3/11 Pascal Maugeri<pascal.maug...@gmail.com>: >>> >>> >>>> Does such NOTIFY go to a TCP registered user? Of course if there is >>>>> not an existing TCP connection between Kamailio and the final natted >>>>> user then it's not possible to send such NOTIFY. >>>>> >>>>> >>>>> >>>> Do you mean that the user is sending "transport=tcp" in his Contact >>>> header ? >>>> >>>> >>> This must be present in the initial SUBSCRIBE. However if the client >>> is behind NAT and uses TCP it's required some way to mantain the >>> keepalive in the router, if not a future NOTIFY could not arrive. A >>> common approach is the client sending some TCP data through the >>> existing connection (i.e.<CRLF><CRLF> as defined in defat-oubound, >>> now RFC XXXX). >>> >>> >> I have seen clients sending registration over UDP requiring to be >> contacted via TCP. >> >> 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. >> >> 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. >> >> 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). >> >> http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.0.x#tcp_parameters >> >> 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. >> >> Cheers, >> Daniel >> >> -- >> Daniel-Constantin Mierla >> Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010 >> * http://www.asipto.com/index.php/sip-router-masterclass/ >> >> > > -- > Daniel-Constantin Mierla * http://www.asipto.com/ * > http://twitter.com/miconda * > http://www.linkedin.com/in/danielconstantinmierla >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
