after upgrade of CUCM, on 8851 DN has been dialed, but the call display shows a directory URI

[Ali Amir]

Hi,

after upgrade of CUCM, on the phones 8851 when a directory number has been dialed (Ex. +1123456789 ), the called number display shows a directory URI (+1123456789@domainname.com).

CUCM version is 11.0.1 and 8851 has Firmware 11.0.1.

How could the directory number display instead of URI?

[Brandon Buffin]

Are these calls traversing a SIP trunk? If so, you can change the blended address setting on the trunk to "Deliver DN only". This should be the default.

Configure SIP Trunks for URI Dialing
Configure SIP trunks in your network to check whether Cisco Unified Communications Manager inserts a
directory number, a directory URI, or a blended address that includes both the directory number and directory
URI in the SIP identity headers for outgoing SIP messages.
Before You Begin
Create the SIP Profile
Procedure
Step 1 In Cisco Unified CM Administration, choose Device > Trunk. The Find and List Trunks window appears.
Step 2 Enter the details for the search criteria and click Find. The Find and List Trunk Configuration window
appears.
Step 3 In the Outbound Calls area, from the Calling and Connected Party Info Format drop-down list, choose
one of the following:
• Deliver DN only in connected party—In outgoing SIP messages, Cisco Unified Communications
Manager inserts the calling party’s directory number in the SIP contact header information. This is the
default setting.
• Deliver URI only in connected party, if available—In outgoing SIP messages, Cisco Unified
Communications Manager inserts the sending party’s directory URI in the SIP contact header. If a
directory URI is not available, Cisco Unified Communications Manager inserts the directory number
instead.
• Deliver URI and DN in connected party, if available—In outgoing SIP messages, Cisco Unified
Communications Manager inserts a blended address that includes the calling party's directory URI and
directory number in the SIP contact headers. If a directory URI is not available, Cisco Unified
Communications Manager includes the directory number only.
Step 4 Click Save.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_0_1/sysConfig/CUCM_BK_C733E983_00_cucm-system-configuration-guide/configure_uri_dialing.pdf

Brandon

[Ali Amir]

No, these calls are not traversing a SIP trunk.

After call processing CUCM sends these calls to the MGCP gatway.

Could these logs help to find out why the dialed number got the host name of CUCM?

60200581.001 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setSipSPIMsgArg: deliverOriginalIdentityHeader=false; origNumber=, origName=
60200581.002 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setPresentationIndication: namePi[0], numPi[0]
60200581.003 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setScreeningIndication: si[1], oct3a[81]
60200581.004 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setIdentityHeaders: ccb[e1a0b128], currLocalNum[+1123456789], currLocalNam[], callbackNumber[], localNumPi[0], localNamPi[0], id.flag[8], id.privacy[0], host[cucm-sub1.domainname.com], user[<NULL>]
60200581.005 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setRpidHeader: rpidHdrStr[<sip:+1123456789@cucm-sub1.domainname.com>;party=calling;screen=yes;privacy=off]
60200581.006 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=43227357/scbId=0/insertContactIntoContainer:  USER=[+1123456789@]
60200581.007 |08:48:21.003 |AppInfo  |//SIP/SIPHandler/ccbId=43227357/scbId=0/insertContactIntoContainer: Outgoing Contact=[<sip:+1123456789@10.10.10.2:5060;transport=tcp>]

...

*******************

...
60202292.001 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/ccsip_call_util: $URI Blended Connected Party info in CONNECT msg: uri-+1123456789@cucm-sub1.domainname.com, dn-+1123456789, ti-DN
60202292.002 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setSipSPIMsgArg: deliverOriginalIdentityHeader=false; origNumber=, origName=
60202292.003 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setPresentationIndication: namePi[0], numPi[0]
60202292.004 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setScreeningIndication: si[1], oct3a[81]
60202292.005 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setIdentityHeaders: ccb[e1a0b128], currLocalNum[+1123456789], currLocalNam[], callbackNumber[], localNumPi[0], localNamPi[0], id.flag[8], id.privacy[0], host[cucm-sub1.domainname.com], user[<NULL>]
60202292.006 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setRpidHeader: rpidHdrStr[<sip:+1123456789@cucm-sub1.domainname.com>;party=called;screen=yes;privacy=off]
60202292.007 |08:48:24.509 |AppInfo  |//SIP/SIPHandler/ccbId=0/scbId=0/setRpidHeader: cached RPID hdr val <sip:+1123456789@10.10.10.2;user=phone>;party=x-cisco-original-called;privacy=off

...

*******************

