05-14-2020 08:58 AM - edited 05-14-2020 12:58 PM
Hello everyone!
I stepped into this one recently and I'm puzzled on the fix and I would like to understand it better.
Facts:
- Call blocking based on calling party was implemented on CUCM using the “Route Next Hop By Calling Party” trick [1][2].
- Anonymous SIP Calls were being blocked by the previous change with 404 Not Found below is an example of the original INVITE.
016761: May 12 16:47:22.002: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:5130004444@199.9.8.7:5060 SIP/2.0 Via: SIP/2.0/UDP 67.1.2.3:5100;branch=z9hG4bKnkru8600a09ucbj79ql0.1 From: "Anonymous"<sip:anonymous@anonymous.invalid>;tag=1537286278-1589323641991- To: "5130004444 5130004444"<sip:5130004444@voip.sip.com;user=phone> Call-ID: BW1647219911205201184354441@10.10.10.10 CSeq: 92871236 INVITE Contact: <sip:anonymous@67.1.2.3:5100;transport=udp> Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Recv-Info: x-broadworks-client-session-info Accept: application/btbc-session-info,application/media_control+xml,application/sdp,multipart/mixed Max-Forwards: 69 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 265
The problem seems to be that -and I quote- "Cisco Unified Communications Manager digit analysis engine is not designed to match on non-numeric strings", which is understandable and the string "anonymous" it is obviously NOT numeric.
I read multiple sites about similar problems and all of them suggested a SIP normalization on the FROM header [3][4][5][6] which is what I ended up doing on the CUBE, considering most common variations.
voice class sip-profiles 1 request ANY sip-header From modify "<sip:Anonymous@" "<sip:00000000000@" request ANY sip-header From modify "<sip:Restricted@" "<sip:00000000000@" request ANY sip-header From modify "<sip:Unavailable@" "<sip:00000000000@" request ANY sip-header From modify "<sip:anonymous@" "<sip:00000000000@" request ANY sip-header From modify "<sip:restricted@" "<sip:00000000000@" request ANY sip-header From modify "<sip:unavailable@" "<sip:00000000000@"
But it did NOT work, anonymous calls where still being blocked, although I clearly saw on the call leg going to CUCM the modification being applied correctly.
016764: May 12 16:47:22.006: //3783693/603D0713A3E2/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:5130004444@10.10.10.10:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.20:5060;branch=z9hG4bK6133D11CB6 From: <sip:00000000000@anonymous.invalid>;tag=3AD06B02-3E6 ! already modified by SIP normalization. To: <sip:5130004444@10.10.10.10> Date: Tue, 12 May 2020 22:47:22 GMT Call-ID: 603D7BE5-93D911EA-A3E8EAF3-B61C7023@voip.sip.com Supported: rel100,timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 1614612243-2480476650-2749557491-3055317027 User-Agent: Cisco-SIPGateway/IOS-16.6.7 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1589323642 Contact: <sip:anonymous@10.10.10.20:5060> Expires: 180 Allow-Events: kpml, telephone-event Max-Forwards: 68 P-Preferred-Identity: "Anonymous" <sip:anonymous@anonymous.invalid> Privacy: id Session-ID: ba7740aa3613515689bb2249c650dd27;remote=00000000000000000000000000000000 Session-Expires: 1800 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 252
I noticed that the SIP headers Contact and P-Preferred-Identity contained sip:anonymous string also and it was not until I added those headers to the SIP normalization that the call worked.
voice class sip-profiles 1 request ANY sip-header From modify "<sip:Anonymous@" "<sip:00000000000@" request ANY sip-header From modify "<sip:Restricted@" "<sip:00000000000@" request ANY sip-header From modify "<sip:Unavailable@" "<sip:00000000000@" request ANY sip-header From modify "<sip:anonymous@" "<sip:00000000000@" request ANY sip-header From modify "<sip:restricted@" "<sip:00000000000@" request ANY sip-header From modify "<sip:unavailable@" "<sip:00000000000@" ! request ANY sip-header Contact modify "<sip:Anonymous@" "<sip:00000000000@" request ANY sip-header Contact modify "<sip:Restricted@" "<sip:00000000000@" request ANY sip-header Contact modify "<sip:Unavailable@" "<sip:00000000000@" request ANY sip-header Contact modify "<sip:anonymous@" "<sip:00000000000@" request ANY sip-header Contact modify "<sip:restricted@" "<sip:00000000000@" request ANY sip-header Contact modify "<sip:unavailable@" "<sip:00000000000@" ! request ANY sip-header P-Preferred-Identity modify "<sip:Anonymous@" "<sip:00000000000@" request ANY sip-header P-Preferred-Identity modify "<sip:Restricted@" "<sip:00000000000@" request ANY sip-header P-Preferred-Identity modify "<sip:Unavailable@" "<sip:00000000000@" request ANY sip-header P-Preferred-Identity modify "<sip:anonymous@" "<sip:00000000000@" request ANY sip-header P-Preferred-Identity modify "<sip:restricted@" "<sip:00000000000@" request ANY sip-header P-Preferred-Identity modify "<sip:unavailable@" "<sip:00000000000@" !
But why? It still doesn't makes sense to me. All the SIP dialing documentation I have read [7] online and books do not mentioned those fields for routing decisions and only FROM should matter, right? I just do not understand why I it started working after what I did.
Any ideas?
Thanks for reading.
05-14-2020 09:58 AM - edited 05-14-2020 10:07 AM
Have a look at this document, https://community.cisco.com/t5/collaboration-voice-and-video/blocking-calls-based-on-calling-party-id/ta-p/3113978
To handle calls with no caller id you should use a LUA script in CUCM tied to the SIP trunk for the voice gateway. Likely your method also works as well, but now you have another option to use if needed.
05-14-2020 11:36 AM
Hi Roger!
Yeah, I saw that earlier, and it is doing pretty much the same thing as what I'm accomplishing with the sip-profile on the CUBE. But my questions is not how to do it "fix it" on CUCM, but rather:
Why the call didn't work after I changed the FROM header? Why am I forced to changed the Contact and P-Preferred-Identity headers, why do they matter?
Thanks!
Rolando A. Valenzuela.
05-14-2020 01:18 PM
I can’t answer your question, but I do believe that the LUA script in the post also modifies this if I’m not wrong.
05-19-2020 09:21 AM
05-19-2020 09:59 AM
The post by Dan Keller that I referenced refer to these fields also for the LUA script and CM call routing process.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide