Created attachment 56519 [details] telepathy-rakia debug log - TPORT_LOG=1 TPSIP_DEBUG=all TPSIP_PERSIST=1 Hi, With: telepathy-rakia-0.7.3 sofia-sip-1.12.11 Account: sofiasip/sip/_34678_40192_2e168_2e5_2e600 Display Name: 4678@192.168.5.60 Normalized: sip:4678@192.168.5.60 Enabled: enabled Icon: im-sip Connects: only when requested Nickname: 4678@192.168.5.60 Service: sip Presences: Automatic: available (2) "" Current: (0) "" Requested: available (2) "" Changing: yes (uint) keepalive-interval = 3600 (string) proxy-host = 192.168.5.60 (string) auth-user = goliver (bool) ignore-tls-errors = true (string) keepalive-mechanism = register (string) transport = udp (string) account = 4678@192.168.5.60 (string) local-ip-address = 172.17.0.100 and my interfaces/routes: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router 0.0.0.0 UG 0 0 0 p5p1 10.0.0.0 172.17.0.1 255.0.0.0 UG 0 0 0 p5p1.2 172.16.0.0 172.17.0.1 255.240.0.0 UG 0 0 0 p5p1.2 172.17.0.0 * 255.255.255.0 U 0 0 0 p5p1.2 172.17.1.0 * 255.255.255.0 U 0 0 0 p5p1.3 172.17.2.0 * 255.255.255.0 U 0 0 0 p5p1.4 172.17.3.0 * 255.255.255.0 U 0 0 0 p5p1.5 192.168.0.0 172.17.0.1 255.255.0.0 UG 0 0 0 p5p1.2 192.168.100.0 * 255.255.255.0 U 1 0 0 p5p1 192.168.101.0 router 255.255.255.0 UG 0 0 0 p5p1 192.168.102.0 router 255.255.255.0 UG 0 0 0 p5p1 192.168.103.0 router 255.255.255.0 UG 0 0 0 p5p1 192.168.104.0 router 255.255.255.0 UG 0 0 0 p5p1 192.168.105.0 router 255.255.255.0 UG 0 0 0 p5p1 209.33.163.0 172.17.0.1 255.255.255.128 UG 0 0 0 p5p1.2 SIP communication functions properly on the p5p1.2 interface (172.17.0.100) - the issue is that SDP is always setup on a *random* (and changing) IP address of those available. On one call it may set up on 172.17.3.100, and immediately after, it may use 192.168.100.100 . This obviously does not work. The log I attached is a fresh start/registration and a single inbound call. The SDP was bound to the wrong interface (192.168.100.100). Please let me know if there is another setting I am missing or if there is anything I can do. Thanks! -Greg
The o= line in SDP is irrelevant, it's only used for identification. What does not work is 3rd party call control INVITE, which this log appears to show. See bug #32808. Rakia responds successfully with no streams, which does not make sense for the call.
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.