CUBE incoming from SIP-SP not matching translations

[pematthe]

Baffled as to why incoming calls from SIP service provider are not matching the translation in CUBE

I have a UK number presented on the incoming CUBE SIP trunk and need to discard digits to the last 3 numbers to present to the CUCM.  The test voice translation works but it would appear that the incoming number offered by the provider is not hitting or matching the translation rule. 

Incoming dial peer config:

dial-peer voice 60 voip
 description Inbound from PSTN (Elite) to CUBE
 translation-profile incoming EliteSIP-DDI-numbers-incoming
 session protocol sipv2
 incoming called-number 44239.......
 voice-class codec 1
 dtmf-relay sip-kpml rtp-nte
 no vad

Translation profile and rule config

voice translation-rule 44239
 rule 1 /^442392006/ //
 rule 2 /^\+442392006/ //
!
!
voice translation-profile EliteSIP-DDI-numbers-incoming
translate called 44239

Translation result:

Matched with rule 2
Original number: +442392006339    Translated number: 339
Original number type: none    Translated number type: none
Original number plan: none    Translated number plan: none

BE6000S#test voice translation-rule 44239 442392006339
Matched with rule 1
Original number: 442392006339    Translated number: 339
Original number type: none    Translated number type: none
Original number plan: none    Translated number plan: none

Output of debug translation:

BE6000S#debug voice translation
VoIP Translation Rule debugging is enabled
BE6000S#
SIP: Trying to parse unsupported attribute at media level
SIP: Trying to parse unsupported attribute at media level
065139: Jun  7 23:35:29.157: //-1/5A562434A112/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x3F5552E8; count=1
065140: Jun  7 23:35:29.157: //-1/5A562434A112/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x421F2934
065141: Jun  7 23:35:29.161: //-1/5A562434A112/RXRULE/regxrule_stack_push_RegXruleNumInfo_internal: stack=0x3F5552E8; count=1
065142: Jun  7 23:35:29.161: //-1/5A562434A112/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x3F5552E8; count=1
065143: Jun  7 23:35:29.161: //-1/5A562434A112/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x421F2934
065144: Jun  7 23:35:29.161: //-1/5A562434A112/RXRULE/regxrule_stack_push_RegXruleNumInfo_internal: stack=0x3F5552E8; count=1
065145: Jun  7 23:35:29.165: //-1/xxxxxxxxxxxx/RXRULE/sed_subst: No match! number= matchPattern=id; |[; ]*id$ replacePattern=
065146: Jun  7 23:35:32.157: //-1/5A562434A112/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x0
065147: Jun  7 23:35:32.169: //-1/5A562434A112/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x3F5552E8; count=1
065148: Jun  7 23:35:32.169: //-1/5A562434A112/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x421F2934

Debug from ccsip messages just to be sure the call it coming in and the DNIS format (btw - which bit of the trace show the DNIS?)

BE6000S#debug ccsip messages
SIP Call messages tracing is enabled
BE6000S#
065149: Jun  7 23:38:16.925: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+442392006339@172.27.199.1:5060 SIP/2.0
Record-Route: <sip:217.68.246.241;ftag=as6b74b830;lr;did=e7c.5d92>
Via: SIP/2.0/UDP 217.68.246.241:5060;branch=z9hG4bKe4be.24390fd700572c75f3247fa6444e9fcc.0
Max-Forwards: 16
To: <sip:+442392006339@217.68.246.241:5060>
From: <sip:+447730711187@217.68.246.241>;tag=as6b74b830
Call-ID: 707a7b4e0c48ebd1476ea13953b13998@217.68.246.241:5050
Contact: <sip:+447730711187@217.68.246.241:5060>
CSeq: 102 INVITE
User-Agent: Elite Hosted Voice
Date: Tue, 07 Jun 2016 23:38:14 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
X-voipnow-did: +442392006339
X-voipnow-extension: 0071*001
X-voipnow-pbx: 3a5b131e3e
X-voipnow-infrastructureid: 92f21508
X-voipnow-did: +442392006339
Content-Type: application/sdp
Content-Length: 520

Ideas? 

[Deepak Mehta · Accepted solution]

Dear Pem,

I believe if you add + to incoming called number it should resolve the problem as provider is sending with +.

Incoming called number +44239........

Also run debug voip dialpeer to see which dial-peer is getting matched on inbound direction from ITSP.thanks

[Tristan Cober]

I'm fairly certain that you hit the dial-peer before a translation rule takes effect.

Edit:

This is from CVOICE 8.0:

[Dennis Mink]

That is correct, once a dial peer is hit, it then applies the translation rule that is configured on THAT dial peer

[Dennis Mink · Accepted solution]

Your invite comes in as

+442392006339

yet your dial peer 60 is configured as:

incoming called-number 44239.......

so i bet if you were to debug your dial peer, you would see that 60 is not getting hit and hence the translation is not getting hit,

[pematthe]

Perfect.... I added the + and the matching / translation happened and all is good!  Thanks for the prompt response.