search

mehrvarz / webcall-android

WebCall for Android - Web-Telephony P2P Messaging File-Exchange E2E-Encryption No-SIM
GNU General Public License v3.0
128 stars 14 forks source link

10 mins timer? #16

Closed andyb9 closed 1 year ago

andyb9 commented 1 year ago
webcall_2023-05-17_18-42-22

i dont know if this is an issue/bug but for me when i called a user using Windows Edge browser from the android app, there appears a counter on both screens on the bottom left which is counting down to zero and after a couple of warning beeps at about 1min and then in the last 15secs or so, the line then gets cut-off.

I'm saying this because in the description somewhere, it says we can talk for as long as we like, if so then why is there a builtin call timer?

mehrvarz commented 1 year ago

Hi! This is not a bug. As can be seen in the screenshot, one side of your 2way-link is relayed. This is causing the timeout. Please read this: https://timur.mobi/webcall/more/#relayed

andyb9 commented 1 year ago

Hi! This is not a bug. As can be seen in the screenshot, one side of your 2way-link is relayed. This is causing the timeout. Please read this: https://timur.mobi/webcall/more/#relayed

Thanks for your quick response.

Indeed one side of the 2way-link is definitely on Vodafone and there are firewalls etc also involved - we will try and see if we can resolve the 10 mins limitation.

Thanks for this very interesting app though, i am surprised lots more people are not raving about it. as it's a very convenient telephony alternative to say Whatsapp, Viber et al.

andyb9 commented 1 year ago

addendum: Also noticed a 20mins timer/call limitation on another call that came through as a relay/p2p call between two android phones (same make and model and both on android 11) , I assumed this is also to do with it being a relay call.

mehrvarz commented 1 year ago

I added an external link at the bottom of my text about Relayed connections. Please have a look. I also extended the timeout to 20min to make things a little less restrictive (temporarily). The real disadvantage of relaying is latency. I hope you can solve this.

andyb9 commented 1 year ago

I added an external link at the bottom of my text about Relayed connections. Please have a look. I also extended the timeout to 20min to make things a little less restrictive (temporarily). The real disadvantage of relaying is latency. I hope you can solve this.

Had a look at the external link and good to know about UDP hole punching to resolve NAT issues, thanks for that,

...however it seems our problem is mainly the ISP - i.e. two users are with Vodafone UK and another user is with EE UK, and the two users on Vodafone have firewalls on their android phones (so that's not helping either) and the EE user doesn't have a firewall and is using an Iphone so iOS not Android, when calls come through, the relay part of the connection is always with the android Vodafone users and the p2p part of the connection is with the Iphone EE connection which clearly points a finger at Vodafone as possible having a 'too strict' NAT setup as even with firewall turned off the connection is still relayed, unfortunately all the phones are using mobile data and hotspots combinations setup to laptops etc and do not have the option to try out UPD hole punching as suggested on the external link webpage.

Nevertheless, increasing the timeout limit helps a lot, as now they can have longer calls/connections before timeout, so for now that will have to suffice as even though calls are relay/p2p latency is not really a problem.

Thanks for all your help in fully understanding the issues are local and not issues with WebCall and for the possible solutions.

Keep up the good work :)

mehrvarz commented 1 year ago

and do not have the option to try out UPD hole punching

The info about UDP hole punching was not meant as something to try out next. It is the very thing that is failing. WebRTC engines always "punch holes" into NAT's/FWs in order to enable P2P. This is normal technology practice.

If disabling a local FW gives you full P2P, then knowing about UDP hole punching can help you find the specific FW setting you need to apply, to let you do P2P with the FW running.

If the constrain is external (ISP NAT), you can do little about it other than switching the ISP. P2P is failing in about 10% of cases (or probably less). It used to fail in 30% of cases only a few years ago. The number of NATs that are too strict for P2P is (slowly) shrinking.

If you find out more, please let me know!

andyb9 commented 1 year ago

WebRTC engines always "punch holes" into NAT's/FWs in order to enable P2P. This is normal technology practice.

Indeed, thought NAT punch 'hole-ing' was a hacking solution to NAT issues, thanks for clarifying.

to let you do P2P with the FW running.

Will try to see if we can at some point do some further tests by turning off the firewalls on one of the android phones then using an EE sim to proof to a greater degree of certainty that it's Vodafone NAT that is the culprit.