Request non-trickle ICE
Asterisk doesn't really handle tricked candidates very well, it can
work, but better to not when the client can avoid it.
Add XEP-0353 store hint to JMI messages
To make sure they get into MAM, offline storage, etc
Rename binary to make it easier to install in shared spaces
cryptonite 0.30 build fails on debian buster
Seperate presence/disco for the gateway itself
Add support for textbase10
Route IQResult and IQError to the correct full JID
Remove unused dependencies
Reply to all IQs as required by RFC
Import asterisk config changes from production
Handle Session Terminate When in Propose State
If a person calls us, we can make a proposal to have the phones ring.
But if they hang up, we're currently just sending them the session
terminate, when they don't actually have a session.
And so they ignore that, and the phone keeps ringing.
Similarly, if there are no resources online, the person on the other end
may hear it ring for a bit and then they'll stop for some reason.
Later, when the user comes back online, they'll be sent the messages
they missed while they were gone, including the session proposal, and
the phone will start to ring for them, no matter how long ago the phone
If they answer it, it'll be an error.
Not ideal, altogether.
Now, when the other side hangs up and we're still in the proposal state,
we retract the proposal, which means it will stop ringing in the online
case, and the user will know the phone call ended in the offline case.
Fix Hlint Suggestions
I basically just did what it asked me to, besides adjusting their
suggestions to our formatting.
Fix GHC Warnings
We have warnings turned on, so we may as well get to a clean base-state.
All of these type signatures came from the compiler's warning text
Similarly, the imports were listed as redundant.
Then there were a few name shadowings, mostly "s" and "init".
Finally, there were some unused variables from the pattern matches.
The version of base specified isn't available on my system, so when I
updated it (and a few other libraries when they also errored) it now
seems to have built fine.
So it must be fine!
Use type=chat so that carbons will relay to all target resources
It turns out that the Carbons spec says you should only use carbons for "IM
like" things, such as messages of type=chat or with a body. So there was a case
where if you had XEP0353-supporting clients connected but they had a lower
priority than other clients that were connected, the server would send those
clients the proposal message and carbons would not kick in and nothing would
So now we use type=chat. Even though it's not a chat, it's not in the context of
your chat, it's just an inbound phone call. But that's a moral question and in
practise this is also what Conversations does and it fixes the problem.
Thanks so much to psycotica0 for all of the investigation work that lead to this