Closed marcoscaceres closed 8 years ago
Orthogonal.
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?
That was anticipated to be done by a (more generic) mechanism, separate from this API. That mechanism may use the Telephony API, though.
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.
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.
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:
I got tel:
working with the prollyfill also in Chrome.
http://marcoscaceres.github.io/teleprolly/demo/?number=tel:12322
Once registered, it can be tested here. http://jsfiddle.net/tzUkT/
@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.
This bug relates to #14
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)
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.
Ok, will make sure the above is captured too when I document the relationship.
@distobj requested the spec describe its relationship to tel: URI scheme.