Seperate presence/disco for the gateway itself
Route IQResult and IQError to the correct full JID
Reply to all IQs as required by RFC
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.
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
Instead of crash on bad stanza, at least log it
Fallback to direct initiate when no Jingle Message Initation support
Check for a message initiation supporting resource, if none then send to the
most available resource.
TODO: Should only send to most available resource that supports jingle rtp audio.
Error payload is often last
Asterisk seems to care about the payload being <error/> and not just the
type="error", which is probably a bug in asterisk, but this whole thing is a
workaround for missing asterisk stuff so here we are.
This code is garbage and will have to be rewritten.
When paired with the Asterisk setup, inbound calls to sip:email@example.com
end up as working Jingle calls (tested only with Conversations) to the target
Declining the call, hanging up, and errors from calling bad JIDs all are handled.