Struggling with LANside inbound dial peer number manipulation

[UrbanPeasant]

I have an existing SIP service provider, through which all our calls in and out over 60 trunks work perfectly. This ITSP does not use registration or authentication and does not require us to do any header manipulation. They have been our provider for about 5 years. Having recently dropped our ISDN backup telephony service we now have a second ITSP to provide call functionality on alternate number ranges in the event the primary ITSP should fail.

The new ITSP uses registration and authentication, so our previously very simple sip-ua config ( retry invite 3 and timers trying 350) now has many more commands in it. They also require us to employ a copylist and a sip profile to modify the inbound INVITE from them in order to make inbound calls work. 

Inbound calls land on the CUBE, are picked up by the correct WANside incoming dialpeer, are matched to the correct LANside outgoing dialpeer, but only if I don't include the outbound dialpeer level sip profile command below. Calls are dropped with a 'no matching outbound dialpeer' message. If I remove the sip profile command, calls go through, but only to the trunk number as the ITSP requires header manipulation.Only the trunk registered number makes it to CUCM, no matter what number from the new range is dialled. 

The relevant config is:

dial-peer voice 16 voip
  description * INBOUND WANside *
  session protocol sipv2
  incoming called-number 44152456798.
  voice-class sip copy-list 1
  dtmf-relay rtp-nte
  codec g711alaw
  no vad

voice class sip-copylist 1
 sip-header TO

 dial-peer voice 17 voip
  description * BACKUP OUTBOUND LANside to CUCM *
  translation-profile outgoing PSTN_inbound
  destination-pattern 44152456798.
  session protocol sipv2
  session target ipv4:10.42.26.72
  voice-class sip profiles 1
  voice-class sip bind control source-interface GigabitEthernet0/1
  voice-class sip bind media source-interface GigabitEthernet0/1
  dtmf-relay rtp-nte
  codec g711alaw
  no vad

voice class sip-profiles 1
 request INVITE peer-header sip TO copy "sip:(.*)@" u01
 request INVITE sip-header SIP-Req-URI modify ".*@(.*)" "INVITE sip:\u01@\1"

voice translation-profile PSTN_inbound
 translate calling 4
 translate called 3

voice translation-rule 3
  rule 7 /^4415245\(6798.\)/ /\1/

voice translation-rule 4
  rule 1 // /8/

#test voice translation-rule 4 441524567988
Matched with rule 1
Original number: 441524567988   Translated number: 8441524567988

is-sipgw02-b18#test voice translation-rule 3 441524567988
Matched with rule 7
Original number: 441524567988   Translated number: 67988

My main question then, if the translation can be seen to be working by 'test voice translation-rule 3' then how come 67988 is not passed to CUCM, and instead only 67980 from the INVITE is passed. In what way does the translation profile we're used to using with the main ITSP not work with the sip profile demanded by the new ITSP? Is the regex for the profile incorrect?

Thanks

Nathan. 

Debug snippet

Received:
2426867: May 10 20:52:08.248: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
INVITE sip:441524567980@217.114.51.210:5060 SIP/2.0
Via: SIP/2.0/UDP 83.218.143.16:5060;branch=z9hG4bKsghogr20cg3hd7h1v2e1.1
Max-Forwards: 15
From: <sip:07814965714@87.224.0.9>;tag=B61DcrZmgZ08g
To: <sip:441524567988@83.218.143.22>
Call-ID: 76b48670-cf2e-1236-1c9d-5065f3f05b98
CSeq: 122654900 INVITE
Contact: <sip:07814965714@83.218.143.16:5060;transport=udp>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 275
X-FS-Support: update_display,send_info
Remote-Party-ID: <sip:07814965714@87.224.0.9>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1525959014 1525959015 IN IP4 83.218.143.16
s=FreeSWITCH
c=IN IP4 83.218.143.16
t=0 0
m=audio 57594 RTP/AVP 8 0 18 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
 

2426934: May 10 20:52:08.252: //-1/74C2DC6BA525/DPM/dpAssociateIncomingPeerCore:

   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=16

