Problems with 3CX Client on Android 7 device

[leonardo_911]

Good afternoon. I have problems with the 3CX Client v16 application installed on a device with Android version 7. The device is a Grandstream GXV-3370 phone, firmware version 1.0.3.3. Exactly, the fault is that when the application is run on the device (3CX Client v16) an error appears with the following alert "Sorry, the application crashed. Please send a report to the developers. You can add a comment here: .. .... " The strange thing is that Android version 7 is the minimum version for the softphone to work well.

How can I solve this case? Thank you very much for the attention, I will be attentive to your response.

 

[nb]

Hi Leonardo

In this case the message is correct but it should not be sent to us - it should be sent to Grandstream No it is not strange at all. Remember our app is designed to work with smartphones. A smartphone does not have a chord with a headset.. So that's already an issue. The on hook and off hook code will have an exception when you install it on these types of devices.

HOWEVER - I really do not appreciate when companies do this. So devices like this are over 300 bucks and released in 2018. Let's dissect this together since you are a platinum partner..

A) So we can both agree that if you have android 7 on a smartphone, it means that phone is discontinued. We are on android 10 now. A phone made for 7 will never go to 10. Just can't. So if it has not gone to 8 at least or 8.1 it means that this model has been superseded by another model.

Now the worst comes here.
B) If you have an android 7 on a DESKPHONE - it shows big big trouble not only with the phone, but also with the roadmap of the development teams in charge of packaging android. Because I think devs that never updated a deskphone to later os, gave up hope and moved to something else - probably an app. So you bought the wrong product concept. This device might never receive an update.

I will explain: First of all it is embarrassing to have android 7 on a smartphone LET ALONE on a deskphone. Remember - I am putting emphasis on DESKPHONE because it is big - has a screen the size of an ipad. You have a POE or capability for high CONSTANT uninterrupted voltage. I mean a 100 dollar cheap phone already has android 10 on it WITH A BATTERY!! How can we justify a power chorded Deskphone with android 7?

The only way to solve this is to dump it or use it as a digital frame which shows pics of your loved ones or weather display. Anyway this is precisely why we don't support Android on Deskphones. Better get a smartphone, and buy a cool charging stand.. then you will have android 10. Anyway less space used on the desk.

I hope this helps. In no way do I mean to mock your situation. I understand your frustration perfectly. My focus is not directed at your problem - the crash. My focus is to make you understand to make better purchasing choices and to explain why we will never fix issues like this. If in doubt come here on the forums and we can assist you. And use our app on a smartphone.

 

[Evolute IT]

Just so you know, the GXV3370 has a later model 3380 and a 3350. They all use Android 7/8.

 

[Evolute IT]

Anyway this is precisely why we don't support Android on Deskphones.

And those? https://www.3cx.com/sip-phones/fanvil-c-series/

Yealink's Android phones are supported too.

 

[nb]

Yes - in fact this becomes like a product range collecting dust. Thanks for sharing Frederick. Proves that the road-map has reached a fork.
The direction of the resources will go to the app on the play store

 

[Evolute IT]

Yes - in fact this becomes like a product range collecting dust. Thanks for sharing Frederick. Proves that the road-map has reached a fork.
The direction of the resources will go to the app on the play store

I agree. I vote for more support of doorphones and facility devices (Grandstream new GSC series is pretty good) instead of more Android phones.

I still wanna see normal deskphones tho But I agree that when you get to that point, just buy a cheap smartphone lol Grandstream will be coming with something in that area soon, you should be on the look-out! It could be an awesome device for 3CX!

 

[nb]

And those? https://www.3cx.com/sip-phones/fanvil-c-series/

Yealink's Android phones are supported too.

one sec.. I need to clarify.
This thread is about leonardo_911 that installed the 3CX Android APP from the play store to an Android phone. that is the problem that cannot be supported.

You just shared a link of 3CX IP INTEROP support. This is going off track.

I mean of course we support android phones. If a manufacturer of phones does not use Android OS today, they have a big problem - and are probably dead like Cisco phones, Alcatel and other proprietary IP Phones

