Hi.  Sorry if this has been asked already, but does this process end up breaking the option to block anonymous calls on the DN using the 'Reject Anonymous Calls' on the directory number page? We're using this setup to be able to block incoming calls based on the calling party number and that works great, but we have a person that keeps getting tons of spam calls from an anonymous caller and we can't seem to stop these calls using the option on the directory number page for this person.     ... View more

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.    ... View more

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 ... View more

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). ... View more

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).   ... View more

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. ... View more

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... ... View more

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... ... View more

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).   ... View more

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. ... View more

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" ... View more

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>" ... View more

Ah!   I will try that :-) ... View more

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 ... View more