SIP profile for inbound messages not working

[voip7372]

I need to look for a specific IP address in the FROM header and change the phone number in that header to a different number.
In the example below, I enabled the inbound SIP profiles feature, created a new SIP profile to use for the inbound messages and assigned that to the dial peer where the calls are first entering our router.

I have another example of an inbound SIP profile that is actually working on the same router (4351) but for some reason this new SIP profile just isn't working. If I test my SIP profile on the Cisco SIP profile test web site, it works. https://cway.cisco.com/tools/SipProfileTest/ Using Cisco's web site for testing SIP profiles, the profile correctly finds the IP address in the example SIP message (a real SIP message from our router) and it correctly edits the phone number. However, when I add this config to our router and test it on live calls, it's not working. It's like it's just ignoring the SIP profile and not applying the changes I want.

Any idea way it wouldn't work?

Enable inbound SIP profiles feature:
voice service voip
sip
sip-profiles inbound

Create a SIP profile to be used for inbound SIP messages:
voice class sip-profiles 2
request INVITE sip-header From modify "<sip:+(.*)@172.16.100.2" "<sip:+16145551212@172.16.100.2>"

Assign the new SIP profile for changing inbound SIP messages to the incoming dial peer where the calls are entering that we want to change:
dial-peer voice 100 voip
description INCOMING CALL FROM SERVICE PROVIDER
session protocol sipv2
session transport udp
incoming called-number +1..........
voice-class codec 1
voice-class sip profiles 2 inbound
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
fax rate 14400
fax protocol t38 fallback none
no vad

This is a real SIP message from our router, but I changed the IP addresses and numbers so I don't have to show that in public. In the example below, I want to look for an incoming INVITE SIP message with an IP address of 172.16.100.2 in the FROM header. In this example, the number in the FROM header is +18585551212 and I want to replace that (or ANY other number that appears there) with +16145551212.

INVITE sip:+17145551212@172.17.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.100.2:5060;branch=z9hG4bK00B4b0fa14d04860213
From: <sip:+18585551212@172.16.100.2;isup-oli=0>;tag=gK00685304
To: <sip:+17145551212@172.17.200.2>
Call-ID: 39872468_58128682@172.16.100.2
CSeq: 823771 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REFER,INFO,NOTIFY,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:+18585551212@172.16.100.2:5060>
P-Asserted-Identity: <sip:+18585551212@172.16.100.2:5060>
X-InContact-AgentId: 11291035
X-InContact-ContactId: 96631343283
X-InContact-BusNo: 4598220
X-InContact-CallType: AgentLegDefault
X-InContact-Originating-Device: fra-e31med03
X-InContact-DcasRouteGroup: eunbs_clk1
Supported: timer,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 286
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 33549 965570 IN IP4 172.16.100.2
s=SIP Media Capabilities
c=IN IP4 172.16.100.3
t=0 0
m=audio 52998 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

[voip7372]

I have to join a meeting soon but I'll get the call flow basics for you after the meeting and also some of the real sip messages (2 invites and a 'trying' between the invites).  I didn't save the entire flow of messages from my last test since the messages were already not what I wanted after the 2nd message (SIP/2.0 100 Trying).  

[voip7372]

OK...

inContact agent call from cloud to our CUBE on gi0/0/1 (which is also the interface for our incoming/outgoing Verizon PSTN calls) > CUBE sends call to CUCM as +E164 type number (on gi0/0/0) > CUCM either matches the call to an internal ext or sends it back to CUBE for PSTN access > CUBE receives the call from CUCM with a 9 in front and we strip the 9 and send the call to Verizon via interface gi0/0/1 

Here are 3 SIP messages from CUBE.  I edited the messages to replace the real numbers and IPs with something else so I don't have to show that publicly, but otherwise these are the real messages.  You can see in the 2nd message ('Trying' SIP message, the number is correctly changed in the From header, but then in the 3rd SIP message (invite to CUCM) the From header is back to what it was before the SIP profile changed it, so it won't do us any good.

This is the SIP profile entry I used to change the number in the From header:  request INVITE sip-header From modify "<sip:(.*@172.16.100.2)" "<sip:+16145551212@172.16.100.2"

INVITE sip:+17145551212@172.17.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.100.2:5060;branch=z9hG4bK08Baca916c01f3e57ec
From: <sip:+18585551212@172.16.100.2;isup-oli=0>;tag=gK084727e6
To: <sip:+17145551212@172.17.200.2>
Call-ID: 86572685_91916203@172.16.100.2
CSeq: 50019 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REFER,INFO,NOTIFY,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:+18585551212@172.16.100.2:5060>
P-Asserted-Identity: <sip:+18585551212@172.16.100.2:5060>
X-InContact-AgentId: 11291035
X-InContact-ContactId: 96861296824
X-InContact-BusNo: 4598220
X-InContact-CallType: AgentLegDefault
X-InContact-Originating-Device: fra-e31med03
X-InContact-DcasRouteGroup: eunbs_clk1
Supported: timer,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 287
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 482556 954673 IN IP4 172.16.100.2
s=SIP Media Capabilities
c=IN IP4 172.16.100.3
t=0 0
m=audio 36786 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

