[Spce-user] Rewrite rule problem

Daniel Grotti dgrotti at sipwise.com
Fri Jun 13 06:54:40 EDT 2014


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:
> And which peer will match ?
>
>
>
>
>
>
> On 06/13/2014 12:32 PM, Jorge Fresneda - Ibersontel wrote:
>> 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ó:
>>> 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:
>>>> 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ó:
>>>>> 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:
>>>>>> 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ó:
>>>>>>> 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:
>>>>>>>> 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ó:
>>>>>>>>> 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
>>>>
>>>
>>
>
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140613/95d6f6e2/attachment-0001.html>


More information about the Spce-user mailing list