Hi

We are running a trial version of TeleFlow server. Our aim is to be able to connect a Dialogic D/4PCIUF to a Nortel BCM phone switch. The Nortel supports up to four analog extensions and provides CLID. I assume we can use these.

The BCM supports Hunt Groups, so the idea would be that first calls would be routed to the IVR. Then, when all IVR lines are busy, the calls are automatically sent to the extensions for operators to pick up. Is this the correct way to go about doing this?

More importantly, our application has an option to speak to an operator. We have been told that we will not be able to get release link transfer to work unless the protocol variant is NI2, and we activate "2 B Transfer" feature. If possible, we would still like the CallerID to be retained after the transfer to allow for call popping (to avoid using messy database/text files)

However, as far as I am aware, NI2 applies to North America only? Also, could you explain what the 2B Transfer actually is? We will most likely be using BCM50 with BRI or Analogue Lines. None of our customers have PRI/ISDN30. What would be your suggestion in order for us to get transfers working?

If it is not possible to get release link transfers to work, what is the alternative?

Thanks

You should be able to, yes. Basically, each line in the Dialogic card on the IVR is like a regular analog phone. So, what you can do when you plug one of these analog extensions into an plain old analog phone, you should be able to do using the Dialogic card.

"Correct" in this case is mostly a matter of what you are trying to accomplish. If the goal is that the IVR handle as much traffic as it can, and the operators handle the overflow, then yes, your suggestion works.

As for the transfers, and the protocols in use, it sounds like there is some confusion about what you are trying to do and/or where in the mix the IVR is.
If you are strictly looking at a Dialogic analog card, your transfer options would be:
- Flash-hook transfer, assuming the analog extensions support it. After a flash-hook transfer, there is a connection between your caller and operator, but the IVR and its extensions should be out of the loop, freeing the analog extensions for more calls. (You still have limitations on the number of simultaneous calls through the PBX, obviously)
- Switch transfer: Uses two of your analog extensions; one line is occupied with your caller, the other with your operator. The two lines remain occupied for the remainder of the conversation between caller and operator.

In analog, there is no NI2. NI2 is an ISDN protocol variant. You can't use it with an analog card. Release link transfer on an ISDN NI2 circuit is available in TeleFlow, although only on the NMS platform(I.e. You can't do this in Dialogic with TeleFlow). This transfer means that when the two parties (the party requesting the call transfer, and the called party) are connected, the connection to the two channels on the ISDN circuit connected to your IVR is freed up. (So, those two parties are now talking, and the IVR is out of the picture.)

Hi

Thank you that cleared up a lot of our worries. We are relatively new to phone systems and we usually contract a third party to setup the BCMs for our customers.

I believe that the confusion lay in the fact that the BCM accepts ISDN (BRI) trunks but it has four analog extensions as well. So, from what I understand an analog Dialogic card should suffice.

That begs the question, under what scenarios may some of our customers require digital telephony cards for E1, etc?

From what you have described, Flash-hook transfer seems like the best option as it will free up more lines and the IVR can take more calls.

We will be testing out TeleFlow and the Dialogic card for another few days, and then hopefully purchase a few licenses for our first client!

Thank you very much

The need for digital telephony cards comes down to what you are trying to accomplish.

For higher volumes of calls with more simultaneous callers, a PRI is typically a better answer than extra analog lines(depending on costs, how many cards you can fit in a single server, etc). A single PRI can handle up to 23 simultaneous callers, and the cards to handle ISDN are capable of connecting a number of PRI circuits on a single card.

Digital circuits also have DNIS, which means you can have one system that answers the phone, then determines what service to provide the caller based on the number the caller dialed to reach the system. In analog, the physical line pretty much determines the number dialed. So with DNIS, one circuit can host a number of different services, and the number of lines used for a given service is based on the demand of callers, as opposed to pre-set hunt groups.

Caller ID is more reliable under ISDN, but that doesn't mean you can depend on it to always be present. In analog, you have to wait a couple rings to get the Caller ID as well, whereas you can answer the phone immediately in ISDN, and still retrieve this information. (Faster call throughput, and your customer is served just a little faster)

There are probably a number of other differences that could matter under the right circumstances, but I believe these are most of the key differences that could be important to you down the road.

Thank you, this was very helpful.

Is it possible to place these digital telephony boards 'in front' of a PBX rather than behind it? That way things like call recording on all trunks could also be carried out...

