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

[Pascal Maugeri]

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 <
miconda at 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 <
> 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>:
>>>
>>>
>>>> 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/5db5cf99/attachment.htm>