Ongoing Thirdlane Connect Issue

Any chance this is going to be fixed in the upcoming release?

Connect is virtually unusable for our customers because switching to the softphone breaks their desk phone.

Hello,

Thank you for reportind the problem. It will be fixed in next release.

Awesome...I filed this bug literally a year ago as bug #2226 in redmine. Is that no longer used and I should report on forums as I reported a handful of other unresolved issues there as well.

We just upgraded to the "next release" and this issue still persists. Additionally, when attempting to configure the ICE Servers to use TLS, the turnserver is outputting errors and we do not get audio....

426357: session 001000000000000005: TLS/TCP socket disconnected: :50006
426357: session 001000000000000005: closed (2nd stage), user <> realm origin <>, local :5349, remote :50006, reason: TLS/TCP socket buffer operation error (callback)
426357: session 001000000000000005: closed (2nd stage), user <> realm origin <>, local :5349, remote :50006, reason: TLS/TCP socket buffer operation error (callback)
426357: session 001000000000000006: TLS/TCP socket disconnected: :50007
426357: session 001000000000000006: TLS/TCP socket disconnected: :50007
426357: session 001000000000000006: closed (2nd stage), user <> realm origin <>, local :5349, remote :50007, reason: TLS/TCP socket buffer operation error (callback)

Any feedback on this as I was expecting the extension settings issue to be corrected in the most recent release.

Additionally, it has come to my extension that Thirdlane Connect does not properly set the outbound caller id. In multi-tenant (at least), the outbound caller id that is used is always the tenant default caller id even when a different external caller id is set on an extension.

Hello,

Engineers are looking into previous and latest reported problems.

interesting, It seems to not do this on the mobile app, as I can bounce back and forth very quickly and it retains the information.

v 8.3.1.2 has this problem fixed.

As an fyi, this issue is not suitable fixed. It is possible it was fixed and rebroken because as mentioned in other posts, Connect is virtually unusable in its current form. Nevertheless, I do test it out from time to time.

There are presently 2 issues still with switching from desk phones to Thirdlane Connect and both are related to the same options when set on an extension.

As mentioned in our original post that started this thread, we actually implement security on our phone system deployments so we have TLS and SRTP in use.

Issue #1:
If the option for transport on an extension is set to tls,udp to allow the system to accept UDP connections if TLS is unavailable, when switching from connect back to the desk phone, the setting is changed to just "TLS".

Issues #2 (the bigger issue since it makes Connect calling not possible):

If you have the encryption option in an extension set to "yes", Connect will not dial out. Further, if the transport option is set to "tls" or even "tls,udp" (possibly because of issue #1 above), Connect will not dial out. This is most likely because Connect fails to support secure calling. If you don't want to support secure calling in Connect, the Connect routine for switching to the Connect client should include modifying these options and storing them temporarily somewhere so that a user can successfully switch back to a desk phone.

Issue #3:

I don't know if this only occurs because of the issues above, but when switching back and forth to Connect and desk phone, the "Opus" codec gets added as an enabled codec on the extension over and over again each time the Connect calling client is enabled and it is not removed when switching back to the desk phone. After doing this a dozen or so times, outbound calls from the desk phone fail with codec unavailable. Most likely because Asterisk only attempts to use so many of the codecs listed before hitting some hard limit and timing out.

Hi netriplex. #1 fix should be available in next release, #2 When you switch Connect to WebRTC mode, pbxmanager adds a bunch of very specific parameters into sip peer configuration, you should not try to edit them, and web GUI does not allow you to do this. Your assumptions are wrong, connect works only via SRTP and Secure WebSockets transport (almost the same as TLS, differs only in connection handshake way and framing inside the socket), and can't work anyhow other than that, it supports only SRTP/AVPF profile and wss as transport, and when you switch Connect to WebRTC mode, transport would be set to wss only, I have explained reasons over here https://www.thirdlane.com/comment/10495#comment-10495. Clarify exact setps to reproduce. #3 is fixed and will be available in next release.

Steps to reproduce are very simple...

1. Create an extension with either the encryption option set to yes and/or transport set to tls.
2. Attempt to make a voice call with thirdlane connect. The thirdlane client with report no connection to the telephony server is available.
3. Set back to desk phone mode, remove the encryption and transport option from the configuration, go back to Thirdlane Connect and switch to using Connect client. Connect will now work.

Of course, Connect will not work this way and was never designed to. What we call "SIP mode" is designed to be compatible and configurable with any phones that customer may have. "WebRTC mode" designed specifically to be used by Connect, and when is chosen, "other options" becomes uneditable, because as I told, we add a lot of specific options to them, for Connect to be able to work and Deliver most reliable and secure way of calling. And Connect has that switch functionality inside, to be able to switch that radio button from the user perspective.

As follow up, this limitation is removed in the next-generation Thirdlane platform and allows having Connect and Desk Phone to be registered simultaneously, on different transports and with different RTP profiles. Feature with switching modes would be removed from Connect as would no longer be required.

Does that feature hold true if the desk phone is connected via TLS and uses SRTP as well?

Also, knowing about all these next gen things is good and dandy however, no timelines have been provided on these things and Thirdlane is losing out as we are migrating our customers to 3CX one by one because we are unable to renew Thirdlane for the few extensions we have remaining on Thirdlane thanks to the inability of Connect to except incoming calls in the background from hunt lists.

If there was a timeline provided, we might have been able to convince some of our customers from migrating. But as it stands now, we have had to migrate over 150 extensions to 3CX.

As I already mentioned, yes it will. We actually already did a lot of effort to support it this way, especially for encryption in multiple devices per account. In new platform asterisk will no longer deal with encryption and TLS, we have new front-end components that will work out almost everything including encryption and TLS for the Asterisk, an Asterisk will be kept as an application server, and will not deal with complex stuff, like ICE, encryption, TLS transport, device wakeup etc... As encryption is handled out of Asterisk we currently have created three modes for it: "Enforce, Reject, Negotiate", so theoretically having this you would be able to have a phone without encryption via UDP transport, phone with encryption via TLS, and Connect with encryption via WSS, under a single account (extension) simultaneously, and dialed in parallel forking mode, moreover due to asynchronous nature of new components, that would also may include ringing mobile device, that would be woken up as last resort of three previous was not answered, or woken up initially and dialed as soon as it will be ready. Timeframes is a very delicate topic and I am not ready to give you an exact date on the forum, we have very strong requirements to deliver it this year. We will soon write a blog post, with an overview of new features and abilities of the next-gen platform, what opportunities does it open, what does that mean to our customers, and ways of migration, etc. It may include a possible time frame. Currently, there is a big focus on next 9 release, which should be released very soon, it will include Asterisk 13 upgrade, with all the features, from 13 branch, and also, we did few tasty custom patches to Asterisk, and changes in other components that significantly increase performance, stability, and monitorability of the platform.