On another note, we wanted to see if it is possible to get some of our smaller customers to have an IVR enabled phone system but without a traditional PBX. What I mean by this is to have the telephony board answer calls for the IVR but then to have calls transferred to handsets that are directly? connected to the telephony board. Is this sort of thing possible with Dialogic telephony cards?

If not, do you recommend any other way for our smaller clients to implement IVR without forking out large sums of money for a PBX? This would definitely make it easier for us to sell our IVR application.

Thanks once again

An IVR doesn't need a PBX to be involved at all, but that depends entirely on what you are trying to accomplish. Call recording is done passively, and can be done trunk-side, rather than station-side, as you suggest(Note that we have a product - CallCapture - for this purpose. This is only supported using AudioCodes SmarkWORKS cards(formerly Ai-Logix cards), so the call recording would likely be in its own server, anyway).

Not exactly, no. If there are Dialogic boards that allow this, we haven't developed any support for them.

You could set up a scenario in which everyone in an office has an analog phone line with its own terminating phone number. The IVR could have several analog phone lines as well. When someone should be transferred, you could use a flash-hook transfer to dial any one of those lines. This moves your costs to monthly (because you need more analog phone lines from the Telco) costs, as opposed to a larger up-front cost with a PBX. Generally speaking, because of the costs of so many analog lines, this will not be a worthwhile option.

On the NMS platform(with a CG6060 card), you could develop a solution using SIP/VoIP. This would allow you to have a T1/E1 coming into your IVR, and then a number of SIP phones that act as extensions. The IVR can direct inbound call traffic to your SIP extensions, and in reverse, SIP calls from the extensions can pass through the IVR out to the PSTN to place outbound calls.

If you do intend to explore this, I would highly recommend getting yourself a test lab developed with your product first, as getting such an environment set up is tricky, and you don't want to try doing it in the field without first-hand experience.

Of course, if you are only looking at a small amount of inbound/outbound call traffic, this may not be ideal, either. However, I have essentially described the options available to you.

This seems like a great option and we will definitely explore this. Thank you

It sounds like you are developing an auto-attendant of some sort using TeleFlow. We have an auto-attendant application we use ourselves, and it includes a voicemail component/application.

We are planning to clean this up a little and augment it with some additional features(primarily, these will provide Web accessibility to the TeleFlow applications using PHP/XML/AJAX), and release it as an open source package in the near future. Although we aren't ready to do that at this time, we would be happy to release an early open source package "as-is" in the more immediate future if this would be of benefit to you.

If you are interested, post here. We'll make something available shortly thereafter(I.e. within a few business days of your post), with more to come in the coming weeks.

this could possibly interest us, and would certainly be far more flexible...

having said that, we have essentially finished our TAM development in teleflow designer and it does perform the bare minimum that we require. One nice thing to add to the teleflow designer is a method by which you could connect to a web service (SOAP, etc)?

TeleFlow has a rich set of features for interacting with a Web service. Check out the "Web" tab on the Designer's Steps Toolbox. If you don't have a Web tab, you probably still have the Web steps. The tabs we re-organized long after the steps were first introduced. Also, check out the "Data/XML" tab. If either of these tabs are not present, download the latest version of TeleFlow from http://www.teleflow.org

The most typical approach to web service integration is to use TeleFlow's HTTP step. Results can come back in any format, but XML is most common. SOAP is not supported natively, but you can work with it using the standard TeleFlow XML steps.

Since you have something that does what you need presently, and our package isn't quite "release ready", it would probably make more sense to hold off until our package is a little more solid.

Check in on the TeleFlow Open Source page every now and then. In addition to what's already available there, the auto-attendant mentioned, and others will become available for download over time.

In the UK, the protocol used for ISDN is ISDN 30 [DASS-2]. Will we still be able to perform call transfers using the Dialogic and Teleflow?

Thanks

You wont be able to perform a release transfer under this configuration. TeleFlow doesn't have support for release transfers on the DASS2 protocol. I don't know enough about the European variants to know if the protocol itself supports this.

You can connect a Dialogic D/600JCT board to the circuit and use TeleFlow to control the call. If you want to connect two channels together, you'd have to use the TeleFlow Switch step, which will "trombone" the two channels together, but will tie up both ports for the duration of the call.

Well, if the Dialogic card is sitting 'infront' of their PBX this should not be a problem right? As you have the lines coming into the Dialogic and out to the PBX... this configuration is surely possible?

I assume you're referring to this part of my post:

In this case, you are quite right. It will work whether you are in front of, or behind, the PBX. The Dialogic card itself is doing the switching and so it does not matter how the two callers were reached. Any two active ports can be switched together.