GNOME Bugzilla – Bug 587504
Having more than one network interface up STILL screws up Ekiga's functionality!
Last modified: 2012-01-10 23:28:43 UTC
Please describe the problem: When Ekiga is started with more than one network interface up with a valid IPv4 address, for example if there is a bridge for a virtualizer, account registration for some SIP providers may randomly fail. This is further complicated by the fact that some providers (e.g. Ekiga.net) require NAT to be traversed with STUN, while others (e.g. Callcentric) require NAT to be traversed without STUN. Bugs 563670, 570511, 582713, and 587442 all relate to this problem, and are all still issues. Steps to reproduce: 1. sudo apt-get install libvirt-bin 2. Set up Ekiga for Localphone.com 3. Try to register with the SIP proxy Actual results: Registration fails until Ekiga is started with the bridge interface down. Expected results: Registration should work the same regardless of other network interfaces. Does this happen every time? No. Other information:
Created attachment 137679 [details] debug outputs under four conditions
Does the interface provided by avahi pose problems too?
I had not made a definite determination before I turned avahi off, but it seems to me that the first time it ever successfully registered with Localphone.com was well after I did so. BTW, here is my current ifconfig -a: eth0 Link encap:Ethernet HWaddr 00:1b:38:2b:b0:65 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:17460 errors:0 dropped:0 overruns:0 frame:0 TX packets:17460 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1060228 (1.0 MB) TX bytes:1060228 (1.0 MB) pan0 Link encap:Ethernet HWaddr ca:aa:64:dc:24:f1 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) virbr0 Link encap:Ethernet HWaddr 52:db:c2:2a:99:f8 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:110 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:22813 (22.8 KB) wlan0 Link encap:Ethernet HWaddr 00:16:eb:05:97:b6 inet addr:192.168.84.100 Bcast:192.168.84.255 Mask:255.255.255.0 inet6 addr: fe80::216:ebff:fe05:97b6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:831946 errors:0 dropped:0 overruns:0 frame:0 TX packets:571282 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1122373191 (1.1 GB) TX bytes:60365554 (60.3 MB) wmaster0 Link encap:UNSPEC HWaddr 00-16-EB-05-97-B6-00-00-00-00-00-00-00-00-00-00 UP RUNNING MTU:0 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
*** Bug 563670 has been marked as a duplicate of this bug. ***
Hi, Here is another example of Ekiga misbahaviour with several network interfaces. There is 2 interfaces in this setup: wlan0 and br0. Both works for REGISTER or INVITE, i.e. Ekiga is over using the network as even if 1 interface succeed, it keeps using both interfaces. Ekiga can register but fails on INVITE with wrong reason: it gets all relevant informations from the server but as it deals with several attempt at the same time (i.e. trying to REGISTER and INVITE using both interfaces at the same time) it destroys the INVITE itself (Call end reason for Call[xxxx] set to EndedByQ931Cause) It is quit tricky for me to exactly understand why as it is related to the algorithm in ekiga which I do not know. Still I tried to extract related informations from the -d 4. I recommand to carefully examin the original debug output... Downstream bug: https://bugs.launchpad.net/ekiga/+bug/423461 Original debug output: http://launchpadlibrarian.net/31377732/ekiga-out.log My own selection: 2009/09/05 17:33:23.185 0:02.182 subscriber:0xcaa78950 SIP Sending PDU (640 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 REGISTER sip:sip.freeconet.pl SIP/2.0 Route: <sip:sip.freeconet.pl:5060;lr> CSeq: 1 REGISTER Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKbce6627f-a798-de11-851d-001f3ca54bf1;rport 2009/09/05 17:33:23.193 0:02.190 subscriber:0xcaa78950 SIP Sending PDU (640 bytes) to: rem=udp$213.218.116.65:5060,local=udp$10.0.100.1:5060,if=10.0.100.1%br0 REGISTER sip:sip.freeconet.pl SIP/2.0 Route: <sip:sip.freeconet.pl:5060;lr> CSeq: 1 REGISTER Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK7e41647f-a798-de11-851d-001f3ca54bf1;rport User-Agent: Ekiga/3.2.0 2009/09/05 17:33:23.241 0:02.238 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 401 Unauthorized CSeq: 1 REGISTER Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKbce6627f-a798-de11-851d-001f3ca54bf1;rport=5060;received=82.5.245.24 2009/09/05 17:33:23.249 0:02.247 Opal Liste...0xd07dd950 SIP Sending PDU (848 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 REGISTER sip:sip.freeconet.pl SIP/2.0 Route: <sip:sip.freeconet.pl:5060;lr> CSeq: 2 REGISTER Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKd8c56c7f-a798-de11-851d-001f3ca54bf1;rport 2009/09/05 17:33:23.269 0:02.266 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$10.0.100.1:5060,if=10.0.100.1%br0 SIP/2.0 401 Unauthorized CSeq: 1 REGISTER Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK7e41647f-a798-de11-851d-001f3ca54bf1;rport=1024;received=82.5.245.24 2009/09/05 17:33:23.316 0:02.313 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 200 OK CSeq: 2 REGISTER Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKd8c56c7f-a798-de11-851d-001f3ca54bf1;rport=5060;received=82.5.245.24 2009/09/05 17:33:33.834 0:12.831 CallSetup:0xcaa37950 SIP Sending PDU (1270 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 INVITE sip:447882738764@sip.freeconet.pl SIP/2.0 Date: Sat, 05 Sep 2009 16:33:32 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKc827ed84-a798-de11-851d-001f3ca54bf1;rport User-Agent: Ekiga/3.2.0 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Contact: <sip:jgrzebyta@82.5.245.24> 2009/09/05 17:33:33.886 0:12.883 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 407 Proxy Authentication Required CSeq: 1 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKc827ed84-a798-de11-851d-001f3ca54bf1;rport=5060 Server: Carrier-eX v.0.9 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=3338e2c0cc67623653a01791ec0a4d72.5f0c Proxy-Authenticate: Digest realm="sip.freeconet.pl", nonce="4aa292fc2f6958630a930a8f9a6296a618cf7d58" Content-Length: 0 2009/09/05 17:33:34.018 0:13.015 CallSetup:0xcaa37950 SIP Sending PDU (1270 bytes) to: rem=udp$213.218.116.66:5060,local=udp$10.0.100.1:5060,if=10.0.100.1%br0 INVITE sip:447882738764@sip.freeconet.pl SIP/2.0 Date: Sat, 05 Sep 2009 16:33:33 GMT CSeq: 2 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKb62bd285-a798-de11-851d-001f3ca54bf1;rport User-Agent: Ekiga/3.2.0 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Contact: <sip:jgrzebyta@82.5.245.24> 2009/09/05 17:33:34.022 0:13.019 Aggregator:0xc9f6c950 SIP Sending PDU (431 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 ACK sip:447882738764@sip.freeconet.pl SIP/2.0 CSeq: 1 ACK Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKc827ed84-a798-de11-851d-001f3ca54bf1;rport From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=3338e2c0cc67623653a01791ec0a4d72.5f0c Content-Length: 0 Max-Forwards: 70 2009/09/05 17:33:34.024 0:13.021 Aggregator:0xc9f6c950 OpalUDP Setting interface to 10.0.100.1%br0 2009/09/05 17:33:34.024 0:13.021 Aggregator:0xc9f6c950 SIP Transaction 1 INVITE completed. 2009/09/05 17:33:34.024 0:13.021 CallSetup:0xcaa37950 OpalCon OnSetUpConnectionCall[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.024 0:13.021 CallSetup:0xcaa37950 OpalEP OnSetUpConnection Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.024 0:13.021 Aggregator:0xc9f6c950 SIP Received Proxy Authentication Required response 2009/09/05 17:33:34.024 0:13.022 Aggregator:0xc9f6c950 SIP Found auth info for realm sip.freeconet.pl 2009/09/05 17:33:34.025 0:13.022 Aggregator:0xc9f6c950 OpalUDP Setting interface to 192.168.1.10%wlan0 2009/09/05 17:33:34.030 0:13.027 Aggregator:0xc9f6c950 SIP Transaction 3 INVITE created. 2009/09/05 17:33:34.067 0:13.064 Aggregator:0xc9f6c950 SIP Sending PDU (1455 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 INVITE sip:447882738764@sip.freeconet.pl SIP/2.0 Date: Sat, 05 Sep 2009 16:33:34 GMT CSeq: 3 INVITE v: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport User-Agent: Ekiga/3.2.0 f: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 i: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop t: <sip:447882738764@sip.freeconet.pl> m: <sip:jgrzebyta@82.5.245.24> Proxy-Authorization: Digest username="jgrzebyta", realm="sip.freeconet.pl", nonce="4aa292fc2f6958630a930a8f9a6296a618cf7d58", uri="sip:447882738764@sip.freeconet.pl", algorithm=MD5, response="541d4db2213f4dc9a98efaab6d713e08" 2009/09/05 17:33:34.076 0:13.073 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.66:5060,local=udp$10.0.100.1:5060,if=10.0.100.1%br0 SIP/2.0 407 Proxy Authentication Required CSeq: 2 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKb62bd285-a798-de11-851d-001f3ca54bf1;rport=1024;received=82.5.245.24 Server: Carrier-eX v.0.9 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=14c725db25104a142fdd6de44be8de0b.bc02 Proxy-Authenticate: Digest realm="sip.freeconet.pl", nonce="4aa292fca524355dc10ad88567a1934ed424d39a" Content-Length: 0 2009/09/05 17:33:34.078 0:13.075 Aggregator:0xc9f6c950 SIP Sending PDU (431 bytes) to: rem=udp$213.218.116.66:5060,local=udp$10.0.100.1:5060,if=10.0.100.1%br0 ACK sip:447882738764@sip.freeconet.pl SIP/2.0 CSeq: 2 ACK Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKb62bd285-a798-de11-851d-001f3ca54bf1;rport From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=14c725db25104a142fdd6de44be8de0b.bc02 Content-Length: 0 Max-Forwards: 70 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 OpalUDP Setting interface to 192.168.1.10%wlan0 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 SIP Transaction 2 INVITE completed. 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 SIP Received Proxy Authentication Required response 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 SIP Found auth info for realm sip.freeconet.pl 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 SIP Authentication already performed using current credentials, not trying again. 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 SIP Transaction 3 INVITE cancelled. 2009/09/05 17:33:34.079 0:13.076 Aggregator:0xc9f6c950 SIP Sending PDU (395 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 CANCEL sip:447882738764@sip.freeconet.pl SIP/2.0 CSeq: 3 CANCEL Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Content-Length: 0 Max-Forwards: 70 2009/09/05 17:33:34.080 0:13.077 Aggregator:0xc9f6c950 OpalUDP Setting interface to 192.168.1.10%wlan0 2009/09/05 17:33:34.080 0:13.077 Aggregator:0xc9f6c950 OpalCon SetPhase from SetUpPhase to ReleasingPhase for Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.080 0:13.077 Aggregator:0xc9f6c950 OpalCon Releasing Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.080 0:13.077 Aggregator:0xc9f6c950 OpalCon Call end reason for Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] set to EndedByQ931Cause 2009/09/05 17:33:34.135 0:13.132 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 100 Giving a try CSeq: 3 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport=5060 Server: Carrier-eX v.0.9 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Content-Length: 0 2009/09/05 17:33:34.144 0:13.141 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 180 Ringing Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Route: <sip:213.218.116.65;lr> CSeq: 3 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;received=82.5.245.24;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport=5060 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=22026502_b3474fa3_1252168414321327000 Content-Length: 0 Record-Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Record-Route: <sip:213.218.116.65;lr> 2009/09/05 17:33:34.153 0:13.150 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 200 OK Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Route: <sip:213.218.116.65;lr> CSeq: 3 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;received=82.5.245.24;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport=5060 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=22026502_b3474fa3_1252168414321327000 Contact: <sip:213.218.116.68:5080;transport=udp> Content-Type: application/sdp Content-Length: 295 Record-Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Record-Route: <sip:213.218.116.65;lr> v=0 o=MediaServer 898166 898166 IN IP4 213.218.116.68 s=session c=IN IP4 213.218.116.73 t=0 0 m=audio 11440 RTP/AVP 0 3 8 101 116 a=rtpmap:0 pcmu/8000 a=rtpmap:3 gsm/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:116 speex/8000 a=fmtp:101 0-15 2009/09/05 17:33:34.156 0:13.153 Aggregator:0xc9f6c950 SIP Sending PDU (654 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 ACK sip:447882738764@sip.freeconet.pl SIP/2.0 CSeq: 3 ACK Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK581eed85-a798-de11-851d-001f3ca54bf1;rport From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Contact: <sip:jgrzebyta@82.5.245.24> Proxy-Authorization: Digest username="jgrzebyta", realm="sip.freeconet.pl", nonce="4aa292fc2f6958630a930a8f9a6296a618cf7d58", uri="sip:447882738764@sip.freeconet.pl", algorithm=MD5, response="5daf90746bc6ff20df91362549352d82" Content-Length: 0 Max-Forwards: 70 2009/09/05 17:33:34.156 0:13.153 Aggregator:0xc9f6c950 OpalUDP Setting interface to 192.168.1.10%wlan0 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalCon SetPhase from ReleasingPhase to ReleasedPhase for Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalCon OnReleased Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalEP OnReleased Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalMan OnReleased Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 Call OnReleased Call[wd4e112601]-EP<sip>[64f9e884-a798-de11-851d-001f3ca54bf1] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalCon SetPhase from SetUpPhase to ReleasingPhase for Call[wd4e112601]-EP<pc>[h3138ed222] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalCon Releasing Call[wd4e112601]-EP<pc>[h3138ed222] 2009/09/05 17:33:34.157 0:13.154 OnRelease:0xc9f2b950 OpalCon Call end reason for Call[wd4e112601]-EP<pc>[h3138ed222] set to EndedByQ931Cause 2009/09/05 17:33:34.657 0:13.654 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 200 OK Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Route: <sip:213.218.116.65;lr> CSeq: 3 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;received=82.5.245.24;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport=5060 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=22026502_b3474fa3_1252168414321327000 Contact: <sip:213.218.116.68:5080;transport=udp> Content-Type: application/sdp Content-Length: 295 Record-Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Record-Route: <sip:213.218.116.65;lr> v=0 o=MediaServer 898166 898166 IN IP4 213.218.116.68 s=session c=IN IP4 213.218.116.73 t=0 0 m=audio 11440 RTP/AVP 0 3 8 101 116 a=rtpmap:0 pcmu/8000 a=rtpmap:3 gsm/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:116 speex/8000 a=fmtp:101 0-15 2009/09/05 17:33:34.659 0:13.656 Opal Liste...0xd07dd950 SIP Sending PDU (654 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 ACK sip:447882738764@sip.freeconet.pl SIP/2.0 CSeq: 3 ACK Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bKece23986-a798-de11-851d-001f3ca54bf1;rport From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Contact: <sip:jgrzebyta@82.5.245.24> Proxy-Authorization: Digest username="jgrzebyta", realm="sip.freeconet.pl", nonce="4aa292fc2f6958630a930a8f9a6296a618cf7d58", uri="sip:447882738764@sip.freeconet.pl", algorithm=MD5, response="5daf90746bc6ff20df91362549352d82" Content-Length: 0 Max-Forwards: 70 2009/09/05 17:33:34.659 0:13.656 Opal Liste...0xd07dd950 OpalUDP Setting interface to 192.168.1.10%wlan0 2009/09/05 17:33:34.660 0:13.657 Opal Liste...0xd07dd950 Opal Transport clean up on termination 2009/09/05 17:33:34.660 0:13.657 Opal Liste...0xd07dd950 Opal Transport Close 2009/09/05 17:33:34.660 0:13.657 Opal Liste...0xd07dd950 Opal Deleted transport udp$213.218.116.65:5060<if=udp$82.5.245.24:5060> 2009/09/05 17:33:35.069 0:14.066 Housekeeper:0xd081e950 SIP Set state Terminated_Success for transaction 1 INVITE 2009/09/05 17:33:35.086 0:14.083 Housekeeper:0xd081e950 SIP Set state Terminated_Success for transaction 2 INVITE 2009/09/05 17:33:35.654 0:14.651 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 200 OK Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Route: <sip:213.218.116.65;lr> CSeq: 3 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;received=82.5.245.24;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport=5060 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=22026502_b3474fa3_1252168414321327000 Contact: <sip:213.218.116.68:5080;transport=udp> Content-Type: application/sdp Content-Length: 295 Record-Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Record-Route: <sip:213.218.116.65;lr> v=0 o=MediaServer 898166 898166 IN IP4 213.218.116.68 s=session c=IN IP4 213.218.116.73 t=0 0 m=audio 11440 RTP/AVP 0 3 8 101 116 a=rtpmap:0 pcmu/8000 a=rtpmap:3 gsm/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:116 speex/8000 a=fmtp:101 0-15 2009/09/05 17:33:35.660 0:14.657 Opal Liste...0xd07dd950 SIP Adding authentication information 2009/09/05 17:33:35.660 0:14.657 Opal Liste...0xd07dd950 SIP Sending PDU (654 bytes) to: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 ACK sip:447882738764@sip.freeconet.pl SIP/2.0 CSeq: 3 ACK Via: SIP/2.0/UDP 82.5.245.24:5060;branch=z9hG4bK9492d286-a798-de11-851d-001f3ca54bf1;rport From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl> Contact: <sip:jgrzebyta@82.5.245.24> Proxy-Authorization: Digest username="jgrzebyta", realm="sip.freeconet.pl", nonce="4aa292fc2f6958630a930a8f9a6296a618cf7d58", uri="sip:447882738764@sip.freeconet.pl", algorithm=MD5, response="5daf90746bc6ff20df91362549352d82" Content-Length: 0 Max-Forwards: 70 2009/09/05 17:33:35.661 0:14.658 Opal Liste...0xd07dd950 OpalUDP Setting interface to 192.168.1.10%wlan0 2009/09/05 17:33:35.661 0:14.658 Opal Liste...0xd07dd950 Opal Transport clean up on termination 2009/09/05 17:33:35.661 0:14.658 Opal Liste...0xd07dd950 Opal Transport Close 2009/09/05 17:33:35.661 0:14.658 Opal Liste...0xd07dd950 Opal Deleted transport udp$213.218.116.65:5060<if=udp$82.5.245.24:5060> 2009/09/05 17:33:36.662 0:15.660 Housekeeper:0xd081e950 SIP Set state Terminated_Cancelled for transaction 3 INVITE 2009/09/05 17:33:37.655 0:16.652 Opal Liste...0xd07dd950 SIP PDU received: rem=udp$213.218.116.65:5060,local=udp$82.5.245.24:5060,if=192.168.1.10%wlan0 SIP/2.0 200 OK Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Route: <sip:213.218.116.65;lr> CSeq: 3 INVITE Via: SIP/2.0/UDP 82.5.245.24:5060;received=82.5.245.24;branch=z9hG4bK06d9d985-a798-de11-851d-001f3ca54bf1;rport=5060 From: "Jacek Grzebyta" <sip:jgrzebyta@sip.freeconet.pl>;tag=64f9e884-a798-de11-851d-001f3ca54bf1 Call-ID: da0ae984-a798-de11-851d-001f3ca54bf1@main-laptop To: <sip:447882738764@sip.freeconet.pl>;tag=22026502_b3474fa3_1252168414321327000 Contact: <sip:213.218.116.68:5080;transport=udp> Content-Type: application/sdp Content-Length: 295 Record-Route: <sip:213.218.116.68;lr=on;ftag=64f9e884-a798-de11-851d-001f3ca54bf1> Record-Route: <sip:213.218.116.65;lr> v=0 o=MediaServer 898166 898166 IN IP4 213.218.116.68 s=session c=IN IP4 213.218.116.73 t=0 0 m=audio 11440 RTP/AVP 0 3 8 101 116 a=rtpmap:0 pcmu/8000 a=rtpmap:3 gsm/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:116 speex/8000 a=fmtp:101 0-15 2009/09/05 17:33:37.655 0:16.652 Opal Liste...0xd07dd950 Opal Transport clean up on termination 2009/09/05 17:33:37.655 0:16.652 Opal Liste...0xd07dd950 Opal Transport Close 2009/09/05 17:33:37.655 0:16.652 Opal Liste...0xd07dd950 Opal Deleted transport udp$213.218.116.65:5060<if=udp$82.5.245.24:5060> 2009/09/05 17:33:38.281 0:17.278 Call Call[wd4e112601] destroyed. Best regards, Yannick
Additional informations for the above setup: The br0 is the bridge used in the virtualization. I use kvim for that. I setup this interface in /etc/netork/interfaces: auto br0 iface br0 inet static address 10.0.100.1 netmask 255.255.255.0 getway 192.168.1.1 bridge_ports tap0 tap1 and route -v gives: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.100.0 * 255.255.255.0 U 0 0 0 br0 192.168.1.0 * 255.255.255.0 U 2 0 0 wlan0 link-local * 255.255.0.0 U 1000 0 0 br0 default 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
I reported the problem to Robert. I think the problem is due to the fact that the first INVITE works, the second too, and we authenticate the second. OPAL clears the call becuase it thinks we already authenticated.
This is fixed (the 2 INVITE problem).
Closing it then (http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23493).
Not fixed. My Ekiga 3.2.7 attempts to register om Cisco Call Manager (SIP) with vmnet1 interface's IP , instead of eth1 - so it fails, and is unusable. eth0 Link encap:Ethernet HWaddr 00:1a:a0:03:8c:a0 UP BROADCAST MULTICAST MTU:1500 Metric:1 eth1 Link encap:Ethernet HWaddr 00:10:18:0f:4a:46 inet addr:10.11.12.13 Bcast:10.11.12.255 Mask:255.255.255.0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 vmnet1 Link encap:Ethernet HWaddr 00:50:56:c0:00:01 inet addr:192.168.104.1 Bcast:192.168.104.255 Mask:255.255.255.0 vmnet8 Link encap:Ethernet HWaddr 00:50:56:c0:00:08 inet addr:192.168.44.1 Bcast:192.168.44.255 Mask:255.255.255.0 Destination Gateway Genmask Flags Metric Ref Use Iface 10.11.12.0 * 255.255.255.0 U 1 0 0 eth1 192.168.44.0 * 255.255.255.0 U 0 0 0 vmnet8 192.168.104.0 * 255.255.255.0 U 0 0 0 vmnet1 link-local * 255.255.0.0 U 1000 0 0 eth1 default 10.11.12.1 0.0.0.0 UG 0 0 0 eth1
Created attachment 184924 [details] ekiga-stderr.txt : output of ekiga -d 4
First had ekiga 3.2.7, Did not work there Tried ekiga 3.3.0, Did not work there either windows XP pro SP3, 32-bit It seems like the interfaces are the reason. Windows IP Configuration ipconfig all contains (lines deleted) Host Name . . . . . . . . . . . . : *** Primary Dns Suffix . . . . . . . : *** Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : **1 **2 **3 **4 Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : *** Description . . . . . . . . . . . : Intel(R) 82567LM-3 Gigabit Network C onnection Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.10.105 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.10.1 DHCP Server . . . . . . . . . . . : 192.168.10.1 DNS Servers . . . . . . . . . . . : **1 **2 Lease Obtained. . . . . . . . . . : Friday, April 01, 2011 12:48:50 PM Lease Expires . . . . . . . . . . : Saturday, April 02, 2011 12:48:50 PM Ethernet adapter Local Area Connection 5: Connection-specific DNS Suffix . : vpn.com Description . . . . . . . . . . . : TAP-Win32 Adapter V9 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.19.22 Subnet Mask . . . . . . . . . . . : 255.255.255.252 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.19.21 DNS Servers . . . . . . . . . . . : 192.168.19.1 Primary WINS Server . . . . . . . : 192.168.19.1 Lease Obtained. . . . . . . . . . : Monday, March 28, 2011 12:49:31 AM Lease Expires . . . . . . . . . . : Tuesday, March 27, 2012 12:49:31 AM Ethernet adapter VirtualBox Host-Only Network: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapte r Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.56.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
ekiga-stderr.txt : output of ekiga -d 4
It can be a very common scenario now 1) concurrent ethernet and wlan collections 2) virtual machines 3) vpn connections
Reopen for further investigation, as per previous comments. I have just tested this bug. I have two interfaces (wired and wireless): snoopy:~/doc/article.zigzag$ ifconfig eth0 Link encap:Ethernet HWaddr ... inet addr:172.20.105.75 Bcast:172.20.105.255 Mask:255.255.255.0 [...] wlan0 Link encap:Ethernet HWaddr ... inet addr:172.21.80.253 Bcast:172.21.81.255 Mask:255.255.254.0 [...] snoopy:~/doc/article.zigzag$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.20.105.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 172.21.80.0 0.0.0.0 255.255.254.0 U 2 0 0 wlan0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 172.20.105.254 0.0.0.0 UG 0 0 0 eth0 still ekiga register to my ekiga.net account. I am a bit lost in this bug. Where is the problem?
> still ekiga register to my ekiga.net account. I am a bit lost in this bug. > Where is the problem? Do the two interfaces in the above ultimately connect to the same physical net connection or gateway? I think most of the issues with this come where the multiple interfaces are completely different networks (say a non routed internal network).
Both interfaces are connected to Internet, probably the 1st or 2nd hop is common to both. I will try with a cable connected to nothing and wi-fi to Internet.
> Do the two interfaces in the above ultimately connect to the same physical net > connection or gateway? I think most of the issues with this come where the > multiple interfaces are completely different networks (say a non routed > internal network). I experience the same problem with my ekiga 3.2.7/ubuntu 10.04 (repo: ppa:nilarimogard/webupd8) My linux box plays role of NAT. one interface is default route for private ip addresses network, while another is public one connected to provider. Ekiga doubles all invite requests to both interfaces. best regards, Paul
(In reply to comment #1) > Created an attachment (id=137679) [details] > debug outputs under four conditions Looking at registration issues in the outputs provided: - nostun-output-one-intf: localphone ok, ekiga.net not ok (this is expected, since it works only with STUN), callcentric ok too (here there is only one Contact, a private one) - stun-output-one-intf: localphone ok, ekiga.net ok, callcentric gives an error: it says Unauthorized, and afterwards Proxy Authentication Required. ekiga/opal stops then: 2009/06/30 05:50:37.374 0:07.492 Pool:0xf39f0950 SIP Authentication already performed using current credentials, not trying again. 2009/06/30 05:50:37.373 0:07.491 Opal Liste...0xf3a72950 Opal Deleted transport udp$204.11.192.22:5080<if=udp$66.218.54.163:5060> This could be a callcentric-specific issue, I suppose this is because of two Contacts - nostun-output-two-intf: ekiga.net not ok (as expected), callcentric not ok (the same error as in stun-output-one-intf, surely because of two Contacts), localphone not ok: each time several Contacts are used, no answer arrives, and finally when Contact is just '*', an error answer arrives, so I infer a problem with Contact again (for reference: showing CSeq lines I see some holes, could that be a problem?) - stun-output-two-intfs: ekiga.net ok, localphone not ok, since there are too many contacts ("P-Registrar-Error: Too many registered contacts" ); this is fixed by ekiga >= 3.3.2 OR by putting %limit inside the account name of localphone. Callcentric is more or less similar to localphone in nostun-output-two-intf. You used ekiga 3.2.4, which always tries with all the contacts. Using only one contact (which fixes hopefully ALL your issues) is a functionality which got committed a bit later, with ekiga 3.2.6, however there is something strange with it in 3.2.x series (but I am not sure). Also, note that with ekiga > 3.3.2 (commit http://git.gnome.org/browse/ekiga/commit/?id=11209441a0), a registration with ONLY one local interface in Contact field (yet a third compatibility mode) will be tried too. To resume, please try with 3.3.2, which fixes several contacts issues, and better with ekiga unstable >= commit 11209441a0 above, which adds yet another compatibility mode. Putting bug in NEEDINFO state, after this analysis, since I am pretty sure it is fixed now. (Note that STUN (de)activation per account is bug 570511.)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!