2427001: May 10 20:52:08.252: //-1/xxxxxxxxxxxx/SIP/Info/critical/12288/sipSPICreateNewRawMsg: No Data to form The Raw Message

   cisco-username=07814965714

   ----- ccCallInfo IE subfields -----

   cisco-ani=07814965714

   cisco-anitype=0

   cisco-aniplan=0

   cisco-anipi=0

   cisco-anisi=1

   dest=441524567980

   cisco-desttype=0

   cisco-destplan=0

   cisco-rdie=FFFFFFFF

   cisco-rdn=

   cisco-rdntype=0

   cisco-rdnplan=0

   cisco-rdnpi=-1

   cisco-rdnsi=-1

   cisco-redirectreason=-1   fwd_final_type =0

   final_redirectNumber =

   hunt_group_timeout =0

2427007: May 10 20:52:08.256: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_PROCEEDING   cisco-username=07814965714

   ----- ccCallInfo IE subfields -----

   cisco-ani=807814965714

   cisco-anitype=0

   cisco-aniplan=0

   cisco-anipi=0

   cisco-anisi=1

   dest=67980

   cisco-desttype=0

   cisco-destplan=0

   cisco-rdie=FFFFFFFF

   cisco-rdn=

   cisco-rdntype=0

   cisco-rdnplan=0

   cisco-rdnpi=-1

   cisco-rdnsi=-1

   cisco-redirectreason=-1   fwd_final_type =0

   final_redirectNumber =

   hunt_group_timeout =0

[R0g22]

I do see a second leg being created in CCAPI which tells me that an outbound dial-peer was indeed allocated. Do you have the complete logs that we can look at ?

[UrbanPeasant]

Hi Nipun,

Yes, I can always answer the call on DN 67980, because from what I can make out only the translation profile is being used on the outgoing dialpeer, the sip profile isn't being regarded first, and I don't know how to make that happen.

Debug of dialpeer all, ccsip all and ccapi all from this morning attached.

Nathan.

[R0g22]

---

@UrbanPeasant wrote:
How come 67988 is not passed to CUCM, and instead only 67980 from the INVITE is passed

---

So if you can answer the call on 67980, then what is the issue ? Is this for the same call or are we talking about two different calls ?

[UrbanPeasant]

67980 is only number I can collect a call on, I can place a call to 441524567988, but because of the sip INVITE the call will only go to 67980, the To: field isn't being looked at.

To clear things up, having spotted an error in my earlier response to you and post, I can only get calls to land on 67980, and ONLY when I remove the voice-class sip profiles 1 command from the outbound LANside dialpeer. If I include the sip profiles command, the call dies with a response from the ITSP stating that there is no matching outbound dialpeer. I can't make calls come in on the range of numbers that I need to convert to DNs. I think it's because I'm failing to successfully copy the contents of the To: field to the INVITE field. With my existing main ITSP, there is no need to manipulate the headers like this, they just send the call in with the INVITE and To: headers the same already, so all I have to do is use the translation profile to convert the full DNIS into our internal DN.

[R0g22]

Can you attach your complete config ? Also, in SIP "To" header is not used for call routing. Only the Request URI will be looked at by the IOS.

[gmgarrian]

Can you send full debugs for a failed call:

debug ccsip message

debug voip ccapi inout

[gmgarrian]

Nevermind, I see a typo in your profile:

voice class sip-profiles 1
request INVITE peer-header sip TO copy "sip:(.*)@" u01
request INVITE sip-header SIP-Req-URI modify ".*@(.*)" "INVITE <sip:\u01@\1"

Try that. You're missing the < in your modify statement.

[UrbanPeasant]

I see what you mean there. I thought I'd confirmed the config I'd been given by checking it against this link, and because I wasn't doing anything with Diversion header, but was working with the To header, I thought it was correct. I'll give it a try all the same and will update the thread. At the same time I'll put up a config and another debug.
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/118825-technote-sip-00.html

[gmgarrian]

My bad, you're absolutely right...no < needed.

This profile should work:

