16 Apr
2009
16 Apr
'09
12:20 p.m.
On Monday 13 April 2009, Carlos A. Alvarez wrote:
I need help setting up carrierroute using the rewrite
prefix and the strip
function. It seem like every time I use the Rewrite Prfix function the
carrierroute module will rewrite the prefix, but then I don't get certain
reply messages on kamailio. At least from what I can see on the log.
Hi Carlos,
did i understand you correctly, the message request URI is correctly
rewritten, and can also be relayed with e.g. t_relay? But you don't get any/
some replies (for this requests) back on your server?
INFO:carrierroute:cr_do_route: uri 5555550001 was
rewritten to
sip:0115555550001@aslab.commx.net, carrier 1, domain 10
INFO:carrierroute:rewrite_uri_recursor: URI or prefix tree nodes empty,
empty rule list
INFO:carrierroute:cr_do_route: rewrite_uri_recursor doesn't
complete, uri 0115555550001, carrier 1, domain 10
Is this normal behavior? I also noticed that some messages coming back
from the host are not being processed by kamailio. For example on this
particular call I purposely get a 604 from the server.
The first log message says that the msg R-URI was correctly rewritten. The
second one means that cr was not able to find a match for the URI, either
because of an empty URI, or an empty routing tree for this case. The third
one is an information that the message was not routed.
The cr module doesn't generate any SIP failures itselfs, so the 604 should be
come from your config or an upstream server.
The thing is I
can't process a failure route for this message, because kamailio doesn't
see is, even though it is being sent back to the server.
Have you checked if the reply actually arrive on kamailio? Do you arm the
correct failure route with t_on_failure in your config before sending out the
request?
Also when I use the Strip function is looks like
carrierroute does a second
lookup on the route table. In the example below I am calling a number using
the prefix 551... The route table is below.
Usage of the strip functionality don't cause a second route lookup, i think.
+----+---------+--------+--------------+-------+------+------+-------+-----
------------+----------------+----------------+------------------------+
| id | carrier | domain | scan_prefix | flags | mask | prob | strip |
| rewrite_host | rewrite_prefix | rewrite_suffix | description
| |
+----+---------+--------+--------------+-------+------+------+-------+-----
------------+----------------+----------------+------------------------+
| 30 | 1 | 1 | 551 | 0 | 0 | 1 | 2 |
| 10.10.10.1 | | | LD-1 31 | 1 |
| 1 | 1 | 0 | 0 | 1 | 0 | 10.10.10.1 |
| | | LD |
Log for that call
INFO:carrierroute:cr_do_route: uri 5515555550004 was rewritten to
sip:15555550004@10.10.10.1, carrier 1, domain 1
The URI was correctly stripped.
INFO:carrierroute:cr_do_route: uri 15555550004 was
rewritten to
sip:15555550004@10.10.10.1, carrier 1, domain 1
This is strange. Does this both logs belong to one INVITE?
Carrier found!! ("1",
"131.226.0.144", "15555550004", "15555550004",
"COMMX-LD");
Now please note that if I remove route id 31 then the call log looks like
it is below:
INFO:carrierroute:cr_do_route: uri 5515555550004 was rewritten to
sip:15555550004@10.10.10.1, carrier 1, domain 1
INFO:carrierroute:rewrite_uri_recursor: URI or prefix tree nodes empty,
empty rule list INFO:carrierroute:cr_do_route: rewrite_uri_recursor doesn't
complete, uri 15555550004, carrier 1, domain 1
Do you relay the call after the first rewrite? Perhaps there is some routing
loop, that causes the second lookup.
It will also help if there was complete routing
example using carrierroute
v 1.5.0, since the one in the wiki is outdated. Thanks.
Can you give the URL of the wiki do you refer to?
Cheers,
Henning