cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2025
Views
0
Helpful
10
Replies

Outgoing Calling Name not working

Ayaz Khan
Level 1
Level 1

Hello All,

We are using CM 7.0 and have 28 using H323.  We have not been able to get Calling name display working.  I have included a copy of the running config and snapshot of GW config from CM.

Feb 23 02:56:48.529: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13

Feb 23 02:56:48.529: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num 5197430271

Feb 23 02:56:48.529: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x2029 callID = 0xA203 switch = primary-ni interface = User

Feb 23 02:56:48.529: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x2029

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98397

                Exclusive, Channel 23

        Facility i = 0x9F8B0100A115020109020100800D4B69746368204C696272617279

                Protocol Profile =  Networking Extensions

                0xA115020109020100800D4B69746368204

MKPLVG#C696272617279

                Component = Invoke component

                        Invoke Id = 9

                        Operation = CallingName

                                Name Presentation Allowed Extended

                                Name = Kitch Library

        Display i = 'Kitch Library'

        Calling Party Number i = 0x2181, '519-------'

                Plan:ISDN, Type:National

        Called Party Number i = 0x80, '1905--------'

                Plan:Unknown, Type:Unknown

Feb 23 02:56:48.605: ISDN Se0/0/0:23 Q931: RX <- STATUS pd = 8  callref = 0xA029

        Cause i = 0x80E428 - Invalid information element contents

        Call State i = 0x01

Feb 23 02:56:48.657: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0xA029

        Channel ID i = 0xA98397

                Exclusive, Channel 23

MKPLVG#

Feb 23 02:56:51.657: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0xA029

        Progress Ind i = 0x8088 - In-band info or appropriate now available

MKPLVG#

Feb 23 02:56:54.949: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x2029

        Cause i = 0x8090 - Normal call clearing

Feb 23 02:56:55.205: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0xA029

Feb 23 02:56:55.205: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x2029

I have tried setting plan and type for called number, checking the display ie box on GW in CM and variations "isdn display ie" commands

Telco says everything is enabled on their end, they are using Nortel DMS100, PRI n1

Below is telco's last statement,


Re: Outbound Call Display

Here is what Allstream sees when you send a call:


<== 06:08:07:56.96 (CM Time: 27:11:10:06.36).
<== Q931: SETUP: from S[7053] L[1,58,0] E[22,57,0] SPA[----]
CR: 0,00 9B
BC: speech
64 kbit/s
circuit mode
mu-law speech
CID: 18
LENGTH: 03
Channel Selection Info: As Indicated in Following Octets
D-Channel Indicator: D-Channel NOT indicated
Preferred/Exclusive: Exclusive
Interface type = primary rate
Interface Identifier: IID Implicitly Identified
Channel Type: B - Channel Units (3).
Number Map: Channel is indicated by the number following.
Coding Standard: CCITT
Channel Number = 23
CGN: e164
national_number
user_provided_passed_screening
presentation_allowed
5197430271
CDN: e164
national_number
5198933996

==> 06:08:07:57.10 (CM Time: 27:11:10:06.50).
==> Q931: CALL PROC: to S[7053] L[1,58,0] E[22,57,0] SPA[----]
CR: 1,00 9B
CID: 18
LENGTH: 03
Channel Selection Info: As Indicated in Following Octets
D-Channel Indicator: D-Channel NOT indicated
Preferred/Exclusive: Exclusive
Interface type = primary rate
Interface Identifier: IID Implicitly Identified
Channel Type: B - Channel Units (3).
Number Map: Channel is indicated by the number following.
Coding Standard: CCITT
Channel Number = 23

---------------------------------------------

The CGN is showing the number and that is getting through. The name display needs to be in a new field call DSP:

DSP: ±Whatever name

Please try this and test.

Thank you,

Andrew Paul
Primus Canada

I think the issue maybe with "Cause i = 0x80E428 - Invalid information element contents"

If anyone has any ideas or has encountered this issue before please let me know.

Thanks,

10 Replies 10

Vipul Jindal
Cisco Employee
Cisco Employee

call manager is sending the name is

Display i = 'Kitch Library'

don't what telco is looking for, you need to contact telco and get more information about name display.

thanks,

Vipul JIndal

I will engage them again,  What should I be asking them.  I'm wondering what their statement means,

"

The CGN is showing the number and that is getting through. The name display needs to be in a new field call DSP:

DSP: ±Whatever name "

Thanks,

I just ran into this with a Telco here in Canada. Was getting the same error as above and they couldn't tell me why.

This thread explains the issue exactly but doesn't mention that the 0xB1 byte is enabled by checking the "Send Extra Leading Character in Display IE" box on PRI Protocol Type Specific Information settings in CUCM.

Hate to bring a dead post back to life but hopefully this helps someone in the future.

Chris Deren
Hall of Fame
Hall of Fame

