Re: [Ekiga-devel-list] Sometimes Ekiga is not binding to the correct interface
On 02/10/11 10:59, Geeziard wrote: I am seeing the same problem on Windows with Ekiga 3.2.7. If I have the VMware bridging networks enabled, Ekiga send the IP addresses of those along in its register message, despite them being on a different subnet from the outgoing package, like: REGISTER sip:ekiga.net SIP/2.0 CSeq: 73 REGISTER Via: SIP/2.0/UDP X.X.X.X:5060;branch=xxx----;rport User-Agent: Ekiga/3.2.7 Authorization: Digest username=myn...@ekiga.net, realm=ekiga.net, nonce=, uri=sip:ekiga.net, algorithm=MD5, response= From:lt;sip:myn...@ekiga.netgt;;tag=2c3da863-4405-1910-894c-001150c429ef Call-ID: ----@MyComputer To:lt;sip:myn...@ekiga.netgt; Contact:lt;sip:MyName@X.X.X.Xgt;;q=1, lt;sip:MyName@192.168.139.1gt;;q=0.667, lt;sip:MyName@192.168.1.4gt;;q=0.334 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING Expires: 3600 Content-Length: 0 Max-Forwards: 70 X.X.X.X is my external IP, 192.168.139.1 is a virtual VMNet interface and 192.168.1.4 is my internal IP, the one that is in contact with my NAT-enabled router. I presume that Ekiga should not send the 192.168.139.1 part as it is on a different subnet from 192.168.2.1. (The netmask is 255.255.255.0 for both interfaces, I have checked! ;-) Is there any reason why the wanted IP address (the interface to bind to) cannot be configurable in the preferences? It would make my system work nicely and it would make it possible to use Ekiga on Linux VServer systems too as all VServer instances share the same network interfaces, making it impossible to have more than one instance of Ekiga running when it binds to all interfaces. When it does not work, I get no answers back from the router at all. Not a peep. With ekiga 3.3.2 there are two modes for what Contact field will have, and in latest ekiga (git/svn) there are three modes. They are tried automatically one after the other if registration fails. One of them is putting in Contact only the outgoing interface. I suppose it is what you want, is that right? -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Sometimes Ekiga is not binding to the correct interface
On Wed, Oct 14, 2009 at 07:45:49PM +0200, Damien Sandras wrote : Ekiga 3 binds to all interfaces. Yeah ok but it is not sending its RTP on the correct one. You can see in the traces that it is binding to 192.168.18.109 instead of 192.168.1.86. 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 OpalUDP Setting interface to 192.168.18.109%eth0 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 SIP Transaction timers set: retry=0.500, completion=1:00.000 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 OpalCon OnSetUpConnectionCall[j5b3316471]-EPsip[5c242127-27b7-de11-93d0-00215ae72d5f] 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 OpalEP OnSetUpConnection Call[j5b3316471]-EPsip[5c242127-27b7-de11-93d0-00215ae72d5f] 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 PWLib Ended thread 0xa279708 CallSetup:0xb39a0b90 2009/10/14 14:02:45.592 0:08.723 Opal Liste...0xb52beb90 OpalUDP Binding to interface: 192.168.18.109:5060 Then, the sip phone will either reject the call because it can't route any packets to 192.168.18.109 or simply not have audio. -- Alexandre Belloni ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Sometimes Ekiga is not binding to the correct interface
Le jeudi 15 octobre 2009 à 10:03 +0200, Alexandre Belloni a écrit : On Wed, Oct 14, 2009 at 07:45:49PM +0200, Damien Sandras wrote : Ekiga 3 binds to all interfaces. Yeah ok but it is not sending its RTP on the correct one. You can see in the traces that it is binding to 192.168.18.109 instead of 192.168.1.86. 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 OpalUDP Setting interface to 192.168.18.109%eth0 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 SIP Transaction timers set: retry=0.500, completion=1:00.000 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 OpalCon OnSetUpConnectionCall[j5b3316471]-EPsip[5c242127-27b7-de11-93d0-00215ae72d5f] 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 OpalEP OnSetUpConnection Call[j5b3316471]-EPsip[5c242127-27b7-de11-93d0-00215ae72d5f] 2009/10/14 14:02:45.591 0:08.722 CallSetup:0xb39a0b90 PWLib Ended thread 0xa279708 CallSetup:0xb39a0b90 2009/10/14 14:02:45.592 0:08.723 Opal Liste...0xb52beb90 OpalUDP Binding to interface: 192.168.18.109:5060 Then, the sip phone will either reject the call because it can't route any packets to 192.168.18.109 or simply not have audio. That's because the remote server accepts it. If it can't relay RTP, it should reject the INVITE request with unroutable RTP addresses. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Sometimes Ekiga is not binding to the correct interface
On Thu, Oct 15, 2009 at 10:19:01AM +0200, Damien Sandras wrote : That's because the remote server accepts it. If it can't relay RTP, it should reject the INVITE request with unroutable RTP addresses. The RTP is not relayed (and it is not supposed to be as the 2 parties are in the same subnet). The SIP proxy (openser) doesn't care about the SDP. The invite is just forwarded as is to the sip phone. What I don't get is why would ekiga send a packet on an interface with IP that are not on the network of this interface. It really seems like a bug to me. I would really expect that a sipphone communicating on eth1 will use the ip address of eth1 in all its messages. -- Alexandre Belloni ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Sometimes Ekiga is not binding to the correct interface
Le jeudi 15 octobre 2009 à 10:54 +0200, Alexandre Belloni a écrit : On Thu, Oct 15, 2009 at 10:19:01AM +0200, Damien Sandras wrote : That's because the remote server accepts it. If it can't relay RTP, it should reject the INVITE request with unroutable RTP addresses. The RTP is not relayed (and it is not supposed to be as the 2 parties are in the same subnet). The SIP proxy (openser) doesn't care about the SDP. The invite is just forwarded as is to the sip phone. What I don't get is why would ekiga send a packet on an interface with IP that are not on the network of this interface. It really seems like a bug to me. I would really expect that a sipphone communicating on eth1 will use the ip address of eth1 in all its messages. Here is how Ekiga works : - it sends the SIP PDU from each interface with that interface as origin - if one (or several) of the PDU fails to reach their destination, the interface is sort of marked as invalid So it should work, except if your destination endpoint is reachable from several interfaces, but the call is supposed to work only from one of them (which is a configuration problem on your side). -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Sometimes Ekiga is not binding to the correct interface
Hi, My setup is the following : Physically: SIP phone-eth1-PC-eth0-router On the PC (IP 192.168.1.86), I'm running openser in an ubuntu kvm image (IP 192.168.1.80). I'm also running ekiga (3.2.0-0ubuntu2) on this PC. The SIP phone IP address is 192.168.1.1. br0 Link encap:Ethernet HWaddr 00:10:18:35:8f:d0 inet addr:192.168.1.86 Bcast:192.168.1.255 Mask:255.255.255.0 eth0 Link encap:Ethernet HWaddr 00:21:5a:e7:2d:5f inet addr:192.168.18.109 Bcast:192.168.18.255 Mask:255.255.255.0 br0 8000.001018358fd0 no eth1 vnet0 The issue is that ekiga is binding to eth0 when I'm trying to call the sipphone. It should bind to br0. You can find debug traces here: http://piout.net/fr/ekiga.log Regards, -- Alexandre Belloni ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
