11-22-2023 07:57 AM
Hi All
I need to modify sip invite message with cucm normalization script for incoming calls from sip trunk
the original invite massage is
INVITE sip:+972765321800@192.117.120.131:5060 SIP/2.0
To: < sip:+972765014007@192.117.120.131:5060>
i need to modify the called number so the new INVITE massage will be
INVITE sip:+972765014007@192.117.120.131:5060 SIP/2.0
Regards
11-23-2023 05:52 AM
Why does it have to be done as SIP normalisation? If all you're concerned with is the called number you could use a Translation Pattern to match +972765321800
11-23-2023 07:33 AM
i sorry i didn't explain my self good enough
I am facing a problem with sip provider connect direct to the cucm (this is new topology we test )
the request URI Header in the INVITE massage is the main registration number +972765321800 instead the DID +972765014007
for example
incoming call to +972765014007
the INVITE massage look like this
INVITE sip:+972765321800@192.117.120.131:5060 SIP/2.0
the cucm try to collect the number from the request URI field and this is way I cant route the number +972765014007 to extension
the right number found in the "TO:" header
"To: < sip:+972765014007@192.117.120.131:5060> "you can see in the image
as i know the only way i can fix it is with sip normalization
i need normalization script
the first parameter is always orignumber = "+972765321800"
this parameter need to replace with this parameter didnumber = "+972xxxxxxxxx"
in the end i need to modify the request URI Header and change the parameter from orignumber to didnumber
the new invite massage after the normalization script >> INVITE sip:+972xxxxxxxxx@192.117.120.131:5060 SIP/2.0
i try some scripts from the internet but it didn't work
there are two cucm servers 192.117.120.131 and 192.117.120.132
thank you hop I explain my self good
thanks
11-23-2023 10:05 AM
Not an answer to your question, but it’s strongly recommended to not have a service provider SIP trunk that directly connects to CM. This is for many reasons directly inappropriate, one being that your service provider will have full access to your internal network where you have phone devices and clients. It’s strongly recommended that you use a SBC to serve as a demarcation point between your business network and the service provider. You can use pretty much any Cisco router for this and use the Cube functionality in it to have it act as an SBC. With an SBC you’ll get a lot more flexibility in how you can modify the SIP dialogue.
11-24-2023 01:35 AM
you are absolutely right
in this case there is VRF connection between the provider and the cucm
and in the front of the provider there is SBC
thank you very much for the help
we fix the problem with manipulation on the SBC
11-24-2023 02:54 AM - edited 11-24-2023 02:56 AM
Great that you have found a solution, but if you have an SBC in between CM and the SP then why did you say that you had a directly connected SIP trunk? Or is it not your SBC, but the SPs? If so this would not make much difference to what I wrote as far as to the security aspect. The SP would still have full access to your business network and that’s definitely not recommended.
11-23-2023 10:34 AM
OK got it. We had to do this for a trunk from Tata in India, the SIP URI always gave the pilot number. But we had a CUBE as the gateway, so was done with SIP profiles using "copy" as already posted.
11-23-2023 08:55 AM - edited 11-23-2023 08:57 AM
Edit: Apologies, I just realized that you are talking about call manager as it is the provider directly connected to cucm. Please ignore this post. Let me see if i can delete the post
Hi there,
You may be able to use something like the following and call this on your dial peer
voice class sip-profiles 100
rule 10 request INVITE sip-header TO copy “<sip:(.*)@” u01
rule 11 request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:\u01@\1"
Rule 10: Copies the content inside the <sip:(.*)@ portion of the "To" header field to the variable u01.
Rule 11: Modifies the SIP Request-URI in the INVITE message, replacing the content before the "@" with u01. This effectively changes the user part of the Request-URI.
I couldn't test it now, and unfortunately, the Cisco SIP profile test tool is also giving me an error to test the profile. You may be able to use the tool to test your SIP profile rule
Tool Link: https://cway.cisco.com/tools/SipProfileTest/
Regards,
Disclaimer:
Responses are based on personal knowledge and experience. Consider them as guidance. Other members may offer different perspectives or better approaches. No responsibility is assumed for outcomes; discretion is advised.
11-23-2023 02:10 PM
Hi
To normalize a SIP message within the CUCM, you need to add a normalization script using LUA.
you can find some useful example here.
HTH
Regards
Carlo
11-24-2023 01:55 AM
thank you very much as you see in the old post we already fix the problem from the SBC
but for learning i what to try and fix this issue with normalization script
local oldsiprquast =msg:getHeader("SIP-Req-URI") >> this is the command to add the sip request header to parameter "oldsiprquast" ?
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