Today a manufacturer MUST make use of android. I mean even a company that makes lightbulbs, cars, watches and fridges needs to put android in there let alone a Deskphone.
But still a deskphone to me now, is like the dashboard of an old car. The interface is limited. And people are understanding that they prefer a smartphone + app on a base with a cool headset than a deskphone that never gets updated.

 

[Evolute IT]

one sec.. I need to clarify.
This thread is about leonardo_911 that installed the 3CX Android APP from the play store to an Android phone. that is the problem that cannot be supported.

You just shared a link of 3CX IP INTEROP support. This is going off track.

I mean of course we support android phones. If a manufacturer of phones does not use Android OS today, they have a big problem - and are probably dead like Cisco phones, Alcatel and other proprietary IP Phones

Today a manufacturer MUST make use of android. I mean even a company that makes lightbulbs, cars, watches and fridges needs to put android in there let alone a Deskphone.
But still a deskphone to me now, is like the dashboard of an old car. The interface is limited. And people are understanding that they prefer a smartphone + app on a base with a cool headset than a deskphone that never gets updated.

Oh I understand! No, definitely the app will not work correctly on those type of devices as the Android is modified to work with handset and SIP.

That means tho that the GXV series from Grandstream could be supported on 3CX, thus eliminating the need for the app itself. (Personally I would just provision it manually, but an official support by 3CX would fix that)

 

[nb]

Oh I understand! No, definitely the app will not work correctly on those type of devices as the Android is modified to work with handset and SIP.

That means tho that the GXV series from Grandstream could be supported on 3CX, thus eliminating the need for the app itself. (Personally I would just provision it manually, but an official support by 3CX would fix that)

It can work - I mean we can modify Android app to understand that a device will have a display and on hook with a handset. But there is no point. then use the internal dialer of Android. Why use an app to dial? Use the native dialer. Connect it via sip and go. This is why we don't even bother adding COMPLEX code to our app.
This new app is very very slim. inside it is clean and uses completely standard controls.
We want to keep it this way.

 

[Evolute IT]

It can work - I mean we can modify Android app to understand that a device will have a display and on hook with a handset. But there is no point. then use the internal dialer of Android. Why use an app to dial? Use the native dialer. Connect it via sip and go. This is why we don't even bother adding COMPLEX code to our app.
This new app is very very slim. inside it is clean and uses completely standard controls.
We want to keep it this way.

It is perfect this way! I agree 100%! That's why I'd like to see support for more GS devices! They almost all use Android as a base OS now. Some uses Linux for lightweight devices too.

The new iOS app is based on the same principles?

 

[nb]

It is perfect this way! I agree 100%! That's why I'd like to see support for more GS devices! They almost all use Android as a base OS now. Some uses Linux for lightweight devices too.

The new iOS app is based on the same principles?

No no the new ios client is based on SWIFT.. and it is fast!!
It is faster than our own Android client I must say. Android at a point is going to become full of if else condition - If huawei do this, If samsung do this, if nokia exit..else do this (Assuming its a pixel)

ios is different bro. iOS is standard - and if you use SWIFT which is the language that Apple now recommends, the app flies.. Swift is the modern language, clean syntax and API's are easier to maintain.

For example the telecom api (check here if you have not seen this and give me your feedback comments section

) is good yes, but since Android can be modified, manufacturers decide to support 1 portion of it.

iOS is not like that. SO the app is more PREDICTABLE.

 

[Evolute IT]

No no the new ios client is based on SWIFT.. and it is fast!!
It is faster than our own Android client I must say. Android at a point is going to become full of if else condition - If huawei do this, If samsung do this, if nokia exit..else do this (Assuming its a pixel)

ios is different bro. iOS is standard - and if you use SWIFT which is the language that Apple now recommends, the app flies.. Swift is the modern language, clean syntax and API's are easier to maintain.

For example the telecom api (check here if you have not seen this and give me your feedback comments section

) is good yes, but since Android can be modified, manufacturers decide to support 1 portion of it.

iOS is not like that. SO the app is more PREDICTABLE.

Can't wait to try it! I've coded in Swift before and I have to agree, it is just awesome! I just hope videocalls work even through the tunnel or SBC! Currently doesn't seem to work other than locally.

As for Android, I know it's a mess. I just wish they all stuck with a standard but they did not so I can imagine how many if/else there is in the code!

 