Does Allstream allow you to send calling name?  Most PRI providers in North American do not accept the name and they simply present what's defined on the trunk group.

HTH,

Chris

I got a reply from Telco, I wans't included in the call.  They said Out bound display is not mapped correctly witht correct bits, and he provided the chart below.  Not sure what this exactly means, is this something we could adjust on the Cisco side?

CharacterDecimalHexBinary
space322000100000
plus+432B00101011
plus/minus±177B110110001
Note:If you get #NAME? in the hex and binary columns, go to Tools -> Add-Ins, and select "Analysis ToolPack"

Thansk,

Chris, In Canada PRI users can send any calling name and it will be displayed.

However, in this case the indication from the telco are not clear at all.

Yes, Paolo I recall you educating me on this already, I should have said most providers in US, sorry :-)

Chris

I got the following repsonse from Telco for why outgoing calling name is not working.  Is there a parameter that would allow me adjust the DSP field.

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

There was also this. Here you are.

The first call is outbound from PBX, if you look in DSP field it should have +/- sign before name and it does not, second call is from me and see the same DSP field with +/- field and name display works

Below is explanation from my technology guy regarding these and attached spreadsheet explaining this

*********** Outbound Call from PBX ***************

<== 05:09:26:29.32   (CM Time: 12:13:43:56.78).

<== Q931: SETUP:     from S[7053] L[1,58,0] E[22,57,0] SPA[----]

  CR:  0,3C F2

  BC:  speech

       64 kbit/s

       circuit mode

       mu-law speech

  CID: 18

       LENGTH: 03

       Channel Selection Info: As Indicated in Following Octets

       D-Channel Indicator: D-Channel NOT indicated

       Preferred/Exclusive: Exclusive

       Interface type = primary rate

       Interface Identifier: IID Implicitly Identified

       Channel Type: B - Channel Units (3).

       Number Map: Channel is indicated by the number following.

       Coding Standard: CCITT

       Channel Number = 20

  DSP: Kitch Library

  CGN: e164

       national_number

       user_provided_passed_screening

       presentation_allowed

       5197430271

  CDN: e164

       national_number

       5198979327

==> 05:09:26:29.32   (CM Time: 12:13:43:56.78).

==> Q931: STAT:      to S[7053] L[1,58,0] E[22,57,0] SPA[----]

  CR:  1,3C F2

  CSE: user

       invalid_information_element_contents

       diag bytes = 28

  CS:  call initiated

*********** Inbound Call to PBX **************

==> 05:09:27:18.57   (CM Time: 12:13:44:46.03).

==> Q931: SETUP:     to S[7053] L[1,58,0] E[22,57,0] SPA[----]

  CR:  0,15 38

  BC:  speech

       64 kbit/s

       circuit mode

       mu-law speech

  CID: 18

       LENGTH: 03

       Channel Selection Info: As Indicated in Following Octets

       D-Channel Indicator: D-Channel NOT indicated

       Preferred/Exclusive: Exclusive

       Interface type = primary rate

       Interface Identifier: IID Implicitly Identified

       Channel Type: B - Channel Units (3).

       Number Map: Channel is indicated by the number following.

       Coding Standard: CCITT

       Channel Number = 4

  DSP: ±ALLSTREAM

  CGN: e164

       national_number

       network_provided

       presentation_allowed

       9056299815

  CDN: e164

       national_number

       5197430271

<== 05:09:27:18.64   (CM Time: 12:13:44:46.10).

<== Q931: CALL PROC: from S[7053] L[1,58,0] E[22,57,0] SPA[----]

  CR:  1,15 38

  CID: 18

       LENGTH: 03

       Channel Selection Info: As Indicated in Following Octets

       D-Channel Indicator: D-Channel NOT indicated

       Preferred/Exclusive: Exclusive

       Interface type = primary rate

       Interface Identifier: IID Implicitly Identified

       Channel Type: B - Channel Units (3).

       Number Map: Channel is indicated by the number following.

       Coding Standard: CCITT

       Channel Number = 4

The byte which precedes the actual name information is in three parts.  The first bit is a 1, and does not mean anything.  The next three bits are referred to as, “associated information”, and basically indicate whether we are including a name, or requesting a name.  For including a name they should be 011.  The final 4 bits are the “display type”, with options for calling, called, and original called.  For sending a calling number they should be 0001.

The little ± you see is actually a byte 10110001 (hex B1).  When you see a + from the customer with the problem they have coded something else in this byte, and thus calling name is not actually being passed.

Attached is a spreadsheet confirming that the ± is the correct coding (10110001) for the byte in question.

It seems like they want 0xB1 as first byte in the calling name to be displayed. I never heard of this requirement.

I don't know if you will be able to configure that on CM, because it's not a ASCII character.

All the other telco I know of in Canada, do not require this, and do accept calling name without a problem.

Issue was resolved by changing the switch-type from Primary-ni to primary-dms100