Customer Identity Request (CID) for internal calls

[mduser]

Is it possible to get CID request for internal calls. The system is BC11 SP8. Normaly CID request is only valid for external calls to ACD groups.

The CID request is programmed with RAGAI and for DDi calls directly to the ACD groups it works fine.

We now have an IVR system (Onebox) in front of the ACD groeps to let customers make a choice which ACD group to go to. The IVR then puts the call on hold and transfers it (before answer / blind mode) to the ACD group. Because the initial call fron the IVR is internal, no CID request is questioned. We need the CID for the CSTA environment (ApplicationLink 4).

Is there some hidden system parameter to change the setting for the CID request or is there any other way to make this?

 

[mduser]

Is it possible to fake the call-id by making an outgoing route comming in in the same exchange again?

For instance a ISDN-QSIG route outgoing and instead of going to another exhange come in in the same exchange again? I don't think real QSIG or DPNSS can work because the MD110 will see it as internal (I think). But what settings do I need to make such a outgoing-and-incomming route. It's preferred to have route optimalisation otherwise i would need more than 1 connection, because we heve 150 incomming trunks from the public exchange.

A: Does anyone know setting for such a connection based on ISDN Public-line?
B: Does anyone know setting for such a connection based on ISDN Tie-line (Qsig)?
C: Are there bottlenecks in this kind of configuration I have to consider?

 

[TBLuk]

Tough one... CID Announcement will *only* work on a direct external call.

It's highly dubious wether it will be possible to fool the system into thinking the call originated from the PSTN.

I'm trying to think of a way around it, and I am wondering if a back to back CAS link may be enough to do the trick.

This would involve programming two new routes, one for outgoing, one for incoming, with an extra dummy code inserted to avoid a looping scenario.

All calls to the ACD group would be sent out on the CAS, received back in, then treated with as a normal external call.

The problem is, wether the CLC will have be a 1 or a 4... hope for your sake it's a 4, but I can't see it. I'll have a think to see if there is another way.

 

[mduser]

It's no problem fo create extra routes with extra destination code. As it's the Onebox receiving the calls and transfering after hookflash it can dial extra digits (first DEST and then <ACD-group>). In that way looping is no issue.

Do you know route settings (ROCAI/RODAI for a back-to-back CAS as you call it?

 

[Avstral]

Hi mduser!

The easiest way to make the loop in MD is to take couple of TLU76/1, loop them TX->RX and program them for ISDN like this:

ROCAI:ROU=60,SEL=011000000000,SIG=111100000031,TRAF=03151515,TRM=4,SERV=2100000001,DIST=30,DISL=128,NODG=0,BCAP=111100;
RODAI:ROU=60,VARC=00000010,TYPE=SL60,VARI=15400000,VARO=00410000;

ROCAI:ROU=70,SEL=011000000000,SIG=111100000031,TRAF=03151515,TRM=4,SERV=2100000001,DIST=30,DISL=128,NODG=0,BCAP=111100;
RODAI:ROU=70,VARC=00000200,TYPE=SL60,VARI=15400000,VARO=00310000;

Don't forget to program number length:
NANLS:EXL=xxx,MIN=3,MAX=7;

Do you have enough license in your system for this?

Regards

 

[TBLuk]

Avstral,

The reason that CAS is used is that it is a pretty dumb signalling protocol, which is well suited for back-to-back operation.

Mduser,

I'll dig out the RODAI's for a CAS link today, you'll need a couple of TLU76/3s or something similar.

 

[mduser]

To TBLuk,

The TLU76/3's will be no point. At the migration from Mobility server to integrated Cordless these boards were not used anymore, and we've putted them on stock.

For the ROCAI/RODAI parameters for the CAS link I'me very interested.

Thanx in advance.

mduser.

 

[mduser]

To Avstral,

Thanks, your solution works fine.

Mduser.