GlobalCall Pros/Cons

From: "Carlos G Mendioroz" <tron@acm.org>

>1) Since the SDK (SR 5.1.1
>and GlobalCall) are C++
>libraries, can I assume that
>everyone building their own
>applications are programming
>in C++?

Nope, once you try java, you can never
leave it :)

>2) Does everyone use
>GlobalCall as an interface
>between your application and
>the call control libraries?
>If not, why?

Nope.
GC is fine for ...
on the other hand, functionality is quite a
subset of what you get with native API (be
it dx_, cc_ or dt_). And even so, it depends
on the underlying layer.
There are some things you can not do. That
sometimes is a show stopper for GC:
E.g. you can not change the number of rings
before answering in ANAPI (for letting a
caller know if messages are available) or
you can not request ANI on demand on an R2
link (for speedy answer on selected DNIS).

>3) Are there any "cons" to
>using GlobalCall? (I believe
>that GlobalCall only exists
>for the Windows platform.)

See 2. GC is available on Linux...
Also, see current postings of people
not knowing what's going on with GC :)

But this seems to be current trend with
dialogic. Higher APIs, obfuscated details.

>4) If all telephony logic is
>built on top of GlobalCall,
>will this ease the transition
>from low-density analogic
>cards to high-density (T1/E1)
>digital cards?

Usually, if you don't know much of T1/E1
signalling at least. (So you don't know
all the benefits that you are not using
because they din't map to GC :-)

As they say, my 2 cents...
-

To reply: mailto:General.26283@pysdiscussext.py.intel.com
To start a new topic: mailto:General@pysdiscussext.py.intel.com
To login: http://members.support.dialogic.com/wbproxy/wbpx.dll/~general
Received on Wed Nov 05 06:42:00 2003