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

[Rodrigo Garcia]

First thing to check would be if your incoming calls are in fact coming through your dial-peer 100. Run a debug voice ccapi inout and verify the incoming dial-peer for the incoming call leg.

[voip7372]

Ok, I can check/verify that but there shouldn't be any other way the call can come in and be considered 'inbound' with the +1.......... pattern.  We only have 4 dial peers to handle the incoming and outgoing calls and two of those dial peers don't have patterns that match the other two dial peers.  I have the dial peer I showed in the first post as the incoming dial peer (incoming called number) from the service provider on that interface and one more dial peer with the same type of pattern (+1..........) that's an 'outgoing' dial peer (destination pattern) to send the call to the internal interface to get to CUCM.  The other two dial peers have patterns that start with 9 and those come from CUCM.  One dial peer for incoming calls from CUCM and one out to the service provider (I strip the 9 before it goes to the provider of course).  Anyway, that's the basic setup of the dial peers.  

[Anthony Holloway]

Since inbound SIP Profiles are supposed to be used before dial-peer matching, it's possible you are not able to use this as you're thinking. Try moving your sip profile from the dial-peer to the global voice service voip > sip section instead.

[voip7372]

Ah!   I will try that :-)

[voip7372]

Ok I tried that too and it doesn't work.  Actually, applying the SIP profile as an inbound profile DOES work, but not if I'm trying to edit the From header.  I can assign the inbound SIP profile to dial peer 100 and mark it as an inbound SIP profile there and change the P-Asserted-Identity but for some reason it just doesn't work (it's ignored/SIP message not changed) if I target the From header.  I don't understand why it won't work if I'm trying to edit the From header, but it works fine if I target the P-Asserted-Identity header.  Any ideas?

Works in router:
request ANY sip-header P-Asserted-Identity modify "<sip:+(.*)@172.16.100.2:5060>" "<sip:18585551212@172.16.100.2:5060>"

Does not work in router (but it works on the Cisco SIP profile test tool):
request ANY sip-header From modify "<sip:+(.*)@172.16.100.2:5060>" "<sip:+18585551212@172.16.100.2:5060>"

[Rodrigo Garcia]

Why don't you try 

request ANY sip-header From modify "<sip:(.*)@172.16.100.2" "<sip:+16145551212@172.16.100.2"

[voip7372]

I tried that and it still doesn't work.  It's strange because it works fine if I use the P-Asserted-Identity header as what I want to change, but if I use the From header, it doesn't work in the router (it's as if it's ignoring it).  It works in the SIP profile test tool though (Cisco's web site).  

Works in router:
request ANY sip-header P-Asserted-Identity modify "<sip:+(.*)@172.16.100.2:5060>" "<sip:+16145551212@172.16.100.2:5060>"

Dos not work in router (only thing different is the header to modify):
request ANY sip-header From modify "<sip:+(.*)@172.16.100.2:5060>" "<sip:+16145551212@172.16.100.2:5060>"

I also checked Cisco's web site for more examples and I tried this one in the SIP profile test tool and it works perfectly fine (the SIP message is changed to what I want), but again, it just won't work in the router:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-param-mod.html

Cisco's example from their web site:
Modify the From Field of a SIP INVITE Request Messages to “gateway@gw-ip-address” Format
For example, modify 2222000020@10.13.24.7 to gateway@10.13.24.7
request INVITE sip-header From modify "(<.*:)(.*@)" "\1gateway@"

My example that works in the SIP prpfile test tool, but NOT on the actual router:
request INVITE sip-header From modify "(<.*:)(.*@)" "\116145551212@172.16.100.2:5060"

[Rodrigo Garcia]

Probably you have already tried different patterns but if you are trying with request ANY sip-header From modify "<sip:+(.*)@172.16.100.2:5060>" "<sip:+16145551212@172.16.100.2:5060>" then it won't work as the SIP profile will look for the string "<sip:+(.*)@172.16.100.2:5060>". Note I highlighted 5060 and the FROM header string pattern does not contains the SIP port on the address so it will never match:

From: <sip:+18585551212@172.16.100.2;isup-oli=0>;tag=gK00685304

[voip7372]

Yep.  I was thinking about that too but I do see the port in the incoming invite so I used that as part of my entry.  I see your point though and if I ever do get this to work, I may shorten it as much as possible so we don't run into that problem if for some reason they ever don't send the port number.  Currently, I do see the port number on all the incoming invites from this provider.

