problems using Regex in sip calls

[snorri.kristjansson]

I have a problem with a search rule that I use to prefix numbers and send them to CUCM. I am using 9 as a prefix for calls made to landlines and mobiles so basicly anything that starts with 90 and is only numbers will be prefixed with 31 and sent to the CUCM:
LocalZone
Alias pattern match
Regex
(90\d{5,20})@domain.com(.*)
Replace
31\1@10.1.1.1
To CUCM

This works fine as long as the call is H.323 and interworked to SIP showing 90****. But if I call from a SIP endpoint the number will show as sip:90***** the rule does not work anymore. Any good ideas?

Sent from Cisco Technical Support iPad App

[Justin Ferello]

Snorri,

Should the 90 be included in the final 'replace string'?  So you would have 31+90+1+number or should it be 31+1+number?

Thanks,

Justin

[adimchev]

Hi Snorri, the regex seems to be correct so it must be other reason. Could you start diagnostic log level DEBUG and place the call again.

Also please let me know how are you dialing out from the calliing system - what is the default call protocol? are you dialing from CLI?

Once you get the log file please post it here.

[snorri.kristjansson]

Well it behaves diferently depending on the defoult call setup. Lets say I wnat to call a Uk mobile phone the number would be something like 07712 123456 If the endpoint is set to h.323 defoult I dial the prefix then the number so 907712123456 there is a trans action that adds @domain.com. 907712123456@domain.com fits the patren and is changed to 31907712123456@10.1.1.1 and sent to the CUCM as sip:31907712123456@10.1.1.1. It is happy and routs the call out. They only downside here is that I don't get CLI.

If I have the defoult set to SIP I dial the number but I get sip:907712123456@domain.com. This does not fit the rule so I don't get the 31 nor @10.1.1.1 but for some reason it still tries to send sip:907712123456@domain.com to the CUCM and the call fails.
The SIP call will actally send CLI and that is why I am keen on getting it to work.


Sent from Cisco Technical Support iPad App

[gubadman]

You could try putting the following at the start:

(?:sip:)?

That should be a non captured group looking for sip: which is also optional. Then keep everything else the same


Sent from Cisco Technical Support iPhone App

[Martin Koch]

maybe by posting some more info like the search details/call history of the successful and the failed call, the search and transform rules, info about your deployment... could help.

I agree with Andrey, in theory (which can be overruled by your deployment), the search rule looks ok, as well for

a sip: call. So there might be something else what fails here.