[Spce-user] Rewrite rule problem
Daniel Grotti
dgrotti at sipwise.com
Fri Jun 13 06:38:26 EDT 2014
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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140613/b191d7ff/attachment-0001.html>
More information about the Spce-user
mailing list