What you are writing just doesn’t make sense as if the problem was in what the service provider sent in their invite it would affect inbound calls and you’re saying that outbound now are working after they changed something. This doesn’t add up IMHO. Possibly, but just speculating, what could have been altered by the service provider is what they send in their return response for authentication for outbound calls.
On the missing response for invites sent to CM from the gateway, could it be that there is something in between these two entities, like a firewall? Assuming the obvious, have you verified that you have connectivity from the gateway to the CM nodes and the other way around?
FYI SIP registration is used in the inbound direction, not in the outbound. For that Authentication is used. For detailed information on this please have a look at this great post. Handle CUBE Registration & Authentication Like a Boss
On the topic of the value in the Invite, that is actually a phone number in the +E.164 format, but it can be that it is also what is used as the user name for the SIP circuit. That said it might be good for you to know that CM uses information in the request URI, ie the very first line in the invite to route the call to the right recipient. So if you do get something goofy there from the SP, like a name, you would need to modify that with a SIP profile to copy data from another field, likely the To field into the request URI to let CM route the call.
In the post I referenced there is a link to this site - Where UC pros belong. These are some really good gems on this site that likely should have valuable information to you.
I’m sorry, but I’m not understanding what you mean. Could you please elaborate?
About the message, I still see it.
As I wrote I’m not sure that this is your problem. Based on the shared debug output it doesn’t seem like that would be the problem. The linked to post, where the error you referenced in your last response, is discussed does not at all cover any problem with the Req-URI. It sounds like you may be out of your league on this topic. Maybe you should seek assistance from a reputable professional consultant service that specialises in Unifed Communication.
It seems like there is an issue with getting the message across here. If you look at the invite that you send to CM you can see that the Req-URI does contain the expected value.
*Feb 1 06:15:55.663: //3134/B8A192E78CFD/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:7200@172.30.2.10:5060 SIP/2.0
Via: SIP/2.0/UDP 172.30.2.9:5060;branch=z9hG4bK7D2577
Remote-Party-ID: "559903358" <sip:559903358@172.30.2.9>;party=calling;screen=no;privacy=off
From: "559903358" <sip:559903358@fmc.stc.com.sa;user=phone>;tag=3A27D84-2293
To: <sip:7200@172.30.2.10>
Date: Wed, 01 Feb 2023 06:15:55 GMT
Call-ID: B8A2CB37-A12E11ED-8D03CFAA-CF3075FD@172.30.2.9
Supported: timer,resource-priority,replaces,sdp-anat
Require: 100rel
Min-SE: 1800
Cisco-Guid: 3097596647-2704151021-2365444010-3476059645
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1675232155
Contact: <sip:559903358@172.30.2.9:5060>
Call-Info: <sip:172.30.2.9:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 24
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 337
v=0
o=CiscoSystemsSIP-GW-UserAgent 7838 2562 IN IP4 172.30.2.9
s=SIP Call
c=IN IP4 172.30.2.9
t=0 0
m=audio 16604 RTP/AVP 8 0 18 101 19
c=IN IP4 172.30.2.9
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
What you’re receiving from the service provider is not really related to this as you translate the called number to match what you have as a directory number in CM.
