Alcatel Unleashed

I´ve faced some problems the last few times that I can´t modify incoming cli and sending it a litle bit different out on a other trunk.
I know that I can do some modification when the incoming trunk is a private call but this is not covering what I want. Actually I would use the external call back translator for modifying cli and set it out through a other trunk. This would be very useful in cases with forced on pabx and remote extensions.

MrAnMo wrote:do some modification when the incoming trunk is a private call

Whould you share how you do it?

A4400 was not a transit pbx, it were some project to include SS7 or use ATM (search for pra7 cards in around R3 or search ATM155 cards up to 5Ux) but it was a quick 'phase out', still having in menu, and sometimes need to explain to end-customers: no-way. It's only empty caption in a menu, it does not work.

As for transit, try this: call goes in, you put it to a number like 2200, 2 it's an Abbreviated Number to dial DISA, in DISA you use automatic substitution (if you got CLI), and 200 is Abbreviated Number to dial out somewhere else.

Also see this: if you have PBX"a"->A4400->PBX"telco" connected by DSS1 you can't pass a CLI with CLIR flag on, to say this: PBX "a" sets CLI to "12 000 000" but it puts the CLIR flag on, what does A4400 on this picture ? it removes CLI from DSS1 (acts as end-user pabx, not the transit one) so PBX "telco" sees empty CLI plus a CLIR flag. So PBX "telco" must put any CLI on that call to pass it through a national carrier network (even when it's CLIR).

It's a not a request that ALU will agree to do it, if you want this, ask for products for TELCO / carrier grade. You will have full range from S12 or E10 to small ( ~200 x E1) compact switches from Lucent. Also ALU's BP for OXE/OXO don't have channel to buy such a transit pbx, you must search for carrier-level partner of Alcatel-Lucent.

Anyway: i try to convince everyone who tries to use a4400 as transit pbx not to do so, it's a great corporate or CCD pbx with IPT capabilities, but does not fit the 'carrier-level'.

About CLI modification in transit :
- if incoming TG private;
- if network mode=yes;
- f.e. entity in TG parameters=1;
- if incoming calling number=3000 (f.e.)
In this case outgoing calling number for transit call will be the same like for internal user (with number 3000 and entity 1) - will be used Installation number (entity 1 or NPD), DID rules (like for internal user 3000).
In additional - in accounting will just one ticket with charged number 3000 and right called number (instead of two in usual case - incoming and transit). And absent tickets to this TG.

Yeap, thanks for this, but i think more of:

incoming TG is private
incoming calling number is anything or it's anything + CLIR flag or it's empty
based on this TG number = f.e. 200, i would like to pass a CLI = 3000 +install number

another case:
CCD with CLI, based on PG that agent is logged on. I've got one site, many PGs, they whould like to call-out with a CLI == pilot no. (plus install number of course, to enable call back) its because people often don't answer cells without any CLI, maybe some of them will do a call back. So either i put private calling no to this agent (so, i must know where agent will be logged on !) or i use the set substitution (and lose anyCCS xls reports...) and must go with CRI and wait till the midnight to see any report data.

same with cost center put into a pilot / pg there is a place for this in mgr, but it never worked.

krzysioD wrote:

MrAnMo wrote:do some modification when the incoming trunk is a private call

It's a not a request that ALU will agree to do it, if you want this, ask for products for TELCO / carrier grade. You will have full range from S12 or E10 to small ( ~200 x E1) compact switches from Lucent. Also ALU's BP for OXE/OXO don't have channel to buy such a transit pbx, you must search for carrier-level partner of Alcatel-Lucent.

Anyway: i try to convince everyone who tries to use a4400 as transit pbx not to do so, it's a great corporate or CCD pbx with IPT capabilities, but does not fit the 'carrier-level'.

In this case I disagree. I see that ALU is doing more and more integration between the OXE and mobile platforms. What happens is that more and more customers are using FoPBX in combination with rex users. This means that al mobile traffic is routed through the OXE. In a FoPBX situation the mobile provider is putting the cli for the mobile phones exactly how they received it which means that when I receive a incomplete number I can not modify so i can send it correctly to the REX user. I´m realy thinking that this kind of integrations are part of the future so the OXE needs the possibility of modifying cli in transit.