[SR-Users] [Kamailio-Users] Relaying NOTIFY UDP messages over TCP

Daniel-Constantin Mierla miconda at gmail.com
Wed Apr 14 11:51:48 CEST 2010


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 
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>
>     On 03/11/2010 05:58 PM, Iñaki Baz Castillo wrote:
>
>         2010/3/11 Pascal Maugeri<pascal.maugeri at gmail.com
>         <mailto:pascal.maugeri at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100414/864919e1/attachment.htm>


More information about the sr-users mailing list