Hi all, I'm trying to setup a very basic scenario with kamailio 3.0. It is placed in front of a softswitch and it has to modify some headers before forward (stateless) messages to softswitch. If I use route { rewritehost("192.168.10.1"); t_relay(); }
all work, but if I want to do that stateless and I use forward() or send() instead of t_relay(), I get a syntax error: "bad forward argument" or "bad send argument". If I use ... forward("udp:192.168.10.1:5060"); ...
I see in the log /usr/local/sbin/kamailio[3675]: : <core> [proxy.c:271]: ERROR: mk_proxy: could not resolve hostname: "udp:192.168.10.1:5060" /usr/local/sbin/kamailio[3675]: ERROR: <core> [route.c:1026]: fixing failed (code=-478) at cfg:/usr/local/etc/kamailio/kamailio.cfg:77 Same error using the long format of send() function.
I can't see any particular hint on the documentation, what I'm missing?
Thank you. Best regards.
Hello,
On 2/9/10 10:35 AM, Antonio Reale wrote:
Hi all, I'm trying to setup a very basic scenario with kamailio 3.0. It is placed in front of a softswitch and it has to modify some headers before forward (stateless) messages to softswitch. If I use route { rewritehost("192.168.10.1"); t_relay(); }
all work, but if I want to do that stateless and I use forward() or send() instead of t_relay(), I get a syntax error: "bad forward argument" or "bad send argument". If I use ... forward("udp:192.168.10.1:5060"); ...
This one should work:
route { rewritehost("192.168.10.1"); forward(); }
If you don't want to change the r-uri:
$du = "sip:192.168.10.1:5060"; forward();
The forward in 3.0 has a slightly different parameters format than 1.5.x. Docs should be updated and I will try to add backward compatibility alternative.
Cheers, Daniel
I see in the log /usr/local/sbin/kamailio[3675]: :<core> [proxy.c:271]: ERROR: mk_proxy: could not resolve hostname: "udp:192.168.10.1:5060" /usr/local/sbin/kamailio[3675]: ERROR:<core> [route.c:1026]: fixing failed (code=-478) at cfg:/usr/local/etc/kamailio/kamailio.cfg:77 Same error using the long format of send() function.
I can't see any particular hint on the documentation, what I'm missing?
Thank you. Best regards.
2010/2/9 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
Hi Daniel, thanks for reply.
This one should work:
route { rewritehost("192.168.10.1"); forward(); }
Already tried that, but it doesn't work: route { rewritehost("192.168.10.1"); forward(); }
result in: "bad forward argument".
If you don't want to change the r-uri:
$du = "sip:192.168.10.1:5060"; forward();
Thanks for the suggestion, in this way it is more transparent...
The forward in 3.0 has a slightly different parameters format than 1.5.x. Docs should be updated and I will try to add backward compatibility alternative.
Cheers, Daniel
Regards.
Hello,
On 2/9/10 11:07 AM, Antonio Reale wrote:
2010/2/9 Daniel-Constantin Mierlamiconda@gmail.com:
Hello,
Hi Daniel, thanks for reply.
This one should work:
route { rewritehost("192.168.10.1"); forward(); }
Already tried that, but it doesn't work: route { rewritehost("192.168.10.1"); forward(); }
result in: "bad forward argument".
you are right. I checked the source and the function without params was missing, it is the old style:
forward(uri:host, uri:port);
However, I just added it in kamailio_3.0 branch (it is an alias to forward(uri:host, uri:port) for better compatibility with 1.5.x) so if you installed from git then pull again. It will be in 3.0.1.
Thanks, Daniel
If you don't want to change the r-uri:
$du = "sip:192.168.10.1:5060"; forward();
Thanks for the suggestion, in this way it is more transparent...
The forward in 3.0 has a slightly different parameters format than 1.5.x. Docs should be updated and I will try to add backward compatibility alternative.
Cheers, Daniel
Regards.
2010/2/9 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
you are right. I checked the source and the function without params was missing, it is the old style:
forward(uri:host, uri:port);
However, I just added it in kamailio_3.0 branch (it is an alias to forward(uri:host, uri:port) for better compatibility with 1.5.x) so if you installed from git then pull again. It will be in 3.0.1.
Thanks, now it works. Just a question. In stateful mode I can handle reply from softswitch using t_on_reply to modify headers before forward the message to the originating. Now that kamailio works in stateless mode, how can I manipulate the reply from the softswitch? I tried doing the manipulation in the main route without success.
Thanks, Daniel
Regards.
Am 09.02.2010 13:15, schrieb Antonio Reale:
2010/2/9 Daniel-Constantin Mierlamiconda@gmail.com:
Hello,
you are right. I checked the source and the function without params was missing, it is the old style:
forward(uri:host, uri:port);
However, I just added it in kamailio_3.0 branch (it is an alias to forward(uri:host, uri:port) for better compatibility with 1.5.x) so if you installed from git then pull again. It will be in 3.0.1.
Thanks, now it works. Just a question. In stateful mode I can handle reply from softswitch using t_on_reply to modify headers before forward the message to the originating.
t_on_reply is a function of the tm module. If you forward stateless, of course the t_on_reply does not work.
Now that kamailio works in stateless mode, how can I manipulate the reply from the softswitch? I tried doing the manipulation in the main route without success.
You can try to do your manipulation in the default reply route, which will be executed always, before execution of reply routes armed by t_on_reply:
onreply_route { # default onreply_route xlog("L_DBG","[$Tf] $rs $rr (From: $fu <- To: $tu)\n"); ... }
regards Klaus
Hi Klaus,
2010/2/9 Klaus Darilion klaus.mailinglists@pernau.at:
t_on_reply is a function of the tm module. If you forward stateless, of course the t_on_reply does not work.
Sure. I was aware of this.
You can try to do your manipulation in the default reply route, which will be executed always, before execution of reply routes armed by t_on_reply:
onreply_route { # default onreply_route xlog("L_DBG","[$Tf] $rs $rr (From: $fu <- To: $tu)\n"); ... }
Great! I missed that the default onreply route was independent from t_on_reply. Thank you very much for the precious suggestion.
regards Klaus
Best regards.
-
Antonio Reale -
Daniel-Constantin Mierla -
Klaus Darilion