[nb]

Can't wait to try it! I've coded in Swift before and I have to agree, it is just awesome! I just hope videocalls work even through the tunnel or SBC! Currently doesn't seem to work other than locally.

As for Android, I know it's a mess. I just wish they all stuck with a standard but they did not so I can imagine how many if/else there is in the code!

But voicemails work perfectly with tunnel. What is the problem? I just tried this now and it works..
Can you explain? Or open a new thread and we can discuss it..

 

[Evolute IT]

But voicemails work perfectly with tunnel. What is the problem? I just tried this now and it works..
Can you explain? Or open a new thread and we can discuss it..

I can't get videocalling to work between my videophone (connected through SBC) and either webclient or other SIP phones connected in STUN or over another SBC.

Call uses H.264 and I know the app uses VP8/9 but the Webclient works with H.264 tho.

 

[nb]

I can't get videocalling to work between my videophone (connected through SBC) and either webclient or other SIP phones connected in STUN or over another SBC.

Call uses H.264 and I know the app uses VP8/9 but the Webclient works with H.264 tho.

Sorry - I misread. Apologies.
Video works only from vp8 to vp8. A call behind phone with SBC to webclient means that you have H264 to Vp8. This is not going to work.

 

[Evolute IT]

Sorry - I misread. Apologies.
Video works only from vp8 to vp8. A call behind phone with SBC to webclient means that you have H264 to Vp8. This is not going to work.

So when a doorphone is dialed via the Webclient, it's not using H.264? I thought it was what it was using. Could it be possible to allow pass-through of video? Just like VP8 works.

 

[nb]

So when a doorphone is dialed via the Webclient, it's not using H.264? I thought it was what it was using. Could it be possible to allow pass-through of video? Just like VP8 works.

I am not sure because then how can you see the video? You need to have common codecs.
So if you are using webclient, then you are using vp8 to vp8. Video is too heavy to be Transcoded. And if codecs are not common, you cannot get 2 way video unless they are both talking the same codec.

Does it work? Remove the tunnel at least. Try local so we can understand what is happening.

 

[Evolute IT]

I am not sure because then how can you see the video? You need to have common codecs.
So if you are using webclient, then you are using vp8 to vp8. Video is too heavy to be Transcoded. And if codecs are not common, you cannot get 2 way video unless they are both talking the same codec.

Does it work? Remove the tunnel at least. Try local so we can understand what is happening.

Calling works between local devices or when using STUN across the board. It does not work when the SBC is in the way.

So all these doorphones (https://www.3cx.com/blog/voip-howto/door-phone/) uses VP8 only?

 

[nb]

Calling works between local devices or when using STUN across the board. It does not work when the SBC is in the way.

So all these doorphones (https://www.3cx.com/blog/voip-howto/door-phone/) uses VP8 only?

yes because the tunnel encapsulates data and proxies it.
Look if you see 2 way video then the doorphone has the vp8 codec inside. And I can tell you from now that the webclient only works with vp8. (and vp9 but till now it is rarely used). So if you see video in the webclient, you have the sender sending vp8.

Now when you put the phone on tunnel, then it makes a traffic stop to a localhost proxy. And since we do not transcode the video, then this breaks the direct handshake of the 2 way video. So yes - it should not work. For this case do not use tunnel. Just use the stun option or vpn it at least so it looks like a local connection to the pbx. You can do that as well.

 

[Evolute IT]

yes because the tunnel encapsulates data and proxies it.
Look if you see 2 way video then the doorphone has the vp8 codec inside. And I can tell you from now that the webclient only works with vp8. (and vp9 but till now it is rarely used). So if you see video in the webclient, you have the sender sending vp8.

Now when you put the phone on tunnel, then it makes a traffic stop to a localhost proxy. And since we do not transcode the video, then this breaks the direct handshake of the 2 way video. So yes - it should not work. For this case do not use tunnel. Just use the stun option or vpn it at least so it looks like a local connection to the pbx. You can do that as well.

Yeah, the goal was to have videocalls between different sites with SBC.

Do you know of video deskphones supporting VP8? Grandstream does not.

And even the proxy can not just forward the video INVITE just like it does with VP8 or there's the licensing issue even if only passing through?