Cisco => Avaya Call Transfer CLID data

[vaoldschl]

I posted this on the Cisco side but thought I'd try here as well. 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.

 

[dufus2506]

You might try setting up the trunk group to "send connected name/number".

That's about the only thing I can think of. Though it may only work in one direction.

When a person transfers a call, the call is essentially re-originated from that point. Unless both ends agree about extending the originator's information, it's not likely to be re-sent after a transfer.

Carpe dialem! (Seize the line!)

 

[vaoldschl]

Playing with various settings for PRI type on the Cisco 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.

 

[vaoldschl]

Found the problem, in the router that serves as gateway for the PRI isdn switchtype was set wrong. Corrected that to 'primary-qsig' and we're good to go.

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