After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 587504 - Having more than one network interface up STILL screws up Ekiga's functionality!
Having more than one network interface up STILL screws up Ekiga's functionality!
Status: RESOLVED INCOMPLETE
Product: ekiga
Classification: Applications
Component: Account stack
3.2.x
Other All
: Normal major
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
: 563670 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-07-01 10:12 UTC by Daniel Gimpelevich
Modified: 2012-01-10 23:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
debug outputs under four conditions (28.99 KB, application/x-bzip)
2009-07-01 10:13 UTC, Daniel Gimpelevich
Details
ekiga-stderr.txt : output of ekiga -d 4 (116.50 KB, text/plain)
2011-04-02 02:03 UTC, G K
Details

Description Daniel Gimpelevich 2009-07-01 10:12:13 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:
Comment 1 Daniel Gimpelevich 2009-07-01 10:13:26 UTC
Created attachment 137679 [details]
debug outputs under four conditions
Comment 2 Eugen Dedu 2009-07-01 10:14:27 UTC
Does the interface provided by avahi pose problems too?
Comment 3 Daniel Gimpelevich 2009-07-01 15:09:34 UTC
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)
Comment 4 Eugen Dedu 2009-07-11 09:19:29 UTC
*** Bug 563670 has been marked as a duplicate of this bug. ***
Comment 5 Yannick 2009-09-06 06:19:00 UTC
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
Comment 6 Yannick 2009-09-06 16:00:27 UTC
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
Comment 7 Damien Sandras 2009-09-13 16:28:23 UTC
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.
Comment 8 Damien Sandras 2009-09-20 16:14:48 UTC
This is fixed (the 2 INVITE problem).
Comment 9 Eugen Dedu 2009-09-20 17:52:48 UTC
Closing it then (http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23493).
Comment 10 André Kjellstrup 2011-02-16 11:45:13 UTC
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
Comment 11 G K 2011-04-02 02:03:38 UTC
Created attachment 184924 [details]
ekiga-stderr.txt : output of ekiga -d 4
Comment 12 G K 2011-04-02 02:19:42 UTC
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 . . . . . . . . . :
Comment 13 G K 2011-04-02 02:20:18 UTC
ekiga-stderr.txt : output of ekiga -d 4
Comment 14 G K 2011-04-02 02:22:37 UTC
It can be a very common scenario now

1) concurrent ethernet and wlan collections
2) virtual machines
3) vpn connections
Comment 15 Eugen Dedu 2011-04-05 15:07:35 UTC
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?
Comment 16 Peter Robinson 2011-04-05 15:10:55 UTC
> 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).
Comment 17 Eugen Dedu 2011-04-06 14:00:53 UTC
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.
Comment 18 pawel 2011-04-17 17:40:11 UTC
> 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
Comment 19 Eugen Dedu 2011-09-16 09:03:39 UTC
(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.)
Comment 20 Tobias Mueller 2012-01-10 23:28:43 UTC
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!