[Spce-user] Rewrite rule problem

Fri Jun 13 11:55:17 EDT 2014

Hi, 
you have several options. 
You can add a new peering group with the same configurations, so you will have one with prefix 34 and one without for example. 
Also, you can play with subscriber prefix, so if the call comes from subscriber 911111111, you can rewrite the callee into "UseMyPeer_34xxxxx", and then adding the peering rules accordingly on your peer(in order to engage that peer), then you can strip away the prefix on the outbound rewrite rules. 

There isn just one solution, it depends on your peering settings you already have. 

Daniel 

----- Original Message ----- 
From: "Jorge Fresneda - Ibersontel" <j.fresneda at ibersontel.com> 
To: spce-user at lists.sipwise.com 
Sent: Friday, June 13, 2014 4:32:49 PM 
Subject: Re: [Spce-user] Rewrite rule problem 

Hello Daniel, 

then, as I can put any prefix? I have to write all the prefixes of the world? 

Regards, 
Jorge 

El 13/06/2014 14:36, Daniel Grotti escribió: 

Peer selection is done by the PREFIX, not the callerID. 
So your peer will not be load cause you have a best matching with rule 21. 

Daniel 

On 06/13/2014 02:18 PM, Jorge Fresneda - Ibersontel wrote: 

<blockquote>
Hi Daniel, 

But.....The callerID is 911111111. 

How is it possible to match the rule 21? Rule 21 has callerID "926501080" 

Regards, 
Jorge 

El 13/06/2014 12:54, Daniel Grotti escribió: 

<blockquote>

Hi, 
if you strip away 34 from 

id | lcr_id | prefix | request_uri | from_uri | stopper | enabled | group_id | 
| 38 | 1 | 34 | | 911111111 | 0 | 1 | 6 | 

a call to a 34XXX will match RULE 21: 

| 21 | 1 | 34 | ^sip:349.+ at 12.43.54.6$ | 926501080 | 0 | 1 | 5 | 

and GW "1057401": 

| 5 | 1 | 1057401 | X.X.X.X | sip06.es | 5060 | NULL | 1 | 1 | 0 | NULL | 5 | NULL | 5 | NULL | 

Because the peer selection is based on "prefix" first. 

Daniel 

On 06/13/2014 12:38 PM, Daniel Grotti wrote: 

<blockquote>

And which peer will match ? 

On 06/13/2014 12:32 PM, Jorge Fresneda - Ibersontel wrote: 

<blockquote>
Hi Daniel, 

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. 

The problem is here: 

| id | lcr_id | prefix | request_uri | from_uri | stopper | enabled | group_id | 
| 38 | 1 | 34 | | 911111111 | 0 | 1 | 6 | 

id | lcr_id | rule_id | gw_id | priority | weight | 
| 38 | 1 | 38 | 6 | 3 | 1 | 

| 6 | 1 | CVIP52-0 | X.X.X.X | NULL | 5060 | NULL | 1 | 1 | 0 | NULL | 6 | NULL | 6 | NULL | 

Thus, the call goes through the peer "CVIP52-0", but if I delete 34 (in prefix), skip this Peer. 

Regards, 
Jorge 

El 13/06/2014 11:51, Daniel Grotti escribió: 

<blockquote>

So, 
calling a 34XXX number, the calls should go out via in my opinion : 

| 21 | 1 | 34 | ^sip:349.+ at 12.43.54.6$ | 926501080 | 0 | 1 | 5 | 

Cause it has a prefix 34 and the lowest priority: 

+-----+--------+---------+-------+----------+--------+ 
| id | lcr_id | rule_id | gw_id | priority | weight | 
+-----+--------+---------+-------+----------+--------+ 
| 21 | 1 | 21 | 5 | 1 | 1 | 

Is that the matching peer ? 

| 4 | 1 | 1057400 | X.X.X.X | sip05.es | 5060 | NULL | 1 | 1 | 0 | NULL | 4 | NULL | 4 | NULL | 

Daniel 