Sep 25 10:32:10.501: //682387/90B953E7BB40/SIP/Msg/ccsipDisplayMsg:

Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.100.2:5060;branch=z9hG4bK08Baca916c01f3e57ec
From: <sip:+16145551212@172.16.100.2;isup-oli=0>;tag=gK084727e6
To: <sip:+17145551212@172.17.200.2>
Date: Wed, 25 Sep 2019 10:32:10 GMT
Call-ID: 86572685_91916203@172.16.100.2
CSeq: 50019 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.5.3.S7a
Content-Length: 0

Sep 25 10:32:10.504: //682388/90B953E7BB40/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+17145551212@146.122.5.38:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.200.2:5060;branch=z9hG4bK6AAAD1A93
From: <sip:+18585551212@172.18.200.2>;tag=2EAE60C8-25D4
To: <sip:+17145551212@146.122.5.38>
Date: Wed, 25 Sep 2019 10:32:10 GMT
Call-ID: 90B9F00F-DEB611E9-BB468F06-31F856C@172.18.200.2
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2428064743-3736474089-3141570310-0052397420
User-Agent: Cisco-SIPGateway/IOS-15.5.3.S7a
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1569407530
Contact: <sip:+18585551212@172.18.200.2:5060>
Expires: 1800
Allow-Events: telephone-event
Max-Forwards: 69
P-Asserted-Identity: <sip:+18585551212@172.18.200.2>
Privacy: none
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 293

v=0
o=CiscoSystemsSIP-GW-UserAgent 721 9883 IN IP4 172.18.200.2
s=SIP Call
c=IN IP4 172.18.200.2
t=0 0
m=audio 22524 RTP/AVP 0 18 101
c=IN IP4 172.18.200.2
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

[Anthony Holloway]

I find three things interesting here:

1) You're sending the call from inContact to CUCM first, then back to CUBE, then to VzB, and therefore you could be solving this with a more powerful Lua script in CUCM. You may need to turn on header passing in CUBE though, so you can key off of those X-InContact-xxxxx headers.

2) CUBE seems to be constructing it's own From header value, based on the intact P-Asserted-Identity. I wonder if you can affect this with a config change on CUBE. Outside of course of just overwriting it with yet another SIP profile.

3) Wouldn't you think that if you leave the PAI header intact, with a "bad" number in it, that VzB will see it and reject the call anyway? I would think they wouldn't only look to the From if the PAI header was missing ,not if it fails validation.

This part here that you said:

"We do already insert a diversion header for some other types of calls to get around a few limitations we have for other types of calls, not related to the call center setup. That's for something else and it's for changing an outgoing SIP message right before it hits Verizon (insert diversion header with one of our real numbers). For example, they want to show the support line toll free number as the calling party number when they call customers. That's just an example of something we already do."

Why can't you do that for the inContact calls too? Seems to be working for you, correct?

[voip7372]

1. I was just trying to keep it as simple and visible as possible and also being able to more easily restrict any unknown numbers from calling back out to the PSTN (if it came in first FROM inContact which uses the same router interface our PSTN is using).  I only allow known numbers to call back out in CUCM with some 'route next hop by calling party number' translation rules and a special CSS.  I'd like to avoid using scripts in CUCM if possible.  

2. That's what it seems like to me...CUBE rebuilding the next message the way it thinks it should be based on the previous invite.

3. Yes, you're right.  In my deep thought on this I probably zoned out and forgot about that :-)...the fact that if Verizon is going to use the PAI as a higher priority than the From header, maybe it would try to use that and reject it.  OR...my hope was (I guess) that it would check for diversion and not see one, then move on to PAI and not see a Verizon number there and finally check the From header as a last resort to authenticate the call.  I think that's where I was going with this originally.  Trying to trick it into accepting the caller-id we want to show with the PAI and then accept the call based on the number in the From header.

Regarding just inserting a diversion header on the incoming calls from inContact, that does work and I tried it, but it causes lots of problems with other things like voice mail.  For example, if the call from inContact needed to ring an internal party and forward to voice mail, CUCM was not overwriting the diversion header I inserted on CUBE and it was using that number as the diversion number which of course was wrong and therefore voice mail was not answering with the correct mailbox. 

