Cisco => Avaya Transfer Issues 1

[vaoldschl]

I have been spinning up a Cisco UCM 7 and stringing it off my Avaya S8700 4.0.

I have PRI and H.323 trunks configured and working. I can call both directions. I can place calls on hold and I can transfer calls back and forth across either of the trunks. I have caller ID and connected name working.

Problem is that when a call is transferred it shows the CLID info of the person transferring instead of the call originator. x1234 (Avaya) calls x5678 (Cisco) and transfers to x4321(A). x4321 sees call as from x5678 which becomes a huge deal when you hit voice mail and reply to the switchboard operator instead of the call originator. The problem also occurs if x1234(A) calls x4321(A) and then gets transferred to x5678(C).

I've searched the world over and tried multiple configurations but I can't seem to overcome this. Anyone seen similar? I just feel like there is a "Send originator" field I'm missing somewhere but my eyes are burnt out from looking.

 

[HmmG3]

Are you using QSIG on those PRIs? When we were using both systems, we used QSIG trunks and they would update the names during transfers. If you have a plain old PRI, then the name info only gets sent during the call setup, and not updated during transfers or other changes.

I'm not sure if H.323 trunks have the same limitation or not. We never setup any between our Avaya and Cisco (our Avaya was mostly limited to TDM at the time).

 

[vaoldschl]

I am using QSIG on the PRI. When I activate QSIG on the H.323 the call fails from Cisco => Avaya.

 

[vaoldschl]

Playing with various settings for PRI type I have made the following progress: a call from Cisco to Avaya which is transferred elsewhere in Avaya is now carrying the CLID of the originator.

When I call Avaya to Cisco and transfer back to Avaya the line transferred to sees CLID of the Cisco but the original Avaya phone sees CLID of the Avaya endpoint. There has to be something on the Cisco PRI side that says to pass the data of the originator.

 

[HmmG3]

Oh, you are using an H.323 gateway? I thought you were referring to H.323 IP trunks between the Avaya and Cisco. QSIG requires the gateway be configured as MGCP. When it's MGCP, you'll have a QSIG option in the CallManager. Then you'll be running true QSIG in both directions.

 

[vaoldschl]

Right now I'm just trying to get it to work across the PRI and not messing with the H.323 (having codec issues and really don't have the time to trouble shoot).

Config is CUCM server to a 2801 w/vwic T1 crossover to CSU/DSU and TN464G on the Avaya. Most recent thought: Could there be something in the isdn config on the 2801 that is messing with me?

 

[HmmG3]

Here's a brief breakdown of how ours are configured (most other configs are fairly standard).
DS1 board config:
Signaling mode: isdn-pri
Connect: pbx
Interface: peer-master
Peer Protocol: Q-SIG
Side: a

Signal Group:
Associated Signaling? Y
Supplementary Service Protocol: a

Trunk Group:
Service Type: tie
QSIG-value Added? Y

Then on the CallManager side, the MGCP gateway port is configured as a "PRI ISO QSIG T1" with Protocol Side set to "User".

No other configs need to be made to the gateway IOS other then MGCP. However, it should show up as ISDN Switchtype "primary-QSIG" when performing a "show isdn status" command.

 

[vaoldschl]

I got it to work across the PRI mid morning. Finally went to the router changed isdn switchtype to primary-qsig and that appears to have been the disconnect.

Now to see if I can do it over H.323...