On 06/13/2014 11:42 AM, Jorge Fresneda - Ibersontel wrote: 

<blockquote>
Hi Daniel, 

lcr_gw: 

mysql> select * from lcr_gw; 
+----+--------+----------------------+----------------+--------------------+------+--------+------------+-----------+-------+------+-------+---------+----------+--------+ 
| id | lcr_id | gw_name | ip_addr | hostname | port | params | uri_scheme | transport | strip | tag | flags | defunct | group_id | prefix | 
+----+--------+----------------------+----------------+--------------------+------+--------+------------+-----------+-------+------+-------+---------+----------+--------+ 
| 1 | 1 | ESMD023 | X.X.X.X | NULL | 5060 | NULL | 1 | 1 | 0 | NULL | 1 | NULL | 1 | NULL | 
| 4 | 1 | 1057400 | X.X.X.X | sip05.es | 5060 | NULL | 1 | 1 | 0 | NULL | 4 | NULL | 4 | NULL | 
| 5 | 1 | 1057401 | X.X.X.X | sip06.es | 5060 | NULL | 1 | 1 | 0 | NULL | 5 | NULL | 5 | NULL | 
| 6 | 1 | CVIP52-0 | X.X.X.X | NULL | 5060 | NULL | 1 | 1 | 0 | NULL | 6 | NULL | 6 | NULL | 
| 7 | 1 | CVIP923-23 | X.X.X.X | NULL | 5060 | NULL | 1 | 1 | 0 | NULL | 7 | NULL | 7 | NULL | 
+----+--------+----------------------+----------------+--------------------+------+--------+------------+-----------+-------+------+-------+---------+----------+--------+ 

lcr_rule 
mysql> select * from lcr_rule; 
+-----+--------+--------+-------------------------------------+--------------+---------+---------+----------+ 
| id | lcr_id | prefix | request_uri | from_uri | stopper | enabled | group_id | 
+-----+--------+--------+-------------------------------------+--------------+---------+---------+----------+ 
| 6 | 1 | 34 | ^sip:349.+ at 12.43.54.6$ | | 0 | 1 | 1 | 
| 8 | 1 | | | | 0 | 1 | 1 | 
| 21 | 1 | 34 | ^sip:349.+ at 12.43.54.6$ | 926501080 | 0 | 1 | 5 | 
| 34 | 1 | 51 | ^sip:0051.+ at 12.43.54.6$ | 16419340 | 0 | 1 | 4 | 
| 38 | 1 | 34 | | 911111111 | 0 | 1 | 6 | 

lcr_rule_target 

