9 Mar
2010
9 Mar
'10
2:54 p.m.
Hi
We need to force some NOTIFY messages going through our kamailio instance
over UDP to be sent over TCP.
For that purpose we inserted the following relaying rule at the beginning of
the routing script:
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}
if(msg:len>1300 && is_method("NOTIFY") && proto==UDP)
{
$du = "sip:" + $(ruri{uri.host}) + ":" + $(ruri{uri.port}) +
";transport=tcp";
t_relay();
exit;
}
[...]
This works well if the destination of the NOTIFY message is not behind NAT.
We're looking for a solution for the NAT case. We did some tests using
lookup("location") before changing $du but we did not get any success.
Do you have any idea on how to implement this relaying properly ?
Is it acceptable to change the $du and then execute the t_relay as we did ?
Cheers
Pascal
9 Mar
9 Mar
3:10 p.m.
2010/3/9 Pascal Maugeri <pascal.maugeri(a)gmail.com>om>:
Hi
We need to force some NOTIFY messages going through our kamailio instance
over UDP to be sent over TCP.
For that purpose we inserted the following relaying rule at the beginning of
the routing script:
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}
if(msg:len>1300 && is_method("NOTIFY") && proto==UDP)
{
$du = "sip:" + $(ruri{uri.host}) + ":" + $(ruri{uri.port}) +
";transport=tcp";
t_relay();
exit;
}
[...]
This works well if the destination of the NOTIFY message is not behind NAT.
We're looking for a solution for the NAT case. We did some tests using
lookup("location") before changing $du but we did not get any success.
Do you have any idea on how to implement this relaying properly ?
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.
Is it acceptable to change the $du and then execute
the t_relay as we did ?
Yes.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11 Mar
11 Mar
5:24 p.m.
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 ?
Is it acceptable to change the $du and then
execute the t_relay as we did
?
Yes.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:58 p.m.
2010/3/11 Pascal Maugeri <pascal.maugeri(a)gmail.com>om>:
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ñaki Baz Castillo
<ibc(a)aliax.net>
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 ?
12 Mar
12 Mar
6:04 p.m.
Hello,
On 03/11/2010 05:58 PM, Iñaki Baz Castillo wrote:
2010/3/11 Pascal
Maugeri<pascal.maugeri(a)gmail.com>om>:
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/
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 ?
14 Apr
14 Apr
12:42 p.m.
New subject: [Kamailio-Users] Relaying NOTIFY UDP messages over TCP
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 ...
Cheers
Pascal
On Fri, Mar 12, 2010 at 6:04 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
On 03/11/2010 05:58 PM, Iñaki Baz Castillo wrote:
2010/3/11 Pascal
Maugeri<pascal.maugeri(a)gmail.com>om>:
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/
Does such NOTIFY go to a TCP registered user? Of
course if there is
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).
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 ?
12:51 p.m.
New subject: [Kamailio-Users] Relaying NOTIFY UDP messages over TCP
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(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 03/11/2010 05:58 PM, Iñaki Baz Castillo wrote:
2010/3/11 Pascal Maugeri<pascal.maugeri(a)gmail.com
<mailto:pascal.maugeri@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
1:08 p.m.
New subject: [Kamailio-Users] Relaying NOTIFY UDP messages over TCP
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(a)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(a)gmail.com> wrote:
Hello,
On 03/11/2010 05:58 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
2010/3/11 Pascal
Maugeri<pascal.maugeri(a)gmail.com>om>:
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/
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).
5336
days inactive
5372
days old
7 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Pascal Maugeri