<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">And which peer will match ?<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 06/13/2014 12:32 PM, Jorge Fresneda - Ibersontel wrote:<br>
</div>
<blockquote cite="mid:539AD320.9050308@ibersontel.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Daniel,<br>
<br>
Yes, this rule, means that when the calling is "926501080" and
destination "34 + 9XXXX ..." the call is sent by the peer 4
(1057400). This is correct. <br>
<br>
The problem is here: <br>
<br>
<br>
| id | lcr_id | prefix | request_uri |
from_uri | stopper | enabled | group_id |<br>
| 38 | 1 | 34 | |
911111111 | 0 | 1 | 6 |<br>
<br>
<br>
id | lcr_id | rule_id | gw_id | priority | weight |<br>
| 38 | 1 | 38 | 6 | 3 | 1 |<br>
<br>
<br>
<br>
| 6 | 1 | CVIP52-0 | X.X.X.X | NULL |
5060 | NULL | 1 | 1 | 0 | NULL | 6 |
NULL | 6 | NULL |<br>
<br>
<br>
<br>
Thus, the call goes through the peer "CVIP52-0", but if I delete
34 (in prefix), skip this Peer.<br>
<br>
Regards,<br>
Jorge<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">El 13/06/2014 11:51, Daniel Grotti
escribió:<br>
</div>
<blockquote cite="mid:539AC998.4050704@sipwise.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">So,<br>
calling a 34XXX number, the calls should go out via in my
opinion :<br>
<br>
| 21 | 1 | 34 | ^sip:349.+@12.43.54.6$ |
926501080 | 0 | 1 | 5 |<br>
<br>
<br>
Cause it has a prefix 34 and the lowest priority:<br>
<br>
+-----+--------+---------+-------+----------+--------+<br>
| id | lcr_id | rule_id | gw_id | priority | weight |<br>
+-----+--------+---------+-------+----------+--------+<br>
| 21 | 1 | 21 | 5 | 1 | 1 |<br>
<br>
<br>
<br>
Is that the matching peer ?<br>
<br>
<br>
| 4 | 1 | 1057400 | X.X.X.X | sip05.es |
5060 | NULL | 1 | 1 | 0 | NULL | 4
| NULL | 4 | NULL |<br>
<br>
<br>
Daniel<br>
<br>
<br>
<br>
<br>
On 06/13/2014 11:42 AM, Jorge Fresneda - Ibersontel wrote:<br>
</div>
<blockquote cite="mid:539AC768.6020008@ibersontel.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Hi Daniel,<br>
<br>
<br>
lcr_gw:<br>
<br>
<br>
mysql> select * from lcr_gw;<br>
+----+--------+----------------------+----------------+--------------------+------+--------+------------+-----------+-------+------+-------+---------+----------+--------+<br>
| id | lcr_id | gw_name | ip_addr |
hostname | port | params | uri_scheme | transport |
strip | tag | flags | defunct | group_id | prefix |<br>
+----+--------+----------------------+----------------+--------------------+------+--------+------------+-----------+-------+------+-------+---------+----------+--------+<br>
| 1 | 1 | ESMD023 | X.X.X.X | NULL | 5060
| NULL | 1 | 1 | 0 | NULL | 1 |
NULL | 1 | NULL |<br>
| 4 | 1 | 1057400 | X.X.X.X | sip05.es |
5060 | NULL | 1 | 1 | 0 | NULL | 4
| NULL | 4 | NULL |<br>
| 5 | 1 | 1057401 | X.X.X.X | sip06.es |
5060 | NULL | 1 | 1 | 0 | NULL | 5
| NULL | 5 | NULL |<br>
| 6 | 1 | CVIP52-0 | X.X.X.X | NULL |
5060 | NULL | 1 | 1 | 0 | NULL | 6
| NULL | 6 | NULL |<br>
| 7 | 1 | CVIP923-23 | X.X.X.X |
NULL | 5060 | NULL | 1 | 1
| 0 | NULL | 7 | NULL | 7 | NULL |<br>
+----+--------+----------------------+----------------+--------------------+------+--------+------------+-----------+-------+------+-------+---------+----------+--------+<br>
<br>
lcr_rule<br>
mysql> select * from lcr_rule;<br>
+-----+--------+--------+-------------------------------------+--------------+---------+---------+----------+<br>
| id | lcr_id | prefix | request_uri
| from_uri | stopper | enabled | group_id |<br>
+-----+--------+--------+-------------------------------------+--------------+---------+---------+----------+<br>
| 6 | 1 | 34 | ^sip:349.+@12.43.54.6$
| | 0 | 1 | 1 |<br>
| 8 | 1 | |
| | 0 | 1 | 1 |<br>
| 21 | 1 | 34 | ^sip:349.+@12.43.54.6$ |
926501080 | 0 | 1 | 5 |<br>
| 34 | 1 | 51 | ^sip:0051.+@12.43.54.6$ |
16419340 | 0 | 1 | 4 |<br>
| 38 | 1 | <b>34 </b> |
| <b>911111111</b> | 0
| 1 | 6 |<br>
<br>
<br>
<br>
lcr_rule_target<br>
<br>
+-----+--------+---------+-------+----------+--------+<br>
| id | lcr_id | rule_id | gw_id | priority | weight |<br>
+-----+--------+---------+-------+----------+--------+<br>
| 6 | 1 | 6 | 1 | 5 | 1 |<br>
| 8 | 1 | 8 | 1 | 5 | 1 |<br>
| 21 | 1 | 21 | 5 | 1 | 1 |<br>
| 22 | 1 | 22 | 5 | 1 | 1 |<br>
| 28 | 1 | 28 | 5 | 1 | 1 |<br>
| 33 | 1 | 33 | 4 | 2 | 1 |<br>
| 34 | 1 | 34 | 4 | 2 | 1 |<br>
| 37 | 1 | 37 | 5 | 1 | 1 |<br>
| 38 | 1 | 38 | 6 | 3 | 1 |<br>
| 42 | 1 | 42 | 5 | 1 | 1 |<br>
| 48 | 1 | 48 | 4 | 2 | 1 |<br>
| 49 | 1 | 49 | 4 | 2 | 1 |<br>
| 51 | 1 | 51 | 4 | 2 | 1 |<br>
| 52 | 1 | 52 | 4 | 2 | 1 |<br>
| 53 | 1 | 53 | 4 | 2 | 1 |<br>
| 54 | 1 | 54 | 4 | 2 | 1 |<br>
| 55 | 1 | 55 | 4 | 2 | 1 |<br>
| 56 | 1 | 56 | 4 | 2 | 1 |<br>
| 57 | 1 | 57 | 4 | 2 | 1 |<br>
| 58 | 1 | 58 | 4 | 2 | 1 |<br>
| 59 | 1 | 59 | 4 | 2 | 1 |<br>
| 60 | 1 | 60 | 4 | 2 | 1 |<br>
| 61 | 1 | 61 | 4 | 2 | 1 |<br>
| 62 | 1 | 62 | 4 | 2 | 1 |<br>
| 63 | 1 | 63 | 4 | 2 | 1 |<br>
| 64 | 1 | 64 | 4 | 2 | 1 |<br>
| 66 | 1 | 66 | 5 | 1 | 1 |<br>
| 67 | 1 | 67 | 5 | 1 | 1 |<br>
| 68 | 1 | 68 | 5 | 1 | 1 |<br>
| 69 | 1 | 69 | 5 | 1 | 1 |<br>
| 70 | 1 | 70 | 5 | 1 | 1 |<br>
| 71 | 1 | 71 | 5 | 1 | 1 |<br>
| 72 | 1 | 72 | 5 | 1 | 1 |<br>
| 73 | 1 | 73 | 5 | 1 | 1 |<br>
| 74 | 1 | 74 | 5 | 1 | 1 |<br>
| 75 | 1 | 75 | 5 | 1 | 1 |<br>
| 76 | 1 | 76 | 5 | 1 | 1 |<br>
| 77 | 1 | 77 | 5 | 1 | 1 |<br>
| 78 | 1 | 78 | 4 | 2 | 1 |<br>
| 79 | 1 | 79 | 4 | 2 | 1 |<br>
| 80 | 1 | 80 | 4 | 2 | 1 |<br>
| 81 | 1 | 81 | 5 | 1 | 1 |<br>
| 82 | 1 | 82 | 5 | 1 | 1 |<br>
| 83 | 1 | 83 | 5 | 1 | 1 |<br>
| 84 | 1 | 84 | 5 | 1 | 1 |<br>
| 85 | 1 | 85 | 5 | 1 | 1 |<br>
| 86 | 1 | 86 | 5 | 1 | 1 |<br>
| 87 | 1 | 87 | 5 | 1 | 1 |<br>
| 88 | 1 | 88 | 5 | 1 | 1 |<br>
| 89 | 1 | 89 | 5 | 1 | 1 |<br>
| 90 | 1 | 90 | 4 | 2 | 1 |<br>
| 91 | 1 | 91 | 4 | 2 | 1 |<br>
| 92 | 1 | 92 | 4 | 2 | 1 |<br>
| 93 | 1 | 93 | 4 | 2 | 1 |<br>
| 94 | 1 | 94 | 4 | 2 | 1 |<br>
| 95 | 1 | 95 | 4 | 2 | 1 |<br>
| 98 | 1 | 98 | 4 | 2 | 1 |<br>
| 102 | 1 | 102 | 7 | 4 | 1 |<br>
| 107 | 1 | 107 | 6 | 3 | 1 |<br>
| 109 | 1 | 109 | 5 | 1 | 1 |<br>
+-----+--------+---------+-------+----------+--------+<br>
<br>
<br>
Regards,<br>
Jorge<br>
<br>
<br>
<div class="moz-cite-prefix">El 13/06/2014 11:22, Daniel
Grotti escribió:<br>
</div>
<blockquote cite="mid:539AC2D0.9010907@sipwise.com"
type="cite">
<pre wrap="">Hi,
give us a select of the following kamailio tables:
lcr_gw
lcr_rule
lcr_rule_target
Daniel
On 06/13/2014 10:41 AM, Jorge Fresneda - Ibersontel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
Yes, I have verified that there are no duplicate rules nor are there
two groups with the same priority.
Please, what should I check in lcr table? The rules are the same as in
the web environment
Thanks
Regards,
Jorge
El 13/06/2014 10:35, Daniel Grotti escribió:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
mmm, that's strange...are you sure you have only that rules on your
peer ?
In that case priority 1 should match Peer1.
Did you check your DB lcr table ?
Daniel
On 06/13/2014 10:06 AM, Jorge Fresneda - Ibersontel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
I note that in the manual ability to filter through the origin of the
call is contemplated. My scenario is as follows:
Peer1 with priority 1
Calle Prefix = blank
Calle pattern = blank
Caller Pattern = 91111111 (este es el llamante / subscriber)
Peer2 with priority 2
Calle Prefix = blank
Calle Pattern = blank
Caller Pattern = blank
Default rule!
Now, when I call the dessde 91111111, the call is sent by the "Peer2"
and want it to be extended by the "Peer1", whatever the destination of
the call. ¿Is possible?
Regards,
Jorge
El 12/06/2014 19:38, Daniel Grotti escribió:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
the peer is chosen using the callee prefix.
So if you do not set callee prefix, probably the call goes out via
another peer.
Also, from the handbook:
"The selection of peering servers for outbound calls is done in the
following order:
1. whether caller or callee pattern matched.
2. length of the callee prefix.
3. priority of the peering group.
4. weight of the peering servers in the selected peering group.
After one or more peering group(s) is matched for an outbound call,
all servers in this group are tried, according to their weight (lower
weight has more precedence). If a peering server replies with SIP
codes 408, 500 or 503, or if a peering server doesn’t respond at all,
the next peering server in the current peering group is used as a
fallback, one after the other until the call succeeds. If no more
servers are left in the current peering group, the next group which
matches the peering rules is going to be used."
Cheers,
Daniel
----- Original Message -----
From: "Jorge Fresneda - Ibersontel" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:j.fresneda@ibersontel.com"><j.fresneda@ibersontel.com></a>
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:spce-user@lists.sipwise.com">spce-user@lists.sipwise.com</a>
Sent: Thursday, June 12, 2014 7:24:22 PM
Subject: [Spce-user] Rewrite rule problem
Hello,
I have a problem in "rewrite rules" on Peer. When I add a "Peering
rule", if I write 34 or another number in the "Callee prefix" field
and
also write in "Caller Pattern", the call goes through this Peer
correctly, but if I put blank "Callee prefix" field and write in
"Caller
Pattern" only, the call is not sent by this peer. What do I do wrong?
Thank you,
regards
Jorge
_______________________________________________
Spce-user mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Spce-user@lists.sipwise.com">Spce-user@lists.sipwise.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.sipwise.com/listinfo/spce-user">http://lists.sipwise.com/listinfo/spce-user</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>