+-----+--------+---------+-------+----------+--------+ 
| id | lcr_id | rule_id | gw_id | priority | weight | 
+-----+--------+---------+-------+----------+--------+ 
| 6 | 1 | 6 | 1 | 5 | 1 | 
| 8 | 1 | 8 | 1 | 5 | 1 | 
| 21 | 1 | 21 | 5 | 1 | 1 | 
| 22 | 1 | 22 | 5 | 1 | 1 | 
| 28 | 1 | 28 | 5 | 1 | 1 | 
| 33 | 1 | 33 | 4 | 2 | 1 | 
| 34 | 1 | 34 | 4 | 2 | 1 | 
| 37 | 1 | 37 | 5 | 1 | 1 | 
| 38 | 1 | 38 | 6 | 3 | 1 | 
| 42 | 1 | 42 | 5 | 1 | 1 | 
| 48 | 1 | 48 | 4 | 2 | 1 | 
| 49 | 1 | 49 | 4 | 2 | 1 | 
| 51 | 1 | 51 | 4 | 2 | 1 | 
| 52 | 1 | 52 | 4 | 2 | 1 | 
| 53 | 1 | 53 | 4 | 2 | 1 | 
| 54 | 1 | 54 | 4 | 2 | 1 | 
| 55 | 1 | 55 | 4 | 2 | 1 | 
| 56 | 1 | 56 | 4 | 2 | 1 | 
| 57 | 1 | 57 | 4 | 2 | 1 | 
| 58 | 1 | 58 | 4 | 2 | 1 | 
| 59 | 1 | 59 | 4 | 2 | 1 | 
| 60 | 1 | 60 | 4 | 2 | 1 | 
| 61 | 1 | 61 | 4 | 2 | 1 | 
| 62 | 1 | 62 | 4 | 2 | 1 | 
| 63 | 1 | 63 | 4 | 2 | 1 | 
| 64 | 1 | 64 | 4 | 2 | 1 | 
| 66 | 1 | 66 | 5 | 1 | 1 | 
| 67 | 1 | 67 | 5 | 1 | 1 | 
| 68 | 1 | 68 | 5 | 1 | 1 | 
| 69 | 1 | 69 | 5 | 1 | 1 | 
| 70 | 1 | 70 | 5 | 1 | 1 | 
| 71 | 1 | 71 | 5 | 1 | 1 | 
| 72 | 1 | 72 | 5 | 1 | 1 | 
| 73 | 1 | 73 | 5 | 1 | 1 | 
| 74 | 1 | 74 | 5 | 1 | 1 | 
| 75 | 1 | 75 | 5 | 1 | 1 | 
| 76 | 1 | 76 | 5 | 1 | 1 | 
| 77 | 1 | 77 | 5 | 1 | 1 | 
| 78 | 1 | 78 | 4 | 2 | 1 | 
| 79 | 1 | 79 | 4 | 2 | 1 | 
| 80 | 1 | 80 | 4 | 2 | 1 | 
| 81 | 1 | 81 | 5 | 1 | 1 | 
| 82 | 1 | 82 | 5 | 1 | 1 | 
| 83 | 1 | 83 | 5 | 1 | 1 | 
| 84 | 1 | 84 | 5 | 1 | 1 | 
| 85 | 1 | 85 | 5 | 1 | 1 | 
| 86 | 1 | 86 | 5 | 1 | 1 | 
| 87 | 1 | 87 | 5 | 1 | 1 | 
| 88 | 1 | 88 | 5 | 1 | 1 | 
| 89 | 1 | 89 | 5 | 1 | 1 | 
| 90 | 1 | 90 | 4 | 2 | 1 | 
| 91 | 1 | 91 | 4 | 2 | 1 | 
| 92 | 1 | 92 | 4 | 2 | 1 | 
| 93 | 1 | 93 | 4 | 2 | 1 | 
| 94 | 1 | 94 | 4 | 2 | 1 | 
| 95 | 1 | 95 | 4 | 2 | 1 | 
| 98 | 1 | 98 | 4 | 2 | 1 | 
| 102 | 1 | 102 | 7 | 4 | 1 | 
| 107 | 1 | 107 | 6 | 3 | 1 | 
| 109 | 1 | 109 | 5 | 1 | 1 | 
+-----+--------+---------+-------+----------+--------+ 

Regards, 
Jorge 

El 13/06/2014 11:22, Daniel Grotti escribió: 

<blockquote>

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: 

<blockquote>

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ó: 

<blockquote>

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: 

<blockquote>

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ó: 

<blockquote>

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" <j.fresneda at ibersontel.com> To: spce-user at lists.sipwise.com 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 Spce-user at lists.sipwise.com http://lists.sipwise.com/listinfo/spce-user 

</blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

_______________________________________________
Spce-user mailing list Spce-user at lists.sipwise.com http://lists.sipwise.com/listinfo/spce-user 

</blockquote>

_______________________________________________
Spce-user mailing list Spce-user at lists.sipwise.com http://lists.sipwise.com/listinfo/spce-user 

</blockquote>

_______________________________________________
Spce-user mailing list Spce-user at lists.sipwise.com http://lists.sipwise.com/listinfo/spce-user 

</blockquote>

_______________________________________________
Spce-user mailing list Spce-user at lists.sipwise.com http://lists.sipwise.com/listinfo/spce-user 

</blockquote>

_______________________________________________ 
Spce-user mailing list 
Spce-user at lists.sipwise.com 
http://lists.sipwise.com/listinfo/spce-user 