GNOME Bugzilla – Bug 553595
cannot connect to Asterisk server
Last modified: 2008-09-25 17:49:42 UTC
I've been using the nightly snapshots of ekiga 3.0 in place of my previously working distribution (Ubuntu, hardy) supplied ekiga 2.x. The snapshots have been able to register and authenticate to my Asterisk server successfully and can receive calls from Asterisk with no problems, however I can't seem to make outgoing calls. I will attach a "-d 4" debug log starting from the call-out attempt until I quit ekiga.
Created attachment 119311 [details] -d 4 debug of ekiga trying to call out via Asterisk
You are not registered to the Asterisk server, so Ekiga can not authenticate. Isn't that the problem ?
I should be registered. I don't think I would even get incoming calls without having registered. Certainly when I bring up the Accounts window I show as "Registered" (i.e. a checkbox) to both "ekiga.net SIP Service" as well as "Local PBX", which is the host "pbx" (10.75.22.8) in that debug attachment.
Please post the full log.
Created attachment 119323 [details] -d 4 debug of ekiga running and trying to call out via Asterisk
The problem seems to be that you have 3 different network interfaces for the same network. Ekiga sends thus an INVITE request through each of them, but all of them reach Asterisk, which reacts badly.
Yes, indeed, I do have a couple of aliases. That was going to be the subject of another bug. :-) Is there any way to have ekiga only use one of them?
We tend to automate things at maximum, so I don't think it is possible. Perhaps in 3.2 we will reintroduce a setting, but in that case if you listen only on one interface, there is no way to connect through a VPN and to the Internet at the same time. I'll discuss with Robert, but I think the problem is on Asterisk side. One thing we could improve is that as soon we get an answer for one interface, we do not try others.
Decreasing severity to "normal".
(In reply to comment #8) > We tend to automate things at maximum, Which for common/normal situations, I completely agree with... > so I don't think it is possible. Perhaps > in 3.2 we will reintroduce a setting, but in that case if you listen only on > one interface, there is no way to connect through a VPN and to the Internet at > the same time. Hrm. I must not be envisioning the use case where multiple IPs on the same subnet are needed for access to a VPN. The reason I have multiple IPs is for QOS. With protocols like bitorrent, etc. the only way to get reliable QOS is to have your torrent software (and only your torrent software) bind to/use a specific address and then set that address up in your QOS priorities. Now, with ekiga binding to all addresses what I actually find is that it's using my "for torrents" address for outbound connections (i.e. to ekiga.net) and thus getting it's traffic shunted into the "low priority" QOS band. Not good at all for VIOP. So somehow there needs to be some kind of differentiation. Maybe in the spirit of automating as much as possible, maybe when ekiga discovers that there are multiple local addresses it pops up a dialog asking which one(s?) to bind to/use [for the various available registrars]. > I'll discuss with Robert, but I think the problem is on Asterisk side. One > thing we could improve is that as soon we get an answer for one interface, we > do not try others. Maybe. It doesn't smell right, but it's one option to explore certainly.
"Maybe in the spirit of automating as much as possible, maybe when ekiga discovers that there are multiple local addresses it pops up a dialog asking which one(s?) to bind to/use [for the various available registrars]." Well, for 3 registrars, it would mean many popups ;-) We also support interfaces going up and down, which makes things even harder. One thing you could try is to make sure that the routes are well-defined and exclusives, ie, your bittorrent interface can only be used to route the trafic to and from bittorrent servers. If not done at the routing level, it can be done with iptables. To answer your VPN question, many persons have a client allowing them to connect to the VPN of their company when being at home or travelling. That is why we need to be able to support several interfaces at the same time. That's so complex for something so simple....
(In reply to comment #11) > > Well, for 3 registrars, it would mean many popups ;-) Yeah. That is the downside. I'm still not envisioning the VPN use case for using multiple IPs in the same subnet though. There is a usecase similar to the one I outlined for QOS though. But with SIP it should be possible to QOS without the need for a dedicated IP address. > We also support interfaces going up and down, which makes things even harder. Well, the IP->registrar could have a "don't ask me again" checkbox in which case it remembers the local IP->registrar mapping and just applies it when an interface/address comes up. > One thing you could try is to make sure that the routes are well-defined and > exclusives, ie, your bittorrent interface can only be used to route the trafic > to and from bittorrent servers. Bittorrent servers? Bittorrent is a P2P protocol so any node on the Internet can be a potential bittorrent end point. There is no way to do policy-based routing based on IP addresses for bittorrent -- which is why binding a local address for it is the only sure method of QOSing it. > If not done at the routing level, it can be > done with iptables. It can't be done at all. > To answer your VPN question, many persons have a client allowing them to > connect to the VPN of their company when being at home or travelling. Sure. I have several such things. None of them allocate an ip alias (i.e. a second ip address in/) my "home" subnet to operate though. > That is > why we need to be able to support several interfaces Ahhh. Several IPs in the same subnet != several interfaces. > at the same time. That's > so complex for something so simple.... Was a specific use-case cited for this multiple-ips-in-the-same-subnet-VPN situation? I wonder if there has been some kind of misunderstanding.
I consider eth0:1 to be a different interface than eth0. Hence the misunderstanding ;-)
(In reply to comment #13) > I consider eth0:1 to be a different interface than eth0. Ahhh. Technically speaking, it's not. It's an alias address on eth0 not at all unlike doing: # ip addr add 192.168.1.2 dev eth0 > Hence the misunderstanding ;-) But is the misunderstanding a deeper misunderstanding of the need to bind to all addresses in the same subnet for this VPN use-case? Maybe this whole problem can be eliminated by revisiting this VPN use case.
Unfortunately not... Robert and I have examinated the log, and it is an Asterisk bug : We send packets over each "virtual" interface (in this case three!) they all get to Asterisk. This is perfectly legal. This is called SIP forking and it is a safe way to make sure that things work in environnements with different IP addresses in different subnets (in your case, all 3 IP addresses are in the same subnet with the same routing). Asterisk then proceeds NOT to check if the second packet is from a different SIP dialog (as indicated by the From: field tag parameter) and returns "491 Request Pending" which means it thinks the second (and third) INVITE requests are re-INVITEs, not forked INVITEs. In forked INVITEs, the tag is different for each of them, so Asterisk should not suppose it is the same request. This could still work, except Asterisk then seems to get confused due to the authentication where the INVITE with credentials is also knocked back with "491 Request Pending" as one of the previous forked INVITE requests is still being processed, even though it will be knocked back too. The only thing you can do in this situation is to bind to a specific interface in Ekiga. Or get Asterisk to fix their problem... See bug #553810