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 <mailto: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
        <mailto: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

Reply via email to