sysapps / telephony

API to manage telephony calls
16 stars 12 forks source link

Describe the relationship to tel: #171

Closed marcoscaceres closed 8 years ago

marcoscaceres commented 11 years ago

@distobj requested the spec describe its relationship to tel: URI scheme.

zolkis commented 11 years ago

Orthogonal.

distobj commented 11 years ago

The API defines "dial" which permits a call to be established to a remote party using a provided phone number, so it's clearly not orthogonal.

It looks to me like the (or at least "a") question is, how does one obtain a TelephonyCall object for a call established by clicking a tel URI?

zolkis commented 11 years ago

That was anticipated to be done by a (more generic) mechanism, separate from this API. That mechanism may use the Telephony API, though.

marcoscaceres commented 11 years ago

It's a fair question that's going to come up a lot (and it would be neat if there was some means to wire them up together). Although somewhat orthogonal, the two are quite closely related (in that this API can serve as a handler for tel:). It would be good to add something non-normative to the spec to clarify the relationship.

zolkis commented 11 years ago

Sorry for shortcutting it, I was in a hurry. Yes, I have also been experimenting with tel URI's, and I have even had another dial() method with a tel URI parameter. In fact, that version of the API used to have a dial(uri) method on the telephony manager object, and the dial(remoteParty) method on the telephony services objects. I always though that was the technically correct way to do it, but it may cause some confusion. Perhaps we could rename the dial(uri) method to some other name and include in on TelephonyManager.

However, handling URI's is a more generic mechanism, and I expect a separate mechanism to handle and bind them to services.

marcoscaceres commented 11 years ago

I'm not sure we need to actually add support for dial(telURI), or some variant of that - though I'm open to exploring it.

I think what need to clarify a bit is what happens with when application A clicks on <a href="tel:+123112312">call me, maybe</a> and somehow App B pops up to deal with it... basically, it sounds like the system message thing again or using HTM5's registerProtocolHandler:

The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular schemes. For example, an online telephone messaging service could register itself as a handler of the sms: scheme, so that if the user clicks on such a link, he is given the opportunity to use that Web site.

Would roughly look like (tested it in FireFox):

var url = "http://127.0.0.1:8888/tel.html?number=%s"
if(!window.navigator.isProtocolHandlerRegistered("tel", url)){
    window.navigator.registerProtocolHandler("tel", url, "testing tel");
}

Which ends up being presented to the user like this, on desktop... not great, but all the infrastructure bits are in place:

screen shot 2013-06-22 at 13 16 55

marcoscaceres commented 11 years ago

I got tel: working with the prollyfill also in Chrome. http://marcoscaceres.github.io/teleprolly/demo/?number=tel:12322

screen shot 2013-06-22 at 22 42 49

Once registered, it can be tested here. http://jsfiddle.net/tzUkT/

marcoscaceres commented 11 years ago

@distobj, just want to confirm that the above is what you mean. Should I just describe how you can hook up the relationship via registerProtocolHandler? Let me know and I'll add what you think is appropriate.

marcoscaceres commented 11 years ago

This bug relates to #14

distobj commented 11 years ago

Hey. Yes, how to connect the Telephony-API using Javascript to registerProtocolHandler would be one aspect of this integration. Your solution seems pretty solid.

The other part of this would be what I mentioned earlier; about using the API to interact with a call that was initiated by a different (perhaps native/plugin) handler. Though I don't think it would be a showstopper to initially scope it to call management for calls initiated by the API (or hooked in via registerProtocolHandler as you do above)

zolkis commented 11 years ago

about using the API to interact with a call that was initiated by a different (perhaps native/plugin) handler

The implementation will have to list all connected calls, regardless how they have been started on the modem (from native or JS). So this should already be covered by the spec.

marcoscaceres commented 11 years ago

Ok, will make sure the above is captured too when I document the relationship.