Incoming calls show "unknown number" on IP Phone

[sgqjt0001]

Hi,
We have two ISR4321 gateways, two E1 lines, CUCM11.5, topology like this:
E1---VG1---|
E1---VG2---|--MGCP---CUCM

We have 600 numbers(xxxx5[0-5]xx) from ISP, the numbers(xxxx5[0-2]xx) are normal.
The numbers(xxxx5[3-5]xx) have a problem, when there is an incoming call from PSTN, the ip phone show "unknown number", debug isdn q931 shows the voice gateway received the caller ID, but ip phone shows "unknown number", how can we fix it.

Thanks.

[b.winter]

Why don't you post debugs, gw config, cucm logs,... already with your orig. post?
With your description only, it is hard to help for anyone.

If you have already done a debug on the GW, have you also checked the info going from the GW to CUCM, if the Caller ID is contained there?

[sgqjt0001]

@b.winterThanks for your reply.

I post the debug info and config here. I'am a beginner, how to check the info going from the GW to CUCM?

Thanks.

[b.winter]

Debugs for MGCP could be e.g. the following:

• debug mgcp events
• debug mgcp packet
• debug mgcp errors
• debug vtsp events
• debug vtsp session
• debug ccm-manager backhaul

Is it working for calls on one VG and on the other it's not? If yes, have you compared the config on the router and in CUCM?

[sgqjt0001]

There's the same issue on both VG, I checked the config on both VGS and CUCM, but I can not find any difference, I don't have enough experience for UC.

I checked the call logs on CUCM; it has received the caller id.

call logs from CUCM:

23/04/22 08:59:13.288|CC|SETUP|41183139|41183140|88888881791|88885410|88885410
2023/04/22 08:59:13.291|CC|OFFERED|41183139|41183140|88888881791|88885410|88885410|S0/SU1/DS1-0@VG2.xxx.com|PHONE-NAME
2023/04/22 08:59:13.292|SIPL|41183140|TCP|OUT|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,1.220737^*^*|82597139|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|INVITE
2023/04/22 08:59:13.308|SIPL|41183140|TCP|IN|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,681642.34^10.10.11.217^*|82597140|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|100 Trying
2023/04/22 08:59:13.403|SIPL|41183140|TCP|IN|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,681642.35^10.10.11.217^*|82597141|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|180 Ringing
2023/04/22 08:59:32.579|SIPL|41183140|TCP|OUT|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,19.140579^10.10.10.34^*|82597248|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|CANCEL
2023/04/22 08:59:32.589|SIPL|41183140|TCP|IN|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,681642.36^10.10.11.217^*|82597249|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|200 OK
2023/04/22 08:59:32.594|SIPL|41183140|TCP|IN|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,681642.37^10.10.11.217^*|82597250|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|487 Request Cancelled
2023/04/22 08:59:32.594|SIPL|41183140|TCP|OUT|10.10.10.28|5060|PHONE-NAME|10.10.11.217|50529|2,100,14,681642.37^10.10.11.217^*|82597251|e468cc00-44313161-86bee-1c950e0a@10.10.10.28|ACK
2023/04/22 08:59:32.686|CC|RELEASE|41183139|41183140|31

logs form IP phone:

Via: SIP/2.0/TCP 10.10.10.28:5060;branch=z9hG4bKd41bf67c505e0^M
From: <sip:anonymous@10.10.10.28>;tag=28058584~2a962780-918a-41bd-bac9-34245e25d012-41183140^M
To: <sip:88885410@10.10.11.217>^M     \\\\\This is the ip address of the phone
Date: Sat, 22 Apr 2023 00:59:13 GMT^M
Call-ID: e468cc00-44313161-86bee-1c950e0a@10.10.10.28^M
Supported: timer,resource-priority,replaces^M
Min-SE: 1800^M
User-Agent: Cisco-CUCM11.5^M
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY^M
CSeq: 101 INVITE^M
Expires: 180^M
Allow-Events: presence^M
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= Unknown; orientation= from; gci= 2-558892; isVoip; call-instance= 1^M
Send-Info: conference, x-cisco-conference^M
Alert-Info: <file://Bellcore-dr2/>^M
Session-ID: 5ed4b79a386eaa14112523bd41183139;remote=00000000000000000000000000000000^M
Remote-Party-ID: <sip:88888881791@10.10.10.28;x-cisco-callback-number=88888881791>;party=calling;screen=yes;prvacy=uri^M
Contact: <sip:10.10.10.28:5060;transport=tcp>^M
Max-Forwards: 70^M
Content-Length: 0^M
^M

This is from a normal phone number:

