Check for callto: protocol support using javascript

[Alexander]

Hi,

I am developing a web-application which will start telephone-calls using a
special protocol (callto: or phone

There will be two groups of users, one with a phone-client installed and
support for the protocol,
and one without this client.

So I need to write a javascript-function to check if the callto: or phoneto:
protocol is available on the client.

ANY IDEAS???

If I just add the link for every user, the ones with no client will run into
an error message on every click:
"Protocol not supported" in firefox
"Page cannot be displayed" in IE

Regards Alexander

 

[Jonas Raoni]

Alexander escreveu:

So I need to write a javascript-function to check if the callto: or phoneto:
protocol is available on the client.
ANY IDEAS???

Call both url's with an image haha, I'm not sure if it will work anyway


Like:
(new Image).src = "callto:lala";

If I just add the link for every user, the ones with no client will run into
an error message on every click:
"Protocol not supported" in firefox
"Page cannot be displayed" in IE

So, don't use it... It's not a standard and I don't know anything like
"hasProtocol" =/

 

[VK]

Hi,

I am developing a web-application which will start telephone-calls using a
special protocol (callto: or phone

There will be two groups of users, one with a phone-client installed and
support for the protocol,
and one without this client.

So I need to write a javascript-function to check if the callto: or phoneto:
protocol is available on the client.

ANY IDEAS???

Are you going to make voice calls over HTTP protocol? If not then you
have to set new MIME type for the browser - then just check for
registered mime types.

 

[Thomas 'PointedEars' Lahn]

Are you going to make voice calls over HTTP protocol? If not then you
have to set new MIME type for the browser - then just check for
registered mime types.

Does it not hurt you when you post such ridiculous utter nonsense? If not,
it should. Hopefully, that will eventually provide you an incentive to
stop doing that. Here is a hint for you: if you did not understand a thing
that was talked about and/or you do not have any clue, just *DO* *NOT*
*POST*!


PointedEars

 

[Thomas 'PointedEars' Lahn]

I am developing a web-application which will start telephone-calls using
a special protocol (callto: or phone

Which is not registered at IANA and therefore unwise to use.
tel:, as specified by RFC2806, is registered as URI scheme for
telephone calls.

There will be two groups of users, one with a phone-client installed and
support for the protocol, and one without this client.

So I need to write a javascript-function to check if the callto: or
phoneto: protocol is available on the client.

And then do what? Tell the user that their configuration is not sufficient?
I bet they already know by then.

[...]
If I just add the link for every user, the ones with no client will run
into an error message on every click:
"Protocol not supported" in firefox
"Page cannot be displayed" in IE

And why is that not sufficient? If the link does not work and results in
displaying an error document, users will use their UAs Back feature. You
should provide additional information next to the link or in the
documentation of your application (maybe even before you can start using
it) what the requirements for its use or the use of its features are, what
the error message would mean and what to do when users encounter this
problem.

You cannot test with unprivileged client-side scripting whether a UA has a
working protocol handler configured for a protocol, and with privileged
script this probably is not cross-browser compatible (you will have to
access the UAs preferences directly for which there is no unified
interface). Due to the Same Origin Policy and URIs not necessarily meaning
resource retrieval -- especially it does not seem so in your case --, there
is no use in trying host objects like Image or XMLHttpRequest as the result
are but false positives regarding missing support.

So ISTM that what you want is simply not possible and you will either have
to rely on UA's behavior and your documentation to provide sufficient
information to the user or provide a user agent along with your "Web
application" that can handle this type of URIs.


PointedEars