cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

350
Views
5
Helpful
22
Replies
Enthusiast

Re: SIP profile for inbound messages not working

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

Enthusiast

Re: SIP profile for inbound messages not working

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

VIP Advisor

Re: SIP profile for inbound messages not working

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?


Anthony Holloway

If you found this post helpful, please consider clicking that helpful button!

And for a limited time, by marking helpful posts, you're also helping Doctors Without Borders
Enthusiast

Re: SIP profile for inbound messages not working

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. 

 

VIP Advisor

Re: SIP profile for inbound messages not working

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.

Anthony Holloway

If you found this post helpful, please consider clicking that helpful button!

And for a limited time, by marking helpful posts, you're also helping Doctors Without Borders
Enthusiast

Re: SIP profile for inbound messages not working

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

Enthusiast

Re: SIP profile for inbound messages not working

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

Enthusiast

Re: SIP profile for inbound messages not working

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.

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here