<HEX to HEX> instead of <Hex - People - Hex>

<HEX to HEX> instead of <Hex - People - Hex>

Post by Ribe » Fri, 23 Jul 2004 13:25:05


Give Tapi Developers more Power!

The raw Hex Caller ID data is not hard to understand at all, and it contain
all the information a developer would need.

I think it is plain stupid to translate a good Hex Caller ID Signal into
"People Language" and then translate it back to Hex in unimodem.

Whoever though out this stupid idea doing this <people translation> do not
deserve a medal.
However they possibly didn't know what they were doing. Maybe it looked
fancy at the time.

I say, get the Raw Hex to Tapi Developers!! The Tapi developers have plenty
of brain to make good use out of this data, and can make any Caller ID
application compatible with any kind of Telco.

Regards
Jack Riber
 
 
 

<HEX to HEX> instead of <Hex - People - Hex>

Post by Andreas Ma » Sat, 24 Jul 2004 01:07:23

Riber" <riber @ RemoveSpacesAndThis mail.com> schrieb im Newsbeitrag
news:qkHLc.45$ XXXX@XXXXX.COM ...

Jack,
please note that TAPI is not equal to modem! TAPI is an abstraction layer for
all kind of telephony equipment.

The "raw Hex Caller ID data" you are referring to is only modem related and
not relevant for any other kind of TAPI devices. So IMO it is not TAPI
relevant. TAPI (not restricted to modems!) has a well defined way of
presenting CallerID in LINECALLINFO.dwCallerIDxxx.

Admittantly there are modem related issues presenting CallerID via TAPI but
these have several causes: TelCo signalling, signal processing by modem
hardware, modem.INF file, and UniModem.TSP.
I'm under the impression that you are focussed on blaming almost solely
UniModem.TSP for this situation.
But AFAIK TAPI is presenting CallerID correctly if UniModem.TSP is provided
with the information it expects. So one can say that it is the task of the
underlaying layers to provide this info correctly and conform to UniModem's
specifications. It seems that a lot of TelCos over the world feel the need to
define proprietary CallerID signalling protocols and that modem manufacturers
are not able to handle all these protocols and provide a valid signalling to
UniModem. Even if UniModem will be enhanced to process all these proprietary
(or malformatted) signallings it won't take long until a new TelCo or modem HW
is available that comes with an additional variant that won't work...
So IMO there is a clear priorisation of responsibilities for these issues:
1. TelCo CallerID signalling "standards"
2. modems (HW, .INF)
3.UniModem.TSP.
(4.)TAPI itself (as part of the OS) has absolutely nothing to do with it
because it solely depends on the info provided by the TSP.

Possible solutions:
A. Address the issues in priority of responsibility.
B. Write your own Modem.TSP: anybody (in theory) is able to write a TSP. The
specifications are available via MSDN and there is a sample code for AT
command based TSP available (ATSP32). Any modem manufacturer could deliver a
well tailored TSP for their modems but apparently the choose to do not. Even
every developer may try to develop a better TSP for modems.
C. If you want modem proprietary data like "raw Hex Caller ID data" you may
always choose to develop a modem proprietary (non-TAPI) app accessing the
modem directly.

--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK
TAPI / TSP Developer and Tester
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
* Please post all messages and replies to the newsgroup so all may
* benefit from the discussion. Private mail is usually not replied to.
* This posting is provided "AS IS" with no warranties, and confers no rights.




 
 
 

<HEX to HEX> instead of <Hex - People - Hex>

Post by Ribe » Sat, 24 Jul 2004 03:52:42

Thank you very much Andreas for you deep and wide reply to this.

and

This raw message is simply Beep - Silence translated to 1s and 0s
I believe that would be the case for any kind of Telephony device ?

However, I guess the modems ability to provide this raw data is not common
in other types of telephony devices. Then again, if Tapi had an option to
receive raw data, maybe more people would look into the raw option. Do you
think that makes sense?


I'll read your message again tomorrow. I very much appreciate your valuable
input.

Regards
Jack Riber
 
 
 

<HEX to HEX> instead of <Hex - People - Hex>

Post by Andreas Ma » Sat, 24 Jul 2004 08:07:25

"Riber" <riber @ RemoveSpacesAndThis mail.com> schrieb im Newsbeitrag



Jack,
I guess you didn't take telephony devices into account that are not POTS
related, e.g. ISDN phones or digital system phone connected to a PBX. They are
using interfaces like S0, Up0, or Uk0 partly with proprietary protocols on it.
In thoses cases there is no "raw Hex Caller ID data" like modems use it.



No!
As I said "TAPI is an abstraction layer for all kind of telephony equipment".
One may regard this as prime directive.
It is the goal of TAPI to provide a standardized mechanism for accessing the
CallerID.
Any TAPI app (not only those focussing on modems!) should be able to get this
info in the same way.
Of course TAPI offers ways to access proprietary info or functions via
Extended Services (DevSpecific stuff) but this is only designed for features
that are not provided by the common parts of TAPI (Basic and Supplementary
Services).
So if a TSP provides raw data although there is well defined way in TAPI to
provide the same info in a way that all(!) TAPI app can understand then this
would be regarded a violation of the prime directive (s.a.).

--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK
TAPI / TSP Developer and Tester
http://www.yqcomputer.com/ 's_TAPI_and_TSPI_FAQ.htm
* Please post all messages and replies to the newsgroup so all may
* benefit from the discussion. Private mail is usually not replied to.
* This posting is provided "AS IS" with no warranties, and confers no rights.
 
 
 

<HEX to HEX> instead of <Hex - People - Hex>

Post by Ribe » Sat, 24 Jul 2004 09:50:10

Dear Andreas,

I must admit I've taken down my banner and will possibly search for
solutions in other directions after having a break.

I thought this raw string could be THE solution globally, to cut straight
through all the problems around world. Now I understand that some modem
producers can not even get that raw part right.

Thank you for filling me in on hard to find information.
(possibly not hard to find for you, but for me it is)

Regards
Jack Riber