EDIT:  Sorry, I read your reply too quickly and missed that you were pointing out that the port is not in the From header.  I probably keep the port in my head because I was trying to use the PAI example that was working fine and the PAI header does have the port number in it (but not the From header).  

[Anthony Holloway]

That's good thinking, to test that way.

However, it looks like you would not be able to simply swap out the header name and have it still work, since your header values are formatted slightly different.

Your From looks like this:

From: <sip:+18585551212@172.16.100.2;isup-oli=0>;tag=gK00685304

Your PAI like this:

P-Asserted-Identity: <sip:+18585551212@172.16.100.2:5060>

Your match pattern looks like this:

"<sip:+(.*)@172.16.100.2:5060>"

Notice that in your From there is no port at the end of the address.  Therefore you would need to change your match to be

"<sip:+(.*)@172.16.100.2:5060"

And quite frankly, the parenthesis are doing nothing for you, so just drop them, and then your replace pattern needs to change too (else you're adding an unintentional greater than sign (>) to the header):

request INVITE sip-header From modify "sip:.+@172.16.100.2" "sip:+16145551212@172.16.100.2"

Note that I also took out the < before sip, as it just extra and not needed.  also your + prefix was actually saying "one or more colons (:)" and lastly, your .* was potentially going to match nothing, since * is "zero or more", whereas + is "one or more"

That should also work for PAI as well now too, just in case you wanted to swap back and forth again for testing:

request INVITE sip-header P-Asserted-Identity modify "sip:.+@172.16.100.2" "sip:+16145551212@172.16.100.2"

[voip7372]

Oops...you're right (and the other person mentioned it and I overlooked that..,the port number is not in the From header).

Let me try your example now...

[voip7372]

I'll work on this again in the morning (or later this evening).  I don't have enough time today to test it for the next several hours...

[voip7372]

I did some more testing this morning and it appears the profile is (correctly) modifying the message that comes right after the initial invite (the SIP/2.0 100 Trying message).  I tried applying the profile as an inbound profile globally in voice service > sip and also on the incoming dial peer where the call first enters.  In both cases the From header is modified but after the initial invite (the From header in the SIP/2.0 100 Trying message) and then after the SIP/2.0 100 Trying message where the From was modified, it goes right back to the original number in the next invite message.  Is it possible taking the number in the PAI header (which is still the original number) and inserting that as the number in the next invite message's From header?  If it's somehow using the PAI from the previous SIP message to create the next Invite, then this isn't going to work for me.  I thank you and the other person for the help/advice.

The reason I'm trying to do this is because we get incoming calls from two sources on the same interface (our PSTN service provider and our call center service provider).  In some scenarios we have calls coming in from the call center that don't have one of our owned phone numbers from the PSTN provider.  If we try to send those calls back out to the PSTN they will be blocked since the calling party number is not a number we own.  The idea I had was to change the From header only for calls coming from our call center provider's IP address and hope that would be enough to have the call accepted by our PSTN provider.  The PSTN provider has this priority (this order) for what they check to see if a call is allowed to call out (check the calling party number to see if it's one of theirs/ours):

1. Diversion header

2. P-Asserted-Identity header

3. From or Remote-Party-ID header

I can't change the diversion header or add a diversion header for the incoming calls because that creates many problems.  I can't use the P-Asserted-Identity header because that causes the caller-id to always appear to be coming from the number I put in the PAI header.  So finally, I was hoping the From header would work to get the PSTN to accept the call (the last header they check for a valid number) while not interring with billing, CDR or the caller-id we need to show to the outside party.  It's a bit of a complicated situation.  We might have to solve it on the call center side with some manipulations on that side, but I don't have control over that part of it so I was trying to see if I could solve this with CUBE in the meantime.

By the way, this is the profile that works for me either in the dial peer or the voice service voip > sip area as a global entry (but like I said, it changes the message after the first invite but the number goes back to what it was in the next invite, so it's not helpful to me for what I need):

request INVITE sip-header From modify "<sip:(.*@172.16.100.2)" "<sip:+16145551212@172.16.100.2)"

I also tried 'request ANY' but got the same result as using 'request INVITE'

The SIP profile test tool like that entry too.  Just too bad it's ultimately not behaving the way I'd like it to.

[Rodrigo Garcia]

I'm having a hard time trying to understand your call flow, can you please provide the call flow and examples of the SIP messages already modified and/or the messages that you want to be changed? For example the first Invite, Trying and the message that "goes right back to the original number in the next invite message".