Forward vs transfer

[slabr]

Hello all.

I've got question/problem. I've got such a config: Cisco CUCM (PBX A)<--QSIG-QF T2-->OXE r9.1(PBX B)<--ISDN T2->>OXE r9.0(PBX C). When on PBX B I set Immediat forward (to PBX A or C - it doesn't matter), on destination set the original number is present (public or private). But when I'll make transfer (with or without consultation - it doesn't matter), on destination set is present only internal number from PABX B (not original). I've tried to managed:
- NPD used for external forwarding in External Signalling Parameters
- Redirecting number used in External Signalling Parameters
- Call diversion in ISDN on Trunk Group
Nothing helps. All the time the internal number from PABX B is displayed on destination set. Is it possible to send original number in transfer mode at all, or this config is not possible in inter PABX configurations? Any suggestions will be appreciated.

Regards
Slawek

[slabr]

I've got some more questions. I've found on cisco site document which describes pretty detailed how to connect CUCM with Alcatel OXE via QSIG trunk: http://www.cisco.com/en/US/solutions/co ... 724166.pdf. There are some limitations of this connection but not all are understanded for me. Does anybody can explain the difference between:
- forward by reroute
- forward by join
My cisco support told me to search something about hairpining but it supposed to be another nomenclature in Alcatel because I cannot find anything similar in documentation. Is hairpining similar to join or it means totally different function? Does anybody knows anything about that?

Regards
Slawek

[alex]

- forward by reroute
- forward by join
My cisco support told me to search something about hairpining but it supposed to be another nomenclature in Alcatel because I cannot find anything similar in documentation. Is hairpining similar to join or it means totally different function?

Yeah, "hairpinning" (what a stupid term , almost like hairpulling) is exactly like "joining". PABX A receives a call which is forwarded and makes another one aimed at external destination. So two TS's (i/c and o/g) are occupied with one call.
With reroute (QSIG-GF) PABX A sends a FACILITY message telling "This set is forwarded to XYZABCD.So make another attempt and call directly XYZABCD."
So originating side just make another call so no TS's are occupied on PABX A.
And still it is not clear what you want to see and where.

[slabr]

OK. Now I understand the difference. So the forward by reroute is better because it takes less resources. And in CUCM<-->Alcatel connection this is the only supported config (as described in documentation). Anyway, after change cisco router config from H323 to MGCP, almost everything started to work. Almost, because during transfer call the original number are transferred properly (in both directions). The only thing which is not working is when on PABX B is set redirection (it doesn't matter which one), the call from CUCM couldn't be established (in another way is working properly). For no one I need to find if problem is on Alcatel side or on CUCM or cisco router config.

The other thing is, that between two Alcatels on ISDN Trunk connection, redirection working properly but on transfer calls the original number is not transfered. So what else can be check to make this config working?

[alex]

And in CUCM<-->Alcatel connection this is the only supported config (as described in documentation).

Actually I cannot check now but if "gf diversion on joining" is "No" then it is "reroute" mode if "Yes" - it is joining.

The only thing which is not working is when on PABX B is set redirection (it doesn't matter which one), the call from CUCM couldn't be established (in another way is working properly). For no one I need to find if problem is on Alcatel side or on CUCM or cisco router config.

Only one thing - check traces. And check SW versions both on CUCM and OXE. A lot of things are added and corrected with new versions.

The other thing is, that between two Alcatels on ISDN Trunk connection, redirection working properly but on transfer calls the original number is not transfered. So what else can be check to make this config working?

Hmm. I am not sure that original number should be transferred in case of transfer.

[slabr]

Actually I cannot check now but if "gf diversion on joining" is "No" then it is "reroute" mode if "Yes" - it is joining.

You mean joining variant gf of diversion in External Signalling Parameters?

The only thing which is not working is when on PABX B is set redirection (it doesn't matter which one), the call from CUCM couldn't be established (in another way is working properly). For no one I need to find if problem is on Alcatel side or on CUCM or cisco router config.

Only one thing - check traces. And check SW versions both on CUCM and OXE. A lot of things are added and corrected with new versions.

The SW on Cisco and Alcatel side are almost the newest (8.5 on Cisco and 9.1 on Alcatel). Anyway, I don't know how it would happen, but forwarding is working now (propably I've set somethig in meantime and don't realize it fix problem).

The other thing is, that between two Alcatels on ISDN Trunk connection, redirection working properly but on transfer calls the original number is not transfered. So what else can be check to make this config working?

Hmm. I am not sure that original number should be transferred in case of transfer.

If original number are transfered to CUCM via QSIG-GF why it sholudn't be transfered to Alcatel? Because of ISDN trunk type? Should it be changed to ABC_F?

[alex]

You mean joining variant gf of diversion in External Signalling Parameters?

Yes I did.

The SW on Cisco and Alcatel side are almost the newest (8.5 on Cisco and 9.1 on Alcatel).

Yeah these are the latest SW's.

If original number are transfered to CUCM via QSIG-GF why it sholudn't be transfered to Alcatel? Because of ISDN trunk type? Should it be changed to ABC_F?

Sure QSIG-GF works like that. ISDN (EDSS1) is lower on services. Just check with t3 and you'll see which information is sent when transferring a call.

[tot3nkopf]

See this (training R7 - I have no information about this on newer releases):

Partial rerouting.jpg

restrictions partial rerouting r7.jpg

[slabr]

OK. To be clear. When I call from mobile to Call Manager (ie. 0609799800) and then transfer this call to Alcatel, the presented number is almost as suspected. Almost, because the number is transmitted without 0 prefix (don't know why), so Alcatel show this on set like 09799800 (propably because first digit, 6 here, is interpreted as outgoing prefix). To fix this, I've set Network call prefix in Network Routing Table coresponding to CUCM<==>Alcatel trunk from -1 (default) to 0. After that, number is presented corectly but it cannot be called backed if it would be logged as unanswered, because there is no 0 prefix (my outgoing prefix). I've checked, that it doesn't matter which prefix I'll set: 0, 00, 5 or something else. The number are presented always in the same way: 609799800. So, can it be done something more, to be possible add 0 prefix in front of transmitted number?

And the second situation is, when I call from mobile to Alcatel (the same number) and transfer it to another Alcatel via ISDN trunk, no extra signalization is transmitted (in t3 trace there are no more information), so on destination set there is only internal number form first Alcatel which is making transfer. So the question is:
- shall I set all necessary parameters as described in restrictions partial rerouting file on both Alcatels, or it is needed only on transfer side?
- is the limitation of ISDN trunk to support extra signalization as Alex sugested and the trunk needs to be changed to ABC_F, or I missed somenthing in my config?

[tot3nkopf]

My general understanding is that the feature is working only for EDSS1 (ISDN all countries, not for QSIG or ABC-F). For this kind of link you must use ARS not routing number.
Keep in mind that partial rerouting is working with forwards, not with transfers:

partial rerouting 1.jpg

partial rerouting 2.jpg