Re: Telephony API draft

Hello,

The record feature in this API only mirrors that the dialer UI has to know
whether the user wants the call recorded from the beginning, or not. It was
meant as a UI option which is then conveyed to the implementation.

About accessing the streams... The Telephony API currently only handles
signaling.
[ Next, we planned to add conference support.
Next, I wish to support for handsfree gateways, multiple SIM cards and
different telephony services. I have a draft prepared for discussion.
Although this could handle most VoIP use cases too, let's discuss that
later and separately. ]

Next, stream support may be added. Note that this is missing from telephony
middleware such as oFono, but it is present in VoIP middleware like
Telepathy/Farstream. For telephony, we arguably don't really need access to
the streams, except for toggling eventual local recording - and only this
is supported for now.

For VoIP, I was thinking to use MediaStream. However, there are some audio
management details to be sorted out before I'd make a proposal.
Once we add support for accessing the streams, then yes, recording could be
supported via the MediaStream interface.

Do you think we should take out for now the recording feature? It could be
seen as a convenience function for the developers. My thinking was that the
Telephony API should facades most means to dialer developers supporting the
typical dialer UI designs, and the binding implementations would connect
the dots.
This is not minimalistic, but IMO it's simpler for developers.

Best regards,
Zoltan

On Sat, Oct 20, 2012 at 2:50 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Oct 19, 2012 at 3:50 AM, EDUARDO FULLEA CARRERA <efc@tid.es>
> wrote:
> > Hi all,
> >
> > I have uploaded an initial draft of the Telephony API [1], which has
> been jointly prepared by Zoltan Kis, Jose M. Cantera and myself, who are
> willing to act as co-editors of this spec.
> >
> > This draft is based to a great extent on the Firefox OS (B2G)
> WebTelephony API, but also incorporates additional feedback received mainly
> from Zoltan. Note that this draft has been edited using ReSpec, but we can
> migrate it later on to Anolis if necessary.
> >
> > Looking forward to your feedback.
>
> I don't really understand the "record" feature. Is the intent that the
> device will be doing the recording? I.e. could exactly the same thing
> be accomplished if we permitted access to the audio stream and then
> allowed the webpage to store the data as it saw fit (for example using
> IndexedDB).
>
> Or is the intent that the network somehow does the recording and so
> the implementation of the record feature will somehow communicate with
> the network?
>
> If the former, is recording really a commonly enough used feature that
> we should add it to the spec? Where is the recoding saved to? Don't we
> need to add parameters to control things like file name, file format,
> encoding and encoding parameters?
>
> Wouldn't it be better to support getting access to the audio stream if
> this is really important since that would allow additional usecases.
> Or at least wait with supporting this usecase until we have audio
> stream access.
>
> I've never seen a device which supports recording but maybe this is
> popular in markets that I'm not part of? Such as enterprise or other
> countries?
>
> / Jonas
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>