> where would i find this daemon log to see what is in it? You can get the log by launching the daemon in the terminal with the options "-d -c" before launching the front end UI. To do this, first quit Ring and make sure there isn't an instance of the daemon still running (you can do "killall dring") to make sure. Then launch dring (on a 64 bit ubuntu this should be "/usr/lib/x86_64-linux-gnu/dring -d -c"). Afterwards launch the front end.
> @ring team, what can cause 100% call failure after 45..90s ? I've found that I can reproduce this failure with the use of a virtual machine, but only with the ip2ip account. If the vm is setup with the network set to NAT, if I make an ip call to another machine, the call goes through, and I receive the video from the other machine on the vm; however, the text messages only work in one direction (vm to other machine) and after about 33 seconds, the call will go into "failed" state on the other machine but will continue on the vm. I do not get the same behaviour using a Ring account, howver; in fact, everything work well... so I'm not sure if this failure is due to the same problem(s). -stepan ----- Original Message ----- From: "Doug Stewart" <[email protected]> To: "Guillaume Roguez" <[email protected]> Cc: [email protected] Sent: Monday, November 2, 2015 10:31:17 AM Subject: Re: [Ring] new user problems On Mon, Nov 2, 2015 at 10:16 AM, Guillaume Roguez < [email protected] > wrote: 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 Thanks Guillaume I am the one having the problems. I am on Ubuntu 15.10 where would i find this daemon log to see what is in it? Doug Stewart -- DAS _______________________________________________ Ring mailing list [email protected] https://lists.savoirfairelinux.net/mailman/listinfo/ring _______________________________________________ Ring mailing list [email protected] https://lists.savoirfairelinux.net/mailman/listinfo/ring
