javascript interface updated

Peers javascript interface (peers-js) has been updated. Peers javascript interface is actually just a javascript interface to a java plugin running in browser. This java plugin uses the core of peers java sip user agent to place and receive calls.

The latest version of peers and peers-js is available on github on my peers repository: Peers source code repository will probably migrate to git, hosted on github soon. Thus, if you’re interested by peers, bookmark this link.

The demo page which was available previously on has been updated. Nevertheless, if you want to test it using latest java version (1.7.0 update 51), you have to declare as a trusted source web site in java configuration panel in security tab. If you don’t do that with latest version, java refuses to execute peers applet. This applet is not signed by a certificate from a certificate authority (like thawte), this is is the reason why this applet must be declared explicitly.

Unfortunately, sometimes, it can be tricky to find the right java config panel to declare trusted sites. Let’s take an example: on a 64-bits windows 7, it’s pretty common to have several java runtime environments installed, some in C:\Program Files\Java and some in C:\Program Files (x86)\Java. In my case, I had jre6 and jre7 in both Program Files and Program Files (x86). Actually, Program Files (x86) contains 32-bits programs and Program Files contains 64-bits programs. I went to this page to know which java version is running in my browser. I my case it was 1.7.0 update 51 but it didn’t say anything about 32-bits or 64-bits version. The browsers I used to validate this javascript interface were firefox and chrome. If I understand correctly, those programs are distributed 32-bits only, even for 64-bits windows versions. Thus, I think they install the 32-bits version of java when they reach a page where a java plugin wants to run and doesn’t find its plugin. I think that’s what I did. So, I ran javacpl.exe in C:\Program Files (x86)\Java\jre7\bin, modified trusted web sites source and it worked. On linux, the java config panel is jcontrol in bin/ in install directory.

Another restriction: I tested this page with asterisk running on a local network on another host and it worked, but it didn’t work with a sip account hosted on a public sip provider. Thus, I think java plugins are not authorized to send udp packets to public ip address in any way, even with signed jar using certificate from a certificate authority, even if user explicitly authorize the applet to run in its java config panel, even if user accepted all security pop-ups, even if the right AccessController.doPrivileged() invocations have been done in source code. I didn’t verify but I think that behavior would be the same even if java.policy files were deployed to the right directories. Even if java.policy was able to activate this “feature”, it would be too hard for standard users to modify it manually.

Thus, if you want run a java sip user agent in your browser with a sip account on a server hosted on the same local network and you are ready to pay for the java code signing certificate to avoid manual java config panel modification, this is the way to go. In any other case, you should probably choose another solution.

This entry was posted in Uncategorized by yohann. Bookmark the permalink.

Comments are closed.