voice class sip-profiles 1
request INVITE sip-header TO copy "<sip:(.*)@" u01
request INVITE sip-header SIP-Req-URI modify "INVITE sip:.*@" "INVITE sip:\u01@"

The copy line needed to be "sip-header" instead of "peer-header" and then I just cleaned it up.

You can test it here with Cisco's Sip Profile Test tool:

https://cway.cisco.com/tools/SipProfileTest/

[UrbanPeasant]

Well, you're on to something there! The Diversion bit, as you say, ins't right, however, I hadn't notice that for the SIP profiles copying the To field there was one entry using peer-header and another using sip-header. What I now realise is that using 15.4(3)M6, it seems I don't need to use the copy-list command on the incoming dial peer (I was blindly following what the ITSP had told me) but having made the amendment in your post above, I can now leave the sip profile command on the outbound dial-peer and a call gets made to CUCM. So that's progress because before now, the only way I could get a call going in was by deleting that sip profile line from the outbound dial peer.
I also note that your command above has a < in it, but the Cisco doc doesn't.
I checked the commands against the link you gave me and it looks good:

INPUT
INVITE sip:441524567980@217.114.51.210:5060 SIP/2.0

OUTPUT
INVITE sip:441524567988@217.114.51.210:5060 SIP/2.0

That's exactly what I'm after.
So where this leaves me is: if I dial with the intention of reaching DN 67988, I instead reach 67980. The only number I can reach, no matter what I try to reach is 67980. So I must have a problem with config elsewhere now!

In the mean time, thanks for helping with that sip profile, I simply would never have got there myself.

[Ayodeji Okanlawon]

I had a few issues with SIP copy list a while back and I think its my configuration issues. However I just reverted to using inbound sip profiles and works great for me.

voice class sip-profiles 10
 rule 1 request INVITE sip-header To copy "sip:(.*)@.*" u01
 rule 2 request INVITE sip-header SIP-Req-URI modify "sip:.*@(.*)" "sip:\u01@\1"

voice service voip

Sip

Sip-profiles inbound

sip-profiles 10 inbound

With this, your SIP TO header is copied to your RURI before any dial-peer is matched. Now you can match your inbound and outbound dial-peer based on the new RURI.

If it doesnt work collect the following logs:

debug voip ccapi inout
debug ccsip mess
debug ccsip info
debug ccsip feature sip-profile

[UrbanPeasant]

Morning!
The last thing achieved before I went to bed last night was with the help of gmgarrian which spotted that I had a 'peer-header' command instead of 'sip-header.' Changing that enabled me to leave the sip profile command on the dialpeer and for the call to proceed inbound. Prior to that change, calls were dying on the CUBE with no outbound dialpeer being matched. But the only number being reached was the trunk number in the INVITE, no modification was taking place.

With your suggestion this morning, I've just removed the sip profile command from the dialpeer and applied the global inbound sip profile commands. I didn't want to do at first because I thought it would interfere with our existing ITSP service (I was mistaken with that, because all it's doing is copying 'To' data to 'INVITE' which makes absolutely no difference to service from our other ITSP as those fields are already the same, it's just an unnecessary step in their case, but causes no problem). 

What you suggested is what the config needed! I was looking for a way to make the sip profile be applied before the translation profile on the dialpeer. This method worked. I'd still like to be able to do the manipulation at the dialpeer level, but if that's just not going to be possible, I'll take this as a win for the inbound call.

There is a new odd behaviour - if the external caller hangs up before the call is answered, the deskphone just keep ringing, there seems to be no BYE message. The only way to clear the call is to 'answer' it and hang up. Any ideas about that?

