I'll do my best to answer each question in turn.
1) Switch from full T1 to half T1 without restarting?
Maybe. If you have a full span of TeleFlow applications waiting for in-bound calls, your telecom provider can reduce the number of channels on the T1, from say 23 to 12. TeleFlow *should* not be affected because it will only see calls on the first 12 channels. Nothing will ever come in on channels 13 to 23, so those ports will just remain idle at the Wait For Call step indefinitely.
If you have any out-bound ports, you will need to adjust your active TeleFlow Application List (.TAL) file to reflect the correct configuration of channels coming from the telco. In order for a change to the active TAL file to take effect, you must stop TFServer and start it again.
2) Can we set-up teleflow to forward calls to another number?
I'm not sure I understand the question, but I'll give this a shot anyway. Forwarding calls is typically something that the telco would do for you. For example, you have calls coming to your IVR on a particular number (DNIS), you could request your phone company send those calls to a different destination.
On the TeleFlow side, you cannot explicitly forward calls to a different number. However, you can transfer calls from TeleFlow to some other destination. This is a subtle difference from the perspective of the caller, but a big one in terms of implementation on the TeleFlow side.
There's only two ways (currently) in TeleFlow to transfer calls on a T1. The one you most likely want is called a "release transfer", or "release link transfer". This causes a call to be sent to another destination and releases your TeleFlow IVR from the conversation. I'll get back to this in a minute.
The other way to accomplish the same thing is to have the TeleFlow IVR place an out-bound call on a different port and then use the Switch port to connect the first call and this new out-bound call together. From the original caller's perspective, he/she has been transfered to another destination. On the TeleFlow side, both the original caller and the new party are connected to the TeleFlow IVR for the entire duration of their conversation.
I'm going to guess that you really want the "release transfer". In the T1 world, there are a number of different ways this is done. In TeleFlow's T1 support there is only one: "2B-Transfer", and it is only available on the NI2 variant of ISDN. This is the configuration we most often recommend. If you are not already on NI2, consider having your telco change your service at the same time they reduce the number of channels for you. 2B-Transfer works very similarly to the Switch connection (non-release) transfer I described above. You still need an out-bound port to reach the new destination. The difference is: once you've got the new party on the line, you issue a Transfer step, instead of a Switch step. The Transfer step instructs the telco to connect the two bearer (B) channels together (hence the name "2B-Transfer", and releases the IVR from the conversation (both ports).
Now I have heard rumours you can get a non-ISDN T1, running the US Wink Start protocol to perform a release transfer with a flash-hook. This is similar to the old transfer features available on analog phone lines. If you have a wink-start circuit and you can convince your telco to provide a flash-hook transfer feature, then TeleFlow would support it as well. The trouble is I have never personally known anyone who's been able to get that feature working. As I said, I think its just a rumour.
3) We are only receiving calls on the server, do we need to have a two way connection?
Depends on how you handle the call-forwarding issue. See if you can get what you need by having the phone company simply forward calls to that number to another destination. All calls will go to the new destination, and you won't need to make any changes to your TeleFlow applications.
If that is not an option for you, both the methods I described to transfer the call require at least one out-bound port. Therefore, you would need a two-way circuit, in and out-bound.
The rumoured "flash-hook transfer" would not require an outbound port, because the (presumed) flash-hook would occur on the in-bound port that answered the call. However, as this is the mythical phone system that Big Foot uses to call the Loch Ness monster, I wouldn't bet on that one!
Pardon my humour. Its getting late.
