Created attachment 660920 [details] debug output while sending OPTIONS on disabled account Description of problem: Ekiga continues to send REGISTER packets for disabled account Version-Release number of selected component (if applicable): ekiga-4.0.0-1.fc17.i686 How reproducible: Always for certain accounts Steps to Reproduce: 1. Start ekiga 2. Disable nextiva account (3rd party voip) 3. Actual results: REGISTER packets continue to go out Expected results: no more communication with that SIP account Additional info: Attaching debug output
Created attachment 660921 [details] host and port packet trace of OPTIONS while disabled
Can you add details from "rpm -q ekiga opal ptlib"
Created attachment 660966 [details] packet trace of OPTIONS while disabled Providing full packet trace. SIP packets are actually OPTIONS, not REGISTER. The strange thing is, the OPTIONS packet is using id 'stuart' - but that is NOT the id configured in ekiga for the account!
Stuart, I do not understand, please be precise. Do you see OPTIONS and REGISTER packets when starting ekiga with disabled accounts? Here with disabled accounts no such packet is exchanged. In your debug output I see that you have an enabled account, so it is normal that you see REGISTER and OPTIONS packets.
I disabled the account after starting. Actually, when I stopped Ekiga, the account *was* disabled. But when I started Ekiga again, it enabled it again by itself, so I had to disable it again. I will try a few more times to try and get it disabled from the start.
Aha, maybe there is an issue if you disable an account *while* it is registering.
Even after it has registered, it continues to send the OPTIONS packets every 10 seconds - including after it is disabled.
(In reply to comment #7) > Even after it has registered, it continues to send the OPTIONS packets every > 10 seconds - including after it is disabled. But only for the nextiva account. The diamondcard and ekiga.net accounts work as you'd expect. Nextiva keeps saying "not allowed" to the OPTIONS requests, but ekiga keeps sending them - even after disabling.
Stuart, give me the -d 4 output and precise the exact steps you do for the bug to happen (for ex. is the account disabled upon starting or do you disable it from ekiga)? And in general, do not tell me all the cases where the bug appears, but just give me a log where the bug appears.
I already gave the log where the bug appears AND a pcap trace in case you didn't believe me about the OPTIONS continuing to get sent.
Created attachment 662555 [details] Screenshot of unregistered account sending OPTIONS packets Here is a screenshot showing that ekiga shows account Unregistered (although that does appear in the log I sent as well). It also show packet capture showing just the Options packets since Unregistering. They continue every 10 seconds.
Created attachment 662556 [details] Yet another debug output of sending options while disabled Got Ekiga to start with account disabled. It does NOT send the options packets when nextiva account is disabled at startup. Next, I Register the nextiva account (still on the same log). It starts sending OPTIONS every 10 seconds (even though refresh is 3600). I Disable the account. It continues to send OPTIONS every 10 seconds. I Quit the program. Silence at last!
Created attachment 662557 [details] packet trace of OPTIONS while disabled
(In reply to comment #12) > Created attachment 662556 [details] > Yet another debug output of sending options while disabled Sorry for being snippy. Since some of the problems I've reported went away the next business day, it makes since to confirm that it is still happening.
(In reply to comment #12) > Created attachment 662556 [details] > Yet another debug output of sending options while disabled > > Got Ekiga to start with account disabled. It does NOT send the options > packets when nextiva account is disabled at startup. Next, I Register the > nextiva account (still on the same log). It starts sending OPTIONS every 10 > seconds (even though refresh is 3600). OPTIONS packets are sent because firewalls remove associations ("connexions") between you and registrar after some time of inactivity, so in order to keep them open we send regularly OPTIONS packets. They are different than REGISTER packets, which have a refresh of 3600 seconds for ex.
... so even if OPTIONS have 3600 sec Expires, this time is used for the registrar, whereas we send them each 10 sec to keep associations open on firewalls.
(In reply to comment #16) > ... so even if OPTIONS have 3600 sec Expires, this time is used for the > registrar, whereas we send them each 10 sec to keep associations open on > firewalls. so the two questions I have on this are: 1) what has changed here since 3.2.x 2) isn't that the point on stun to deal with firewalls (yes I know some is differences for calls point to point vs registration)?
http://git.gnome.org/browse/ekiga/commit/?id=90446c1a6 : before that we used empty packets, whereas now we use standard OPTIONS packets. I noticed the error, you are right. I think this is because OPTIONS are not accepted by that registrar, and this confuses ekiga or opal. I am still investigating.
Sorry, I answer too fast... For point 2), stun does not deal with this. stun is about a few packets exchanged between your client (ekiga) and some server in the beginning to obtain just your public IP address.
(In reply to comment #12) > Created attachment 662556 [details] > Yet another debug output of sending options while disabled > > Got Ekiga to start with account disabled. It does NOT send the options > packets when nextiva account is disabled at startup. Next, I Register the > nextiva account (still on the same log). It starts sending OPTIONS every 10 > seconds (even though refresh is 3600). I Disable the account. It continues > to send OPTIONS every 10 seconds. I Quit the program. Silence at last! Could you check the patch at http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=revision&revision=28849 and tell if it fixes your problem or not? In both cases give us the -d 4 log.
Any news?
Just getting to this. It is compiling now. I will test in the morning.
Created attachment 680361 [details] ekiga -d 4 output after patch Ok, applied patch to create opal-3.10.9-3b.fc17.i686 and updated. The problem is not fixed. I started ekiga with all accounts disabled. No SIP packets - good. I enabled the Nextiva account (I had already verified that ekiga.net still works correctly) and it registered and started sending OPTIONS every 10 seconds - good. I disabled Nextiva and it still sends OPTIONS every 10 seconds - bad.
Good, thank you! Opal developer thought well, it is sent because of SUBSCRIBE, not REGISTER. I will contact him again.
I did notice that while enabled, it send *two* OPTIONS packets every 10 seconds. After disabling, it sends only one every 10 seconds. Perhaps one OPTIONS is for REGISTER (and goes away when disabled, as it should) and the other is for SUBSCRIBE (while keeps going).
Exactly!
ptlib-2.10.10-1.fc17,opal-3.10.10-1.fc17,ekiga-4.0.1-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ptlib-2.10.10-1.fc17,opal-3.10.10-1.fc17,ekiga-4.0.1-1.fc17
ptlib-2.10.10-1.fc18,opal-3.10.10-1.fc18,ekiga-4.0.1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ptlib-2.10.10-1.fc18,opal-3.10.10-1.fc18,ekiga-4.0.1-1.fc18
Package ptlib-2.10.10-1.fc17, opal-3.10.10-1.fc17, ekiga-4.0.1-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ptlib-2.10.10-1.fc17 opal-3.10.10-1.fc17 ekiga-4.0.1-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2890/ptlib-2.10.10-1.fc17,opal-3.10.10-1.fc17,ekiga-4.0.1-1.fc17 then log in and leave karma (feedback).
ptlib-2.10.10-1.fc18, opal-3.10.10-1.fc18, ekiga-4.0.1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
ptlib-2.10.10-1.fc17, opal-3.10.10-1.fc17, ekiga-4.0.1-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.