We're still waiting on the other group we're working with to see if they can manipulate the SIP messages before they get to us/CUBE and that might help us...or maybe not.  Still waiting to see what options they have.  Ultimately if we have to move ahead with this (it's just in testing phase right now but will need to be live soon), we can tell them (the agents) they will need to show one of our numbers in order to complete the calls correctly.  I understand their desire to show some other number we don't own, like someone's home office number, etc...but depending on the final config, it might just be something we can't do. 

[Anthony Holloway]

Why are you inserting those random parenthesis in there? They are not needed.

Also, I'm not quite sure I follow what you are saying about where it is and isn't working. I would help, me at least, if you also posted the SIP messaging.

Lastly, am I understanding you correctly here: You have calls coming into CUBE from your Call Center, which need to be routed to the PSTN through your provider, but the provider is rejecting the call because of the source phone number? Therefore, you're trying to spoof the call, as if it came from a real DID associated to the PSTN SIP trunk?

If so, then I would question/verify the From validity for doing this. I have worked on several major SIP provider implementations, and they all just about always claim one thing, but then only support another: Diversion header. Just for testing, you could try adding a Diversion header.

[voip7372]

Parenthesis:  I may have been confused about when the ( ) is needed so in my case it was there but didn't affect the output (it worked to change the message I wanted).   I already tried your example and it worked to change the message.  I think I had that in my mind because of another example we're already using and I think (I could be wrong) you had to use (.*) after a + to make it work right.  For example, to look for any number after the + sign (a +E164 type number), we used this (not our real IPs and numbers, just an example): request ANY sip-header P-Asserted-Identity modify "<sip:+(.*)@172.16.100.2:5060>" "<sip:+18002422121@172.16.100.2:5060>"

It's difficult to just paste in the debugs here and I could, but I don't want our IP addresses, the service providers addresses and phone numbers to be shown so I would have to manually edit the debug before posting it and that can be pretty tedious.

"Lastly, am I understanding you correctly here: You have calls coming into CUBE from your Call Center, which need to be routed to the PSTN through your provider, but the provider is rejecting the call because of the source phone number? Therefore, you're trying to spoof the call, as if it came from a real DID associated to the PSTN SIP trunk?"

Yes the call comes from our call center (inContact) on the very same interface that we receive incoming PSTN calls (Verizon).  It's part of what Verizon calls VCC (virtual call center). The agents sometimes need to make external calls and they use our CUCM/Verizon SIP trunks for that.  So the call comes from inContact to CUBE on gi/0/01 > CUCM > Verizon via CUBE on interface gi0/0/1.  It's as you said, we sometimes need to spoof the number behind the scenes for legitimate calls from these agents that use our CUBE/CUCM for PSTN access instead of inContact trunks (they chose not to buy PSTN access from inContact).  

We do already insert a diversion header for some other types of calls to get around a few limitations we have for other types of calls, not related to the call center setup.  That's for something else and it's for changing an outgoing SIP message right before it hits Verizon (insert diversion header with one of our real numbers).  For example, they want to show the support line toll free number as the calling party number when they call customers.  That's just an example of something we already do.  The thing I was asking about for this discussion was changing an incoming message, not outgoing.  My hope was that I could insert a real number we own in the 'from' header since that's the lowest priority Verizon looks for to authenticate the call and I was hoping the PAI header would be used as the caller-id.  It's just something I was trying to do as a workaround but maybe it's not possible.  It looks like the CUBE is changing the 'From' header back to what the number it was on the next Invite.  So, Invite (number is not what we want so I change it via SIP profile) > SIP Trying message with correct number in the From header (what the profile changed it to) > Invite to CUCM (somehow changed back to the number from the original incoming Invite...I assume CUBE does that for some reason).

[voip7372]

Looks like it's hitting the dial peer I expected.  These are the first two bits of info that was generated from my incoming call.  It's hitting dial peer 100 as expected.   I put X's in place of the IP addresses and phone numbers below, but otherwise this is the real output from my test call.

Sep 24 15:19:08.756: //-1/7D30C98483CE/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=+1xxxxxxxxxx
----- ccCallInfo IE subfields -----
cisco-ani=sip:+1xxxxxxxxxx@X.X.X.X;isup-oli=0
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=sip:+1xxxxxxxxxx@X.X.X.X:5060
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
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

Sep 24 15:19:08.758: //-1/7D30C98483CE/CCAPI/cc_api_call_setup_ind_common:
Interface=0x7F49F31FE060, Call Info(
Calling Number=sip:+1xxxxxxxxxx@X.X.X.X;isup-oli=0,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=sip:+1xxxxxxxxxx@X.X.X.X:5060(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=100, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=675021

[voip7372]

I'm starting to wonder if this is a bug since it works perfectly fine for the P-Asserted-Identity header, but not for the From header.  With the SIP profile applied to my incoming dial peer, it works great if I want to change the P-Asserted-Identity header, but it totally ignores it if I try to change the From header.

[NavreenaGill]

I have exactly same issue.  I am not able to change the "From field" using SIP profile on the initial invite. It works fine for P-Assterted-Identity and even To. How were you able to fix the issue?

[voip7372]

Not sure if this is what you're looking for...It's been awhile and I don't think I need that original idea anymore but I do use this for an inbound profile to change the anonymous in the caller-id of a call and replace it with 0000000000 so it's easy to filter calls in CUCM by calling party number.  We can then choose to accept those anonymous calls or block them in CUCM.  Anyway, here's my basic config in CUBE for that...

Enable it:

voice service voip

sip

sip-profiles inbound

Add the rule:

voice class sip-profiles 2
request ANY sip-header From modify "<sip:anonymous@" "<sip:+00000000000@"

Apply to inbound dial-peer:

dial-peer voice 100 voip
description INCOMING CALL FROM VERIZON WAN
session protocol sipv2
session transport udp
incoming called-number +T
voice-class codec 1
voice-class sip profiles 2 inbound
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
fax rate 14400
fax protocol t38 fallback none
no vad