There is a (non-free) iOS app called Transceive that is able to connect to any node that has the wt (web transceiver) option enabled. Apparently it does this by logging in to your allstarlink.org portal account as a means of authenticating, thereby presumably getting back a login token/cookie. Since wt access is defined in the portal as opposed to in a node .conf file, the wt protocol therefore seems to not simply be IAX, and would appear to be some undocumented protocol.
- Is the WT protocol documented anywhere? Or did Transceive have to essentially reverse-engineer it? If not, what would it take to get this documented?
- Is there a particular context/stanza in iax.conf or some other conf file that applies to wt connects?
- Is there any free app that can do the same thing? (aside from than web-transceiver which only works on certain computers/browsers requiring Java and a goofy security setup)
- What is the “[allstar-public]” stanza in iax.conf for? (Tried connecting from iaxRpt with those credentials but did not work. Connecting to iaxclient context works fine but that requires a password.)
Goal here is simply to be able to connect from a free smartphone app to nodes that support wt access. Thanks, David
It think Tranceive reversed engineered it as did Repeater-phone.
Node admins could add a new iax.conf stanza eg. “iaxclient-public” with a generic password such as “allstar” which could achieve the same thing, but that would require all node admins to then change that setting. That probably wouldn’t be any less secure than allowing wt access, since anyone can probably set up a web portal account easily enough (I don’t recall if allstarlink .org actually verifies callsigns when setting up an account). But apparently for now people either need to buy an apple phone and one of these paid apps, or set up Java and WT. Which may be good as it prevents people from getting some free app and jumping on AllStar, which could result in AllStar becoming more like EchoLink, which I would not endorse if that free app had not properly taken into account things like audio quality, dynamics, level settings, etc. to ensure audio quality consistent with high-quality real nodes.
I took a look at the WT app.js and it’s a 10,000-line blob with no documentation and no meaningful function or var names. Was there any documentation ever created for the WT? Or is it just an ancient relic with no written history? Just curious. I don’t personally use any of these apps anyway, but often see these kinds of questions and just wanted to have a better idea of how WT and app_rpt connect to each other.
We most certainly do verify every call sign at sign up! We also validate call sign changes.
Node admins could add a new iax.conf stanza eg.
Node admins do that now. Zoiper Setup for AllStar Btw, it’s free app.
Note, some node admins are preventing WT connections.
I tried DVSwitch (the beta version) on my android phone using WT method. It’s simple to set up using my allStarlink account and seems working fine. Good receive audio quality. But I did not try to talk using the app.
One thing is that my call shows up on the active node list instead of my node number.
Hi, great to hear DVSwitch Mobile will support that. I see now that it does have a “public authentication” checkbox in the account settings. It’s not clear which other fields have to be filled out though. I tried a couple things but am getting registration failure messages. I’ll continue to experiment with various combinations of settings and look further into this, but if you have any tips or could post a screenshot of your account settings for use with wt mode that would be much appreciated.
The IAX protocol does not really have facilities for creating or updating a password; this is generally done out-of-band. This is why the web-transciever protocol isn’t documented alongside IAX; it’s implementation specific.
I’d be willing to document the allstar-public (aka WT) system on the AllStar Wiki if I had access.
While we’re at it, we should probably also document the node registration API as well.
Thank you ve6ngk, DVSM is now working great in WT Mode, and parrot test audio sounds great.
I see now that Steve N4IRS posted about this in Aug. '22 - DVSwitch Mobile 2.x beta test available And DVSM also has a Node Mode where it will act as a node ie. an actual ASL node with its own node#! Pretty impressive for an android app! I will be looking into that further also.
And to W8WJB, documentation on the WT protocol and registration API would be great. Always good to have things properly documented somewhere. I hereby move that the ASL admins give you wiki access. Thanks & 73, David
Could you mark the post that solved this for you? Just clicked the solved checkbox on the posted solution. Thanks.
I’d prefer to leave it open if you don’t mind, as it was more a request for information than an issue. Maybe someone else might run across it later and post more details about the WT protocol and related APIs. And while DVSM is a great option it’s not Free & Open Source so ideally there would be a FOSS app that can do these things. With DVSM being only $2 to buy I’m definitely not complaining, and it is the first and only program I have ever paid money for in the Android app store. As an advocate of open-source software and also of making detailed and complete documentation available for AllStar and all the protocols it uses, I think the more general issues brought up here have not yet been solved.