Hi all,
> @ring team, what can cause 100% call failure after 45..90s ?
I've often seen this kind of question: what's happening when I do a call, and
why it fails?
So this is the long answer :-)
When calling a RingID number, following steps happen in order:
1/ The caller initializes a ICE transport:
- this step blocks until all ICE "services" are initialized/contacted
(Host/UPnP/STUN/TURN)
- this step can fail: initialization fails after 5 seconds
(ICE_INIT_TIMEOUT in src/ringdht/ringaccount.cpp)
2/ The caller does a DHT put with its local ICE attributes as value and the
callee RingID as key (well a bit more complex, but it's the concept).
- this step is asynchronous
- this step can fail: bound on DHT backend failures.
3/ The caller adds a listen point on DHT for the callee's response on our put.
- this step is asynchronous
- listen success callback starts ICE negotiation on callee ICE attributes
4/ The call ID is put into a pending list: a paced loop checks the ICE
transport status.
- if ICE negotiation succeed before 60 seconds (ICE_NEGOTIATION_TIMEOUT in
src/ringdht/ringaccount.cpp) the call goes into connected state
and SIP protocol proceed as in IP2IP/SIP account.
- after this time: the call is marked as failed and removed.
On the callee, a similar process happens: it starts from a DHT listen that
trigs when a ICE msg comming (see point 2/).
In short: when a ICE is initialized at the caller side, the callee has 60
seconds to:
- receive the DHT msg
- start its own ICE transport
- send back its local ICE attributes to caller
- negotiate ICE transport with caller
Only both daemon logs (at each point) can answer where is the problem.
Regards,
Guillaume
_______________________________________________
Ring mailing list
[email protected]
https://lists.savoirfairelinux.net/mailman/listinfo/ring
