Running Ubuntu 10.04 with ppa:telepathy repository enabled (telepathy-core version 23, telepathy-sofiasip version 0.6.3-1). My system has several network interfaces up. Telepathy picks the right interface to register via SIP (in my case the main ethernet interface). Telepathy also picks the same right interface to send out the INVITE when I dial a call. But the problem is that in the INVITE's SDP, the contact lines (c=IN IP4 1.2.3.4) get filled with the IP address of a completely unrelated network interface (in my case a network interface made up by vmware player). I need to disable all interfaces except the one I want to use (well, I can keep the loopback interface up as well) in order to have the SDP contact lines filled with the right values. Expected behaviour would be either to pick the IP address the INVITE is sent on to fill the c-lines in the SDP or to have a configuration option to select it.
A lame workaround is to use the account parameter local-ip-address. A proper fix will require support from the sofia-sip stack.
(In reply to comment #1) > A lame workaround is to use the account parameter local-ip-address. > A proper fix will require support from the sofia-sip stack. Thanks for the reply. Just tried that, but did not work. If I set the local-ip-address parameter to the IP address of the right interface, then I can enable the account (register via SIP). When I set it to the wrong interface it does not work any more. From that I get that I am doing the right thing to set the parameter. However, even when set to the right IP on the right network interface, when making the call, the SDP gets the wrong IP from the other network interface to fill the "c=" line. As a note, however, the "o=" line of the SDP gets the correct address.
(In reply to comment #2) > However, even when set to the right IP on the right network interface, when > making the call, the SDP gets the wrong IP from the other network interface to > fill the "c=" line. > > As a note, however, the "o=" line of the SDP gets the correct address. This is odd; there is code to make the value in 'local-ip-address' a preferred choice among RTP transport candidates. Can you post verbose sofiasip logs? You can enable them by setting TPSIP_DEBUG=all in the environment of telepathy-sofiasip. You can do it in a shell belonging to the user session with TPSIP_PERSIST=1 also exported to prevent telepathy-sofiasip from exiting. The "sofiasip" log view in Empathy will have the logs.
Created attachment 39844 [details] sofiasip debug output As requested in comment #3
(In reply to comment #4) > Created an attachment (id=39844) [details] > sofiasip debug output Hmm, there is not enough information to see what went wrong. I should add a few more debug statements.
I can reproduce it locally, will investigate.
(In reply to comment #3) > > However, even when set to the right IP on the right network interface, when > > making the call, the SDP gets the wrong IP from the other network interface to > > fill the "c=" line. > > This is odd; there is code to make the value in 'local-ip-address' a preferred > choice among RTP transport candidates. This code would have a chance if Farsight collected the second address, but it doesn't any longer for some reason: Nov 5 17:14:24 Rxxxx telepathy-stream-engine[2373]: GLIB DEBUG tp-fs - stream 0 0xd26c0 (audio) cb_fs_new_local_candidate: called Nov 5 17:14:24 Rxxxx telepathy-stream-engine[2373]: GLIB DEBUG tp-fs - stream 0 0xd26c0 (audio) cb_fs_local_candidates_prepared: called Nov 5 17:14:24 Rxxxx telepathy-stream-engine[2373]: GLIB DEBUG tp-fs - stream 0 0xd26c0 (audio) cb_fs_local_candidates_prepared: ip = '192.168.2.15 port = 7078 component = 1' Nov 5 17:14:24 Rxxxx telepathy-stream-engine[2373]: GLIB DEBUG tp-fs - stream 0 0xd26c0 (audio) cb_fs_local_candidates_prepared: ip = '192.168.2.15 port = 7079 component = 2' Nov 5 17:14:24 Rxxxx telepathy-sofiasip[2237]: GLIB DEBUG tpsip - tpsip_media_session_debug: SIP media session [created ]: put native candidate 'L1' from stream-engine into cache Nov 5 17:14:24 Rxxxx telepathy-sofiasip[2237]: GLIB DEBUG tpsip - tpsip_media_stream_native_candidates_prepared: enter My interfaces are configured as follows: usb0 Link encap:Ethernet HWaddr 2A:40:C2:D2:C7:D0 inet addr:192.168.2.15 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5377 errors:0 dropped:0 overruns:0 frame:0 TX packets:5651 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:577105 (563.5 KiB) TX bytes:4710240 (4.4 MiB) wlan0 Link encap:Ethernet HWaddr <<stripped>> inet addr:213.28.38.84 Bcast:213.28.38.127 Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:447 errors:0 dropped:0 overruns:0 frame:0 TX packets:3641 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:124321 (121.4 KiB) TX bytes:1428785 (1.3 MiB)
strange, farsight2 should prioritize the non-local address. I can give you more than one candidate for rawudp, but I can't really give you the right answer in NewActiveCandidatePair().. One easy thing you can do is just ignore whatever farsight tells you and use the one that has been configured.
(In reply to comment #8) > strange, farsight2 should prioritize the non-local address. > > I can give you more than one candidate for rawudp, but I can't really give you > the right answer in NewActiveCandidatePair().. Yeah, but it used to work with multiple candidates, when we got them from Farsight. > One easy thing you can do is just ignore whatever farsight tells you and use > the one that has been configured. Except when Farsight succeeds in NAT traversal (e.g. using the UPnP IGD service that telepathy-sofiasip knows nothing about) and gives us a really workable candidate?
I can give you all the candidates if you want.
How reproduceably are you getting the "wrong" candidate ?
(In reply to comment #11) > How reproduceably are you getting the "wrong" candidate ? Every time when I have its interface configured ahead of the right interface. I think it depends on the order in the interface table.
Arg, I can reproduce this bug. I'll do two things: 1. I'll generate the right default candidate (it will try a non 192.168.x.x address if there is one). 2. I guess I should give all the candidates to tp-ssip, then it can select the one with the LOWEST priority (which will be stun if there is one). For backwards compat, it seems that I need to give them in reverse priority order (first host, then UPnP, then STUN).
(In reply to comment #13) > 1. I'll generate the right default candidate (it will try a non 192.168.x.x > address if there is one). Good. Don't forget also the other private IP prefixes: 10.x.x.x and what was the third one... > 2. I guess I should give all the candidates to tp-ssip, then it can select the > one with the LOWEST priority (which will be stun if there is one). For > backwards compat, it seems that I need to give them in reverse priority order > (first host, then UPnP, then STUN). Yes; this seems to be in accordance with RFC 5245 section 4.1.4.
Yea, it does all the prefixes.
Hello, I suffer from the same misbehavior. I'm using telepathy-kde (0.5.2) with farstream 0.1.2-r1 on a Gentoo Linux system. If I make a call, the local IP address within the SDP-part of the SIP-INVIVE message contains an IP-Address of one of my tun-devices (10.x.y.z). Thus, I receive no media data. Regards, Florian
The best way to make sure it always works is to set a STUN server. Right now farstream still emits only the first IPv4 candidate... Where first is.. the first one returned in the list produced by libnice. So it's entirely random. The solution to this is to implement ICE in tp-rakia.
(In reply to comment #17) > Right now farstream still emits only the first IPv4 candidate... Where first > is.. the first one returned in the list produced by libnice. On Linux, it could use the heuristic of looking into rtnetlink and choosing the interface used by the default route. I agree that ICE is the ultimately right solution, provided that the other endpoint supports it.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/farstream/farstream/issues/2.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.