GNOME Bugzilla – Bug 592012
P-Registrar-Error: Too many registered contacts
Last modified: 2009-09-23 19:49:01 UTC
Created attachment 140919 [details] ekiga registration pcap Failing to register to a public popular SIP server in Czech Republic. Feel free to use the account for testing purposes. I have turned off the registrations to it now. SIP service provider: http://www.802.cz/ SIP server: sip.802.cz username: 910807540 password: ekiga returned error packet: Server: ecomPhoneServer P-Registrar-Error: Too many registered contacts Expecting due to the 4 REGISTER packets sent there for my 4 local IPv4 IPs. The server may receive multiple registrations from multiple IPs: 89.250.240.59: openvpn endpoint which is used for the default route. 192.168.66.2: Valid IP which gets NATted to some other IP on public Internet. This IP gets used for transport of openvpn for 89.250.240.59. 172.20.0.1, 192.168.67.2: Invalid IPs for the Internet. ekiga-3.2.5-2.fc11.x86_64 opal-3.6.4-2.fc11.x86_64 ptlib-2.6.4-2.fc11.x86_64 (twinkle-1.4.2-2.fc11.x86_64 registers fine.)
Created attachment 140920 [details] twinkle registration pcap
I'm not sure there is something we can do. The only workaround I can think of would be to add back the ability for Ekiga to listen to one interface only.
I think Robert added an optio to OPAL to only have one registered contact. Eugen, do you remember it ? That was something to add to the registrar ?
This is the limited patch. It was committed only on trunk about two weeks ago. See http://www.mail-archive.com/ekiga-devel-list@gnome.org/msg02981.html (and all the thread).
Created attachment 142439 [details] output of ekiga -d 5 -u 4 When trying to register to the same service with ekiga build for testing bug 586531 (which was fixed, thank you!), I couldn't register either, dialog window claimed "Internal Server Error" (which is a non-sense -- I can register there both with twinkle and linphone).
Created attachment 142440 [details] tcpdump of the registration process
(In reply to comment #5) > Created an attachment (id=142439) [details] > output of ekiga -d 5 -u 4 > > When trying to register to the same service with ekiga build for testing bug > 586531 (which was fixed, thank you!), I couldn't register either, dialog window > claimed "Internal Server Error" (which is a non-sense -- I can register there > both with twinkle and linphone). Matej, do you want to say that with a previous versin of ekiga the registration worked? If yes, what version?
Eugen, I think it is the remote server not allowing multiple contacts. In that case, Ekiga can work around it thanks to the %something modifier in the host name.
The situation was that Robert did observe some NAT issues with the "%LIMITED" Opal commits 23102 + 23104, so they were not promoted to stable. Additionally Ekiga stable needs a different patch than master. As I am hit by a provider which bails out when it sees a local IP I backported the Opal and Ekiga changes to stable and use them regularly for my Win32 previews. I do not know whether they help here. You can find my patches in http://wwwuser.gwdg.de/~mrickma/ekiga/ekiga_build-3.2.pre6.tgz . They are the ekiga_alienreg.diff and opal_alienreg.diff and are not Win32 specific. For the interface restriction to become effective you have to place the string "%limit" (without the quotes) into the name of the respective account. Michael
(In reply to comment #7) > Matej, do you want to say that with a previous versin of ekiga the registration > worked? If yes, what version? Sometimes in 2.* area maybe ... ekiga didn't work for me at all in 3.* versions so I haven't tried it too much.
Another downstream bug related to this issue: Some SIP providers return 403 Forbidden (No RFC 1918 IP allowed) https://bugs.launchpad.net/ekiga/+bug/362891 Relevant debug output: 2009/04/01 20:02:57.405 0:12.079 Opal Liste...0xb53beb90 SIP PDU received: rem=udp$212.227.15.231:5060,local=udp$79.209.54.40:61224,if=192.168.2.101%wlan0 SIP/2.0 403 Keine RFC1918-IPs erlaubt CSeq: 1 REGISTER Via: SIP/2.0/UDP 79.209.54.40:61224;branch=z9hG4bK04c5cbff-541d-de11-9f94-001b9e55716e;rport=61224 Server: UI OpenSER From: <sip:499419999999@sip.1und1.de>;tag=d88bc7ff-541d-de11-9f94-001b9e55716e Call-ID: 2cde27fe-541d-de11-9f94-001b9e55716e@clarissa-laptop To: <sip:499419999999@sip.1und1.de>;tag=329cfeaa6ded039da25ff8cbb8668bd2.ad0d Content-Length: 0
I think this has just been committed to stable too, thanks to Robert and Michael. Please reopen if not.
http://git.gnome.org/cgit/ekiga/commit/?h=gnome-2-26&id=067463bf06eb11040122520a1f53c2e724fddb63
With ekiga-3.2.6 (Fedora 12) I still see the same problem on the sent Contact data. Tried various account names (like "910807540@sip.802.cz%limit").
Sigh, could you attach the -d 4 output?
Hi, I think the "%limit" string has to be put in the registrar field in the account window, isn't it?
The registrar is freephonie.net for ex. It should be in the account name...
Oh, it works but one needs to restart Ekiga after changing the account name. Still I thought it will be autodetected. Thanks for this fix but still such a cryptic feature is like non-existing for normal users not looking up Bugzilla.
Indeed, we are aware of the usability issue, but we were too short on time/possibilities because of the Gnome release/various freezes.
Moreover, it seems to be a limitation of registrars, not of ekiga.