Signal-ios: Calls failing to connect

[mailinglists35]

• [ ] I have searched open and closed issues for duplicates

---

Bug description

Describe here the issue that you are experiencing.

Steps to reproduce

• using hyphens as bullet points
• list the steps
• that reproduce the bug

Actual result: Describe here what happens after you run the steps above (i.e. the buggy behaviour)
Expected result: Describe here what should happen after you run the steps above (i.e. what would be the correct behaviour)

Screenshots

Device info

Device: iDevice X
iOS version: X.Y.Z
Signal version: Z.Y

Link to debug log

https://debuglogs.org/a14a3c12b0d72a1903cc0fb87569402fec1f69c7d0932d1c7a908800c3d91851.zip

[mailinglists35]

filing the template on phone is terrible. hopefully the debug log contains all the answers.
opening the app receives call, but with screen locked I receive neither the call nor the missed call notification. happening both with low power mode and without

[mailinglists35]

only when receiving call from android. i receive call from ios very well

[littleporkchop]

I’ve noticed that this happens more frequently when I’m using a VPN

[michaelkirk-signal]

@littleporkchop - if you and the caller can both submit a debug log right after this happens, we can take a look.

We'll need logs from both sides.

And please include the time that the missed call was dialed.

[rex4539]

Calling someone, they don't see the call notification on the lock screen. Only afterwards they notice they had a missed call within the app.

Same when receiving a call. Nothing is shown on screen. Only afterwards you find a missed call within the app.

It appears the app does not integrate with the iOS notification system and tries to handle everything in-app which results in very bad user experience.

[michaelkirk-signal]

It appears the app does not integrate with the iOS notification system and tries to handle everything in-app

That is incorrect.

results in very bad user experience.

That much I believe.

Can you get a debug log from yourself and the other party right after a call fails?

Would anyone who is experiencing this be willing to install a debug build to help diagnose the issue? If so send an email to [email protected] with the subject "GH #3249 - calling issues debug build".

[rex4539]

I’m unable to get logs from the other party but here are mine.

There were multiple call attempts between 20:00-20:02

https://debuglogs.org/27c1986cf4b049aea20342aac466dc69c2e08b272ec581771504091db65d5222.zip

[mailinglists35]

unable to call android to ios, and neither viceversa

debug logs from ios and android around the attempt:

https://debuglogs.org/a7a7c0a49fa4cd4ab3612c90a9d9ea1eed90f4e3394a9b61584790d44fb21f7f.zip1 (remove "1" after zip)

https://debuglogs.org/3c56658c63c75e24ef6f442113f969a5677a40caada58eff88f27f250492f2051 (remove 1 at the end, anti search engine and data scavengers protection)

[michaelkirk-signal]

@mailinglists35 - It looks like you're already on the beta, but not on the latest beta, released about 12 hours ago. Could you update your client and let me know how it goes?

[michaelkirk-signal]

To be clear, this isn't a generic "make sure you're always on the latest version" message - there was a fix in the latest beta specific to an issue shown by your debug logs.

[mailinglists35]

great, thanks. appears to be fixed ios to ios, but I will also verify tomorrow (gmt+2 here) ios to android / android to ios.

[michaelkirk-signal]

Thanks @mailinglists35!

[mailinglists35]

verified android-to-ios and viceversa, fixed, thank you!

[mailinglists35]

this has just happened again.
latest ios app store called testflight 2.29.2 and testflight did not receive call, but only missed call ios notification.
Testflight called appstore and received no answer.
https://debuglogs.org/2c7081ee91975d6aab799f40df33407d397a9c5e5d63076a9b3a54b49d3f781c.zip1 (remove 1 at the end)

[mailinglists35]

after updating from 2.29.3 to 2.29.3.2 it works again - was this a regression?

[mailinglists35]

again calls are not Ringing
2.30.2.9

https://debuglogs.org/b9f0dccc193ae26dea4f1541596bd6bc3ada5dc678576537b92e28c4e53f5c09.zip1

[mailinglists35]

aaaand fixed again in 2.30.2.11

[mailinglists35]

given the flapping nature of this issue, I'll leave it open

[mailinglists35]

@michaelkirk-signal, and once again stuck in connecting. text mesaage appears as delivered.

https://debuglogs.org/6242182f35314550c3792401483a53765f6ea235b29ac4a9a22d9995fc0945c7.zip1

2.30.2.11

[michaelkirk-signal]

Can we get a log from the person at the other end of the call as well?

On Oct 12, 2018, at 05:42, mailinglists35 [e-mail] wrote:

@michaelkirk-signal, and once again stuck in connecting. text mesaage appears as delivered.

https://debuglogs.org/6242182f35314550c3792401483a53765f6ea235b29ac4a9a22d9995fc0945c7.zip1

2.30.2.11

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[mailinglists35]

unfortunately the peer is not enrolled in testflight, I think he got the app store version with default settings.

[michaelkirk-signal]

Anyone can submit a debug log by going to settings > advanced > submit debug log, no enrollment in testflight required.

[mailinglists35]

2.30.2.16

https://debuglogs.org/922afcbab21a5123c05d2b31dda6b72251c57b129277bfffdea3da4b994961ed.zip1

[mailinglists35]

2.30.2.16 ios to app store ios

https://debuglogs.org/922afcbab21a5123c05d2b31dda6b72251c57b129277bfffdea3da4b994961ed.zip1

[mailinglists35]

latest testflight to app store fail:
https://debuglogs.org/f846d65eb765bab6180564c1ab8777f2c9f9b592c171d5f48006ffc5abfa7937.zip1