...

60202293.001 |08:48:24.509 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.10.19.110 on port 50125 index 290089
[129992562,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.19.110:50125;branch=z9hG4bK6bb043d5
From: "Test user" <sip:+164088899@cucm-sub1.domainname.com>;tag=b07d47d3baea001835a37d2c-71726d4e
To: <sip:+1123456789@cucm-sub1.domainname.com>;tag=43227357~2c7a54c7-0d9e-4eff-84e0-78946b228486-44471474
Date: Fri, 21 Oct 2016 07:48:13 GMT
Call-ID: b07d47d3-baea0006-731d464b-49bda870@10.10.19.110
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: replaces
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= NotAuthenticated; orientation= to; gci= 1-638176; isVoip; call-instance= 1
Send-Info: conference, x-cisco-conference
Remote-Party-ID: <sip:+1123456789@cucm-sub1.domainname.com>;party=called;screen=yes;privacy=off
Session-ID: 93a59504db202a96ff7820bd44471475;remote=25451a7600105000a000b07d47d3baea
Remote-Party-ID: <sip:+1123456789@10.10.10.2;user=phone>;party=x-cisco-original-called;privacy=off
Contact: <sip:+1123456789@10.10.10.2:5060;transport=tcp>
Content-Type: application/sdp
Content-Length: 181

v=0
o=CiscoSystemsCCM-SIP 43227357 1 IN IP4 10.10.10.2

Calling party: +164088899

Called party:+1123456789

[Brandon Buffin]

Check this service parameter - System > Service Parameters > Cisco CallManager > URI Dialing Display Preference. Is it set to URI or DN?

Brandon

[Ali Amir]

It is set to DN.

[CHRISTIAN END]

Hello Ali,

did you solve your issue? We got the same with two installations upgraded one from 8.6 and one from 7.1 to 11.5.

Christian

[Ali Amir · Accepted solution]

Hi Christian,

yes, it was solved. I don't know how but the  'Always Display Original Dialed Number' parameter under CCM was true.

After changing this parameter to false (default value), the peroblem has been solved.

[Rob Huffman]

Hi Ali/Christian,

I believe it's related to this bug and the fix that Ali nicely noted (+5 Ali!)

8841 Phones incorrectly display URI under OnHook Dialing

CSCuy44000

Symptom:
8841 Phones Displays URI DN@Domainname in on Hook Dialing when CCM Service Parameter -- Always Display Original Dialed Number is set to True

In the Logs if you look at 180 Ringing from CM to Calling Party --

For On Hook Dialing
In Remote party ID We will see DN@Domain

For Off Hook Dialing
in Remote Party ID field we will see DN@IPaddress

Conditions:
8841 Phones with 11.0.1 Firmware

On hook Dialing and CCM Service Parameter -- Always Display Original Dialed Number is True

Workaround:
This is working as designed, because the customer has set ?Always Display Original Dialed Number?

The basic difference in off and on hook dialing is :
Only in on hook (enblock)dialing is that the user (Phone) can dial a URI pattern i.e enduser@domain.com
Where as in off hook dialing that can never happen as we send 1st digit and then send the rest via kpml hence CUCM will never match a uri pattern. Because with the 1st digit itself phone will append the IP or the host name of the node that its registered to.


Hence only for a enblock dialing we store the host name that the phone send along with the digits dialed and not for off hook dialing

That causes the difference when ?Always Display Original Dialed Number? is enabled.

This needs to be documented in URI Dialing Section as a note that this is expected behavior

[CHRISTIAN END]

Thanks for your replies. My issue with the hostname portion when dialing was gone with setting the service parameter to false.

But i have in addition one more issue with 9971 phone and call list. No not an issue. When a user dialing to 9971, in the call list, the directory uri appears and not the number of the calling user.

When i delete the directory uri from the calling user, the phone shows the number. Is there any way to tell 9971 that it should display the number instead of the directory uri?

[Ali Amir]

Hi Christian,

I've not faced the issue with 9971 but following articles may help you:

Originally Called Party Name in Placed CallHistory

Uniform Resource Identifier Dialing

The phone screen displays the call information for the URI call. The phone stores the URI call information in the Call History and the Details page. When you receive a call with a URI address, the URI address is stored in your Call History. Press Redial to call the most recently dialed URI address.

Depending upon how the administrator configures your phone, you may see either the URI or the Directory Number (DN) displayed for the incoming call alerts, call sessions and call history. If the phone is set to display the DN but only the URI is available, then the URI displays. If the phone is set to display the URI and only the DN is available, then the DN displays.