[Spce-user] Having an issue with Inbound Rewrite Rules for Caller

[Daniel Grotti]

Hi Bob,

I tried the Regexp on Inbound RR for caller and it works fine.

In the /var/log/ngcp/kamailio-proxy.log you should see something like that:

INFO: <script>: User-Provided CLI '12345678' taken from From-User -
R=sip:0099998888 at 10.15.20.178 ID=vvsphdtyyjnogwk at majortom
INFO: <script>: Applying caller-in domain rewrite rules on user-provided
CLI using dpid '1' - R=sip:0099998888 at 10.15.20.178
ID=vvsphdtyyjnogwk at majortom
INFO: <script>: Rewriting user-provided CLI '12345678' to '43112345678'
- R=sip:0099998888 at 10.15.20.178 ID=vvsphdtyyjnogwk at majortom


Is it possible for you to share your /var/log/ngcp/kamailio-proxy.log
file in order to debug the issue ?


Regards,
Daniel



On 07/16/2013 03:24 AM, Bob Fryer wrote:
> Hi List,
> 
> I am hoping that someone can assist. I have been looking at this issue
> for several days now before I have posted.
> 
> Rechecked all my work, checked I am using the correct regex tests etc
> etc.
> 
> After working on SIPWise for over a month now, we have a reasonable
> handle on how everything works, and the concepts.
> 
> Just to confirm the concept that this post is about, I believe that the
> Inbound Rewrite rules are the correct ones that I should be
> concentrating on at the moment. What I understand this area is for is I
> have a subscriber who has a PBX, and they are dialling a number. Once it
> reaches SIPwise, its first stage I believe is the 'Inbound Rewrite Rules
> for Caller' where it finds a match (if available) and rewrites based on
> the replacement pattern. This is to allow SIPWise to process all numbers
> as E.164 format, which includes the billing engine. Our Outbound Rewrite
> rules mainly take these now converted E.164 numbers and process them
> back to numbers that the local carrier requires to perform a connection
> to the desired phone number. Hopefully this is correct.
> 
> Basically we have most of the Inbound Rewrite Rules for Caller working
> (there plenty of great examples to work off).
> However there is one rule which does not appear to work which is the
> first rule in our list. Our rules for Inbound Rewrite Rules for Caller
> are as follows:
> 
> Match Pattern                           Replacement Pattern
> Description
> ^(\d{8})$                               ${caller_cc}${caller_ac}\1
> Local 8 Digits to E.164  (it should match 8 digits only)
> ^(0011|\+)([1-9][0-9][0-9][0-9]+)$      \2
> International to E.164
> ^0([1-9][0-9]+)$                        ${caller_cc}\1
> Australian National & Mobile to E.164
> 
> 
> Just so the above makes some sense, in Australia we have the following
> 
> The Subscriber has the CC of 61 and AC of 2
> International Calls use 0011 prefix to dial international numbers
> followed by the E164 standard
> Our Mobile numbers are 04XXXXXXXX e.g. 0414989898 or 0418909090
> National Calls have the two digit Area Code + 8 digit number e.g.
> 0299998888 or 0388889999
> In the local area (in our case area code 02, you can dial the 8 digit
> phone number 99998888
> 
> As mentioned the first rule ^(\d{8})$ does not appear to match when the
> incoming number is 99998888, it appears to fall through to our default
> billing rule as the replacement is not done which should be 61299998888
> and the number passes through as 99998888
> 
> I have tested this rule on several PCRE regex online engines and seems
> to work correctly. The one I have been using a lot is
> http://regex.larsolavtorvik.com/
> 
> With this regex pattern and replacement and an input of 99998888 in the
> online engine, I get a match and a result of 61299998888 (exactly what I
> need).
> If I provide an input of 9999888 I do not get a match and it passes
> through the 9999888
> If I provide an input of 999988888 I do not get a match and its passes
> through the 999988888
> 
> For the sake of it I also have tried a replacement pattern of 612\1 and
> also 612\0 which again also provides the same results as above
> 
> Just so I understand the Inbound Rewrite rules, the patterns are applied
> in the order that they are in the table, the first correct match (as it
> moves down the table) will then apply the replacement pattern. If there
> is no match it will continue down the table..if there are no matches it
> will perform no rewrite and pass the number through.
> 
> Can anybody assist with why this is not working, correct my
> understanding, or just offer some advice. Any is appreciated.
> Is there a log to confirm where these matches are being made. My
> understanding is that it should be written to the billing table in the
> e.164 format (providing it has been rewritten), is this correct?
> 
> Regards
> 
> Bob Fryer
> 
> 
> 
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>