Via: SIP/2.0/TCP 10.10.10.28:5060;branch=z9hG4bKd41bc21d4d2ac^M
From: <sip:88888881722@10.10.10.28>;tag=28058500~2a962780-918a-41bd-bac9-34245e25d012-41183137^M
To: <sip:88885100@cucmsub.xxx.com>^M     \\\\This is the FQDN of the CUCM.
Date: Sat, 22 Apr 2023 00:58:08 GMT^M
Call-ID: bdaa9580-44313120-86beb-1c950e0a@10.10.10.28^M
Supported: timer,resource-priority,replaces^M
Min-SE: 1800^M
User-Agent: Cisco-CUCM11.5^M
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY^M
CSeq: 101 INVITE^M
Expires: 180^M
Allow-Events: presence^M
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= Unknown; orientation= from; gci= 2-558891; isVoip; call-instance= 1^M
Send-Info: conference, x-cisco-conference^M
Alert-Info: <file://Bellcore-dr2/>^M
Session-ID: 5ed4b79a386eaa14112523bd41183136;remote=00000000000000000000000000000000^M
Remote-Party-ID: <sip:88888881722@10.10.10.28;x-cisco-callback-number=88888881722>;party=calling;screen=y;privacy=off^M   
Contact: <sip:88888881722@10.10.10.28:5060;transport=tcp>^M
Max-Forwards: 70^M
Content-Length: 0^M
^M

Thanks.

[b.winter]

The logs of the phone tell you all you need to know and you already marked it with orange:
The calling number was hide by the calling party "From: <sip:anonymous@10.10.10.28>" --> That's why do don't see anything on the phone.
And you cannot do anything against it, because it's the choice of the calling party to hide it's number or not.

So, something is triggering the GW and / or CUCM to hide the calling number when sending the call further along the path until it reaches the phone.
Because you also have "privacy=uri" set in the non-working call, and "=off" in a working call.

Maybe you could also post the VG debugs of a working call or compare them by yourself.

[Scott Leport]

Hi,

Silly question, but are you sure that your provider have enabled inbound caller ID on the 5[3-5]XX number range? If the 5[0-2]XX was the original number range and the 5[3-5]XX was added later then it is entirely possible that caller ID may be enabled on one range and not the other. It might be worth asking the question of your provider if you haven't done so already.

[sgqjt0001]

@Scott Leport@b.winter Thanks

Yes, the 5[0-2]XX was the original number range, and the 5[3-5]XX was added later, but the provider said inbound caller ID are disabled on both number ranges, and now the 5[0-2]XX number range shows calling number when there's an incoming call, but the 5[3-5]XX number range shows "Unknown Number" when there's an incoming call.

Do you think I should trust the provider?

[Scott Leport]

Hi,

I don't think it would be disabled on both number ranges. If it was, inbound caller ID wouldn't be shown on any of your number ranges. Please follow up with the provider and show them evidence of working and non working calls. Alternatively, follow the suggestions by @b.winter 

[sgqjt0001]

And I tried "SIP normalization script" to show the calling number on the called phone, it can show the calling number, but still show "Unknown Number" after taking the call, and the call history in the phone is "Unknown Number"; there are 2 records in the history detail, one calling numbers is "Unknown Number", another is the real calling number.

[Roger Kallberg]

From your original post you stated that the GW is setup with MGCP as the control protocol. With this how would a SIP normalization scrip have any relevance?

[sgqjt0001]

Here is the debug on the VG.

The 88885097(Called Party Number) is the working call.

The 88885410(Called Party Number) is the non working call.

[Roger Kallberg · Accepted solution]

For the non working call you are getting this from the SP.

Calling Party Number i = 0x21A3, '88888888791'

21A3 = Hide calling number

Whereas for the working call you get this.

Calling Party Number i = 0x2183, '88888888791'

2183 = Show calling number

So definitely the Telco is sending these calls to you differently, or the calling end has defined it to be a hidden calling number, but as the calling number seems to be the same in both cases, so that's not very likely.

[sgqjt0001]

@Roger KallbergThanks

The Calling Party Number is my cell phone number and is not a hidden calling number. I'll contact Telco.

About SIP normalization scrip:

I found the "sip:anonymous" and the "privacy=uri" in the SIP invite message, so I changed the “sip:anonymous" to sip:[calling number-this number is from "Remote-Party-ID"] and changed the "privacy=uri" to "privacy=off", it works, but it has a bug.

[Roger Kallberg]

To what did you tie the SIP normalization script in CM? What you refer to is the phone logs and from what I know you can't use a SIP normalization script with a phone device.