W3C home > Mailing lists > Public > public-sysapps@w3.org > September 2013

Re: About Telephony API

From: Anton Tveretin <fas_vm@surguttel.ru>
Date: Mon, 30 Sep 2013 23:18:44 +0600
Message-ID: <9B8D57544A7444E0B8327B12EE186AA9@Gateway>
To: "Kis, Zoltan" <zoltan.kis@intel.com>
Cc: <public-sysapps@w3.org>
Thank you for your reply.
So let me be more specific... This is not valid WebIDL. In particular, I use
"struct", "enum" for undefined (yet) types.
First, consider the following grouping:

interface TelephonyAddress{
readonly attribute String DisplayName; //from any source
readonly attribute String AddressOfRecord; //empty string if unknown, incl.
interoperability and anonymity
readonly attribute String RoamingAddress; //or CareOfAddress? E.g. IP-based
for VoIP implementations, otherwise empty.
                                                                //Should be
MSRN in GSM, but unknown there
readonly attribute Boolean Anonymous; //or restricted, in ITU terms.
readonly attribute Boolean Verified; //do not specify by whom
}
//Maybe a local TAddress is also a factory for calls, similar to JTAPI?

Hence, common attributes for a call:

partial interface TelephonyCall{
 readonly attribute TelephonyAddress CallingParty;
 readonly attribute TelephonyAddress CalledParty;
 readonly attribute TelephonyAddress CallInitiator; //Call may be initiated
by a third party. This also covers "doctor" scenario discussed by stir WG at
IETF.
 readonly attribute enum Direction;
  //one of "outgoing", "incoming", "transit", "third-party", "internal",
"unknown"
  //Call may be exposed to a non-party, e.g. to an administrator of a PBX.
It is "transit". "Internal" is for symmetry.
  //I think it should be better to have the same State at both sides...
 readonly attribute sequence<ForwardingRecord> History; //see below
 attribute String Subject;
 attribute String? Bearer;
 //ISDN (and thus TAPI) uses this attribute to discriminate between "voice"
//and "data". For some implementations, it is invariable, as "analog" or
"IP".
 //If not defined by dialer, implementation chooses the best one.
 //TBD: what about bandwidth? Is it a separate attribute?
 //TBD: is the "Bearer" attribute mutable? Modify the call by some other
method?
 readonly attribute struct LowLevel;
 //another ISDN-specific attribute. Actual structure TBD as a separate
interface.
 attribute String HighLevel;
 //equivalent to MediaMode in TAPI. For IP, logical channels are used
instead.
 attribute LogicalChannel[] LogicalChannels; //See below. Useful only for
some implementations.
 readonly attribute struct AdviceOfCharge; //TBD
 attribute String ClosedUserGroup; //Number or GUID?
}

Some structures mentioned above:

interface ForwardingRecord{
 readonly attribute TelephonyAddress Forwarder;
 readonly attribute struct Reason;
 readonly attribute String? Timestamp;
}

interface LogicalChannel{
 readonly attribute String HighLevel; //for consistency. One of "audio",
"video", "fax", "chat" or few more.
 void hold(); //channel-specific.
 void resume();
//anything else? Direction (send,recv,both)?
}

Few more notes.
1. What does "Accept a call" mean? In TAPI, lineAccept really means "start
alerting". I suggest removing "accept" operation, and replacing it with two.
2. TAPI 2 has a concept of call "handover" between applications (e.g. a
voice mail application, a fax application, a terminal emulation
application). I think it is still useful for IP-based calls (esp. in
interworking).
3. "Holding" a call is local; other party may also hold the call on its side
or not.
4. As for conferencing, I'll write next time.

partial interface TelephonyCall{
 void answer();
 void startAlerting();
 void redirect(String to, struct reason);
 void blindTransfer(String to); //or combine these actions into one, 
depending on call state?
 void assistedTransfer(TelephonyCall consultation);
 Boolean handover(); //to another local application.
//If succeeds, the app no longer owns the call, and should not change its 
state (only listen to events).
 String park(); //returns code
}

Best wishes,
Anton Tveretin.

----- Original Message ----- 
From: "Kis, Zoltan" <zoltan.kis@intel.com>
To: "Anton Tveretin" <fas_vm@surguttel.ru>
Cc: <public-sysapps@w3.org>
Sent: Saturday, September 14, 2013 4:13 AM
Subject: Re: About Telephony API


> Hi Anton,
>
> Thank you for the interest in the Telephony API.
>
> On Thu, Sep 12, 2013 at 11:02 PM, Anton Tveretin <fas_vm@surguttel.ru>
> wrote:
>> I think telephony API should be something different.
>
> Please feel free to make a proposal, handling the existing use cases
> of the API, plus the use cases you would like to add.
> Or just add use cases. Any of these would be useful.
>
>> I think of a telephony
>> program (for a voice/fax modem, or ISDN) or a softphone (for VoIP), which
>> uses scripts to handle incoming calls. It may process calls automatically
>
> As far as I understand these are exactly the use cases for the
> Telephony API, adherent to existing telephony standards.
> In this version, voice call control is in the scope.
>
>> (e.g. receive faxes or files, or implement voice mail) or reject them,
>> using
>> caller, nature of the call, subject etc.
>
> When it comes to extra interfaces, the spec has been designed so that
> we can later include other than voice interfaces, too.
> Also, the API could already be creatively used for implementing other
> than usual user interactions on telephony events.
>
> Again, feel free to propose extensions, or alternative designs - these
> would illustrate your point more accurately.
>
>> Maybe I shouldn't address to this WG, as the thing is unrelated to the
>> Web
>> and W3C.
>
> Given the scope you depicted above (scripted handling of call events),
> I understood the thing actually was related to the Web and W3C. For
> clarifying the scope, please provide use cases and/or proposals :).
>
>> Obviously, such API must be fairly extended (Microsoft TAPI 2.2 is
>> somewhat
>> closer), with many call attributes, states, and methodes.
>
> This, or a related API can (and hopefully will) be extended to support
> all GSM/CDMA/(and later VoLTE, SIP, XMPP) features needed, and which
> are not visible yet in the API. As an example where future development
> may lead, see https://etherpad.mozilla.org/5AnQEPnpvI
> There have been many modem and telephony middleware implementations
> the editors have considered during the API design, so more specific
> questions may help clarifying where do you perceive having gaps in the
> API.
>
>> Also, I know there are PBXes that allow some kind of call control, but no
>> common API.
>
> Could you elaborate more on this point?
>
> Best regards,
> Zoltan
>
>> Sincerely yours, Anton Tveretin
>>
>>
Received on Monday, 30 September 2013 17:22:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:16 UTC