app store to testfail, call rings:
https://debuglogs.org/f7699a18cd1991cb60b00bce979d732e54c403c22f58726cd0da3061a55700ab.zip1

[mailinglists35]

@michaelkirk-signal managed to get a debug log from peer, see above

[michaelkirk-signal]

Thank you! I'll take a look soon.

[mailinglists35]

hi @michaelkirk-signal
any luck finding the culprit? i'm getting this every time. it's getting really frustrating.

[sierravictor806]

I will advise that after I changed it from routing all calls through the signal server it seems to work. That should not even be an option unless it works properly.

[mailinglists35]

I don't understand. It works for you via signal servers? or it doesn't?

[sierravictor806]

It does NOT work when routed through the Signal servers

[mailinglists35]

I have "always relay calls" switch turned off - and I never tried to turn it on, and with the switch turned off is my issue

[sierravictor806]

I see. I could not get calls to connect with calls routed through signal servers. Odd.

[mailinglists35]

same fail with updated testflight version

https://debuglogs.org/5fea0c0e39841e4fc4dd5b8a26033881e89f1dae4fc562e0b17d5499590ec358.zip1

[mailinglists35]

and on callee https://debuglogs.org/7e159c0123f836385c2970e7621b690bb180e8f21cb59069c4ae5eb4186d9dcb.zip1

[mailinglists35]

@michaelkirk-signal,
is there any hope for a fix/workaround for this anytime soon?

[michaelkirk-signal]

@mailinglists35 - Thanks for the logs.

I'm assuming you're talking about the call at about "2018/11/05 10:52:30:853" local time?

It seems like the caller didn't send a single ICE update. Were they on some kind of restricted network?

Are you the caller or the callee in those logs?

Do you know if the other party had enabled "always relay calls"?

[mailinglists35]

I always am the one referred to as "testflight" and the callee is referred as "app store"

we were next to each other, via 4G network, always relay calls enabled on both

On Nov 17, 2018 at 8:04 AM,

@mailinglists35 (https://github.com/mailinglists35) - Thanks for the logs.

I'm assuming you're talking about the call at about "2018/11/05 10:52:30:853" local time?

It seems like the caller didn't send a single ICE update. Were they on some kind of restricted network?

Are you the caller or the callee in those logs?

Do you know if the other party had enabled "always relay calls"?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/signalapp/Signal-iOS/issues/3249#issuecomment-439591548), or mute the thread (https://github.com/notifications/unsubscribe-auth/AB9YnnMmJXYjzNdXt8sNBS3Ue7cqiqXvks5uv6bcgaJpZM4TLHxN).

[mailinglists35]

one more fail latest testflight to appstore
both have "always relay calls" enabled
testflight on 4g, store on wifi

https://debuglogs.org/38b42f1728fceb5d95b9ee010f0c19ca8fb48ab987093843e8de0e6832201f63.zip-testflight

[mailinglists35]

and app store log https://debuglogs.org/4e1ecb7e80076b5b3fbde60ccd177babbaa230b4385305e82bf4f12d9e6c6962.zip-store

[ghost]

https://launchpadlibrarian.net/398226865/wireguard-tools_0.0.20181119-wg1~trusty_arm64.deb

[nucuuv]

I am seeing this as well: it usually takes about 10 to 20 attempts to get a call to “Ringing”, the rest get stuck in “Connecting”.

Looking at CallService.swift, it seems as if useTurnOnly is set to true if the user has requested this or if the peer is not in the system contacts. I have not granted Signal access to my system contacts, so I am guessing this causes the latter check to fail, making useTurnOnly true regardless of how “Always Relay Calls” is configured.

Secondly, doing some packet traces during some calls attempts, I noticed that stun1.l.google.com (the fallback STUN server) and turn1.whispersystems.org are resolved. For me, the latter resolves to turn-eu-central-1.whispersystems.org with addresses 18.184.143.105, 35.157.50.142, 52.58.122.141, 52.59.23.42 and 52.59.152.10.

Signal then fires off binding requests to stun1.l.google.com:19302 (which immediately succeeds) and then 52.59.152.10 at ports 80 and 443. The requests to 52.59.152.10 all fail with ICMP response Port unreachable, but that does not stop Signal/WebRTC from making repeat attempts. Presumably, the calls do not connect as the fallback server does not support TURN.

Subsequent calls continue to use 52.59.152.10, presumably due to the DNS cache of iOS, and fail as well.

Finally a while later, a new DNS request is made, resulting in a different address order, causing 52.58.122.141 to be picked instead. The binding responses then succeed and the call goes through.

If the above analysis is correct, I suppose the quick fix would be to simply remove any broken STUN servers from the DNS response, and the long term solution to do the name resolution before passing the servers to WebRTC (that is, present WebRTC with 18.184.143.105:80, 18.184.143.105:443, 35.157.50.142:80, 35.157.50.142:443, ... rather than turn1.whispersystems.org:80 and turn1.whispersystems.org:443; or do the same upstream).

In either case, I cannot stress enough how incredibly annoying this issue is.

[mailinglists35]

I have not granted Signal access to my system contacts

me neither!

[michaelkirk-signal]

This should now be resolved in production.

If you have calling issues in the future, could you please open a new issue with fresh debug logs instead of resurrecting this one? A lot of the details in this one are now irrelevant.

[mailinglists35]

again. testflight to play store.
skype rang successfully.
signal message was delivered successfully. but call remained in connecting rather than ringing

I can't get the debug log from the play store peer.

https://debuglogs.org/e84285aa0aa31af85c8a62e24a85d911ecd49b7b4e0fba8eb054d5bd94e3bcbd.zip1