Presently this is the config now employed (I didn't use the 'rule x' statements from your config above) and a correctly delivered inbound call is captured in the attachment:

dial-peer voice 16 voip
  description * INBOUND WANside from ITSP *
  session protocol sipv2
  incoming called-number 44152456798.
  dtmf-relay rtp-nte
  codec g711alaw
  no vad

dial-peer voice 17 voip
  description * OUTBOUND LANside to CUCM *
  translation-profile outgoing PSTN_inbound
  preference 1
  destination-pattern 44152456798.
  session protocol sipv2
  session target ipv4:10.42.26.72
  voice-class sip bind control source-interface GigabitEthernet0/1
  voice-class sip bind media source-interface GigabitEthernet0/1
  dtmf-relay rtp-nte
  codec g711alaw
  no vad

Voice service voip

  sip

    sip-profiles inbound

    sip-profiles 1 inbound

voice class sip-profiles 1
  request INVITE sip-header To copy "<sip:(.*)@" u01
  request INVITE sip-header SIP-Req-URI modify "INVITE sip:.*@" "INVITE sip:\u01@"

(edit: I see the benefit of 'rule x' now as the rule sequence is crucial for the sip profile. I've tested with and without the < character in the copy commmand '<sip:(.*)@' and it seems to make no difference at the global level.)

[Ayodeji Okanlawon · Accepted solution]

Hi,

Yes I did consider the impact on calls coming from the other ITSP but just like you figured out, I knew the TO and RURI will be the same, so there wont be any impact.

You can actually apply inbound sip profiles on dial-peer. However the downside to this is that you will have to match an inbound dial-peer first before applying the sip profile. Here is the config for matching on dial-peer

voice service voip
sip
sip-profiles inbound
!
dial-peer voice <tag> voip
voice-class sip profiles 1 inbound

Once that dial-peer is matched we will copy the To header to the RURI. You can then match an outbound dial-peer based on the new Request-URI (RURI)

The rule statement if very useful. The default behavior of SIP profiles is that when you add a new rule, it just goes to the bottom of the last rule added. It also does not check if the new entry is the same as the old one, so you could have duplicates. With the new rule statements you can choose the order you want SIP profiles matched and replace an existing one just like with voice translation rules

On the issue with phone ringing while the call is ended. Normally when a call is ended before it is answered, the party who ended the call will send a CANCEL and the other party should send a 487 Request Cancelled as the final response. A BYE is only used to end an established dialog. So we need to see the SIP traces to know what is going on. You can try and test the other way. Make an outbound call then hang up, and see if the call ends on the called party.

[UrbanPeasant]

That's it!

The config now works applying the profile to the inbound dialpeer, which is great. I've removed the sip-profile 1 inbound command from the global voice service voip section, and applied it to the inbound WANside dialpeer. That leaves us with an outbound LANside dialpeer just like all our other LANside dialpeers.

I tried to add the rule statements to the sip profile but IOS 15.4(3)M6 that we use doesn't allow it (the only voice class config commands allowed are exit, help, no, request, response) so I'll just have to keep things correctly ordered manually.

I noted also that I had a session target sip-server statement in the inbound dialpeer that I didn't need, so that's gone too.

Voice service voip
  sip
    sip-profiles inbound

voice class sip-profiles 1
request INVITE sip-header TO copy "sip:(.*)@" u01
request INVITE sip-header SIP-Req-URI modify ".*@(.*)" "INVITE sip:\u01@\1"

dial-peer voice 16 voip

 description * INBOUND WANside from ITSP *

 session protocol sipv2

 incoming called-number 44152456798.

 voice-class sip profiles 1 inbound

 dtmf-relay rtp-nte

 codec g711alaw

 no vad

voice translation-profile PSTN_inbound
translate calling 4
translate called 3

voice translation-rule 3
rule 7 /^4415245\(6798.\)/ /\1/

voice translation-rule 4
rule 1 // /8/

dial-peer voice 17 voip
description * OUTBOUND LANside to CUCM *
translation-profile outgoing PSTN_inbound
preference 1
destination-pattern 44152456798.
session protocol sipv2
session target ipv4:10.42.26.72
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
no vad

With respect to the CANCEL message, it works if I dial out, but not when dialling in. I only see a 481 message, SIP/2.0 481 Call Leg/Transaction Does Not Exist.
I put the CUBE debug and the SDL traces into Translator X but haven't quite made sense of what the problem is. I'll pull something together to post after I've had some food. In the mean time, I'm really pleased the inbound calls are working now. I've been going nuts over it for days!