Help getting ANI from a PRI off a Rolm 9751 to CUCM 7.1

dubrennan · ‎04-04-2012

I have a scenario where I'm working with an old Rolm 9751 model 50 that does not support QSIG. It does support PRI and T1 and the vender for the PBX says it is sending both DNIS & ANI when sending a call from a Rolm phone to a Cisco phone; however, the Cisco phone only shows "unknown number".

I am not, nor would I claim to be, profficient with a PBX, so I'm working off the basis that the vender is accurate. The PRI is configured as a user side PRI as DMS-100 on the PBX and supposedly transmits called party and calling party information during the ISDN setup request.

I have configured a 3945 using both MGCP and H323 to emulate the network side as a DMS-100 trunk; however, all the ISDN Q931 debugs show that there is no calling party information regardless.

Does anyone have any experience or suggestions as to how to take this further? My limitation is that from a Cisco integration standpoint, if I don't see the calling party information in the setup request, all I can really ascertain is that the ANI isn't being sent.

The basic call flow is as follows:

Rolm phone dials 5555 > Rolm 9751 > PRI DMS-100 > Cisco 3945 PRI > CUCM 7.1.3 > 7942

Here's the q931 debug:

*Apr 4 17:10:36.939: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0001

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98397

Exclusive, Channel 23

Called Party Number i = 0xA1, '5555'

Plan:ISDN, Type:National

*Apr 4 17:10:36.943: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8001

Channel ID i = 0xA98397

Exclusive, Channel 23

*Apr 4 17:10:37.059: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x8001

*Apr 4 17:10:39.347: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x8001

*Apr 4 17:10:39.367: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0001

*Apr 4 17:10:39.367: %ISDN-6-CONNECT: Interface Serial0/1/0:22 is now connected to N/A N/A

*Apr 4 17:10:44.251: %ISDN-6-DISCONNECT: Interface Serial0/1/0:22 disconnected from unknown , call lasted 4 seconds

*Apr 4 17:10:44.251: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x8001

Cause i = 0x8290 - Normal call clearing

*Apr 4 17:10:44.283: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x0001

*Apr 4 17:10:44.283: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8001

Here's the relevent PRI setup for H323:

voice service voip

h323

h225 display-ie ccm-compatible

!

controller T1 0/1/0

pri-group timeslots 1-24

!

interface Serial0/1/0:23

no ip address

encapsulation hdlc

isdn switch-type primary-dms100

isdn protocol-emulate network

isdn incoming-voice voice

no cdp enable

!

voice-port 0/1/0:23

bearer-cap Speech

!

Any assistance would be greatly appreciated.

paolo bevilacqua · ‎04-05-2012

As you have seen yourself already, PBX is not sending calling number.

There is nothing that you can do about.

moataz_mamdouh · ‎04-05-2012

the PBX is not sending the calling number

have you tried to change the the protocol emaulate from user to network on both sides

paolo bevilacqua · ‎04-05-2012

moataz_mamdouh wrote:

the PBX is not sending the calling number

have you tried to change the the protocol emaulate from user to network on both sides

Doing that would guarantee complete communication failure.

moataz_mamdouh · ‎04-05-2012

I mean if we can change both sides not only one side

paolo bevilacqua · ‎04-05-2012

Good luck having legacy PBXs technicians to even understand what that means.

David Vasquez · ‎04-12-2012

We had a similar call flow and I could not get it to work either:

Rolm phone dials 5555 > Rolm 9751 (T-1 Card) > Cisco 3945 PRI (VWIC) > CUCM 7.1.3 > 7945

About the best I was able to do is have the ROLM phones display that a call was coming from VoIP gateway vs my other trunks, but was not able to get any caller information from the ROLM other than "Unknown Number."

I just let all of my users know that caller ID would not be available while we were migrating to the new VoIP system.