The scenario is we have a CUCM6.1.2, a Meridian system and an H323 gateway with two PRIs connected.
On the H323 Gateway Serial0/0/0:15 is a primary-net5 that goes to the PSTN and Serial0/1/0:15 is a primary-qsig that goes to a Meridian system.
When users make calls out to the PSTN from the CUCM they send a 4 digit CLI that is passed to the exchange successfully and the correct number is displayed at the called number
When users on the Meridian call out to the PSTN the call comes in to the gateway on s0/1/0:15 and has the correct 4 digit calling party number and is routed to s0/0/0:15 without going to the CUCM. When a circuit is picked up on s0/0/0:15 the 4 digit calling party number is still correct but the base number is displayed at the called number.
I suspect the problem is the conversion of the calling party number from the qsig format to q931 format as we are getting this error:
Jun 2 10:38:31.588: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8429
Channel ID i = 0xA9839F
Exclusive, Channel 31
Facility i = 0x91A40702020100810101
Protocol Profile = Remote Operations Protocol
Component = Reject component
Invoke Id = 256
Problem = Invoke problem; Unrecognized operation
I have attached a debug and the configuration of the gateway. By the way, this site is in Germany and the users in Germany use "0" for an outside line on the CUCM and Meridian. To keep configuration clear on the gateway the Meridian system translates the leading "0" to a "9" and that is why the called number coming in from the qsig link is prefixed with a 9.
"Internal" calls between the two systems display the correct calling information.
Yes, it's just type/plan. I wanted to be sure before saying:
interface x/y (to pstn)
isdn map address . type unknown plan unknown
You can also block sending the qsig message with "no isdn outgoing ie facility" or something like that, it doesn't make a difference anyway.