[Spce-user] Rewrite rule problem
Daniel Grotti
dgrotti at sipwise.com
Fri Jun 13 08:36:18 EDT 2014
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:
> 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ó:
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/3ae61d22/attachment-0001.html>
More information about the Spce-user
mailing list