From mtbc at ixod.org Sun Sep 1 17:05:53 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sun, 01 Sep 2013 18:05:53 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 Message-ID: <87d2oslbf2.fsf@ixod.org> I am having trouble with ekiga not registering when behind a BT Home Hub running software version 8.1.H.U (Type A), whether or not I enable network detection in the preferences. The -d 4 log is pasted at http://pastebin.com/bd6kAWgp In probing the port forwarding I set up, I discover that it is doing all the forwarding correctly except for UDP port 5060. 5059 and 5061 are forwarding just fine, as are UDP 3478,9 and TCP 1720. I am thus guessing it has some built-in grabbing of 5060 for its own purposes. Would this forwarding issue explain the failure to register with ekiga.net? Is it possible to use Ekiga, at least to initiate SIP calls, if it is behind NAT that won't forward 5060? Is there some trick to getting this device to actually forward 5060? -- Mark From friedrich_o at web.de Sun Sep 1 23:38:57 2013 From: friedrich_o at web.de (friedrich_o at web.de) Date: Mon, 02 Sep 2013 01:38:57 +0200 Subject: [Ekiga-list] registrar over dnydns? Message-ID: <5223D011.6030907@web.de> Hello when I enter the local domain name of the registrar (in my case "fritz.box") there is no problem. But this only works in LAN. Over the internet I could use the ip I got from my isp - but this is unconvenient, although it works. So I thought I could just enter a dyndns uri - but then ekiga doesn't connect to my router. Is there no support for such connections or am I doing something wrong? The debug messages don't show the resolved ip either but the uri (like sip:123 at mydyndnsserver.com) Regards, Oliver From junk_no_spam at verizon.net Mon Sep 2 00:45:43 2013 From: junk_no_spam at verizon.net (junk_no_spam) Date: Sun, 01 Sep 2013 19:45:43 -0500 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <5223D011.6030907@web.de> References: <5223D011.6030907@web.de> Message-ID: <5223DFB7.7080004@verizon.net> On 09/01/2013 06:38 PM, friedrich_o at web.de wrote: > The debug messages don't show the resolved ip either but the uri (like > sip:123 at mydyndnsserver.com) The registar that ekiga is interested is the retistar of your Voice Over Ip provider. Since my VOIP is diamondcard.us, I have to set Name: sip.diamondcard.us Registrar: sip.diamondcard.us In Accounts. From friedrich_o at web.de Mon Sep 2 09:12:03 2013 From: friedrich_o at web.de (Oliver Friedrich) Date: Mon, 02 Sep 2013 11:12:03 +0200 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <5223DFB7.7080004@verizon.net> References: <5223D011.6030907@web.de> <5223DFB7.7080004@verizon.net> Message-ID: <52245663.7060806@web.de> On 02.09.2013 02:45, junk_no_spam wrote: > On 09/01/2013 06:38 PM, friedrich_o at web.de wrote: > >> The debug messages don't show the resolved ip either but the uri (like >> sip:123 at mydyndnsserver.com) > > The registar that ekiga is interested is the retistar of your Voice > Over Ip provider. Since my VOIP is diamondcard.us, I have to set > Name: sip.diamondcard.us > Registrar: sip.diamondcard.us > > In Accounts. > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > https://mail.gnome.org/mailman/listinfo/ekiga-list > Thanks, in my case the "provider" is my fritzbox (router) that forwards the calls to ekiga. As I said - with the ip address it work. The problem is only that I want to use dyndns. From junk_no_spam at verizon.net Mon Sep 2 10:40:26 2013 From: junk_no_spam at verizon.net (junk_no_spam) Date: Mon, 02 Sep 2013 05:40:26 -0500 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <52245663.7060806@web.de> References: <5223D011.6030907@web.de> <5223DFB7.7080004@verizon.net> <52245663.7060806@web.de> Message-ID: <52246B1A.9020800@verizon.net> On 09/02/2013 04:12 AM, Oliver Friedrich wrote: > in my case the "provider" is my fritzbox (router) that forwards the > calls to ekiga. As I said - with the ip address it work. The problem is > only that I want to use dyndns. Let's pick some terms to agree upon. Your Internet Service Provider (ISP) provides you with an Internet connection. You have selected dyndns to be a domain name provider. It joins your dyndns domain name to your ISP ip address. All ekiga wants is a Voice Over IP (VOIP) provider which you use in ekiga Account registar and Name fields. When you fire up ekiga, it calls your VOIP provider's server, gives your id/pw and your VOIP's servers now knows your ip address provided by your ISP. It then sends any calls back to that IP, which happens to be your router's Internet WAN address. As you can see, dyndns was nowhere in the loop. For ekiga software to receive a call, someone calls your VOIP id, the VOIP server looks up your id, gets the ip address where your id/pw showed up on, and sends a udp packet to that IP on port 5060. Your router should forward that WAN packet to your LAN ip node where the ekiga application would accept the incoming call. In my setup, I have three nodes on my LAN. I have to tell the router to forward the ekiga/sip ports to the WAN ip address where I have the ekiga application running in order to originate or receive any calls. You either hard code the LAN ip address to forward your SIP traffic, or you have to configure your router to dynamically configure the required ports to the LAN ip address which opens port 3478 or 3479, if possible. I am pretty sure you will not get dyndns to provide your LAN ip address unless your router is in a bridge mode where the LAN ip address is the WAN ip address. If you are running linux, "hostname --ip-address" would return your LAN ip, To get your WAN ip address wget -nv -O- http://cfaj.freeshell.org/ipaddr.cgi From grep at gmx.us Mon Sep 2 12:47:10 2013 From: grep at gmx.us (That Guy) Date: Mon, 02 Sep 2013 08:47:10 -0400 Subject: [Ekiga-list] dyndns & WAN Message-ID: <522488CE.9090206@gmx.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > To get your WAN ip address > wget -nv -O- http://cfaj.freeshell.org/ipaddr.cgi or you can use: $ curl ident.me #for your WAN also curl ifconfig.me ; icanhazip ; tnx.nl/ip ; myip.dnsomatic.om I use the first one and created a simple alias for it and works great. _________________________________________________________________________ GnuPG Fingerprint: 7770 D186 A06E A329 2217 3161 63EB F269 37B8 8644 _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSJIjIAAoJEGPr8mk3uIZEkZkQAItrs9TJ050DiXMPg8QHaQP0 5kPgU+P5F/YIvsduWqZAAaaLTYGScpF1CVJBFC+L32MhYtzJuRDz23zOOqzvA6eL h6ZYcbnSsfG8QU1pJpTuHVfK+tDP6OBvqaG+zvv/DRxJhJ3NbD2Hdwk0KDXy8gfc TJdnc4JxKP2+yBts+2SjRnLDcAA6H8/vQrFkRE+O5Hq+XZwhwGnIPG7OCNVcbhlH Ufq97SbXrWoJRP9FRjGLoDP+dbkCYpzfHU7kzNXg2uNujH8Iui8nfvWtmuT76AKt yyp/q0EGc9AWi2DGCgM15SMt+ed+2C6GyeRRtwVuU6pZm+OjFSmfSOw+4XwrLbHm PpXjaZBa2xS+ZIwi3XEKB2s95FKRu7g8wDIIYXrmM8ZNQViF1WUqG68cbIIwnaRr NO6L/Lfafd6jIe3p8CxJoK+wXEuahXrqDAUJve3AT9sJsEy3hBsQL5bMn2XslVkN lfZgqjcYlA2OofQ14mIhVGQffNYFHExyhK9l9kpWu0pAkHkyoCnFWWH/TPCahQIr /05GtAbfOhYrWbwvsLSS4qFTE/PmZzd6DdwqsrkMxEndYULMIf4UO51br9DTwkaU S5YfPEnnr4BjzNRUJ2a+ips+1SLZeqTRyWc2k735S7zd0TS3U/HGvB6UvtWdqQtR 2Hyk70CRi0aU9Yp6sMYf =h9wG -----END PGP SIGNATURE----- From friedrich_o at web.de Tue Sep 3 12:11:31 2013 From: friedrich_o at web.de (Oliver Friedrich) Date: Tue, 03 Sep 2013 14:11:31 +0200 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <52246B1A.9020800@verizon.net> References: <5223D011.6030907@web.de> <5223DFB7.7080004@verizon.net> <52245663.7060806@web.de> <52246B1A.9020800@verizon.net> Message-ID: <5225D1F3.5050803@web.de> On 02.09.2013 12:40, junk_no_spam wrote: > On 09/02/2013 04:12 AM, Oliver Friedrich wrote: > >> in my case the "provider" is my fritzbox (router) that forwards the >> calls to ekiga. As I said - with the ip address it work. The problem is >> only that I want to use dyndns. > > Let's pick some terms to agree upon. > Your Internet Service Provider (ISP) provides you with an Internet > connection. > > You have selected dyndns to be a domain name provider. It joins your > dyndns domain name to your ISP ip address. > > All ekiga wants is a Voice Over IP (VOIP) provider which you use in > ekiga Account registar and Name fields. > > When you fire up ekiga, it calls your VOIP provider's server, gives > your id/pw and your VOIP's servers now knows your ip address provided > by your ISP. > > It then sends any calls back to that IP, which happens to be your > router's Internet WAN address. > > As you can see, dyndns was nowhere in the loop. For ekiga software to > receive a call, someone calls your VOIP id, the VOIP server looks up > your id, gets the ip address where your id/pw showed up on, and sends > a udp packet to that IP on port 5060. Your router should forward that > WAN packet to your LAN ip node where the ekiga application would > accept the incoming call. > > In my setup, I have three nodes on my LAN. I have to tell the router > to forward the ekiga/sip ports to the WAN ip address where I have the > ekiga application running in order to originate or receive any calls. > > You either hard code the LAN ip address to forward your SIP traffic, > or you have to configure your router to dynamically configure the > required ports to the LAN ip address which opens port 3478 or 3479, if > possible. > > I am pretty sure you will not get dyndns to provide your LAN ip > address unless your router is in a bridge mode where the LAN ip > address is the WAN ip address. Okay - let me put that straight: I can use ekiga with the WAN IP of my router as registrar (since it works obviously perfectly) but I can't use the dyndns which should be (per definition) nothing else but a mapping between hostname an ip. It sounds a bit weird to me. Also I don't use the voip provider directly (which I wanted to make clear by saying: the registrar is my router). It is connected to the isp (which in my case is the voip provider) and forwards calls to it's clients - e.g. ekiga (or the "normal" telephone). And since it shall forward the calls not only in LAN but over WAN, I need to tell ekiga the WAN ip of my router - and here I want to use dyndns..... So you see: in this loop there is dyndns which doesn't work :( From el_gallo_azul at yahoo.com Tue Sep 3 12:53:58 2013 From: el_gallo_azul at yahoo.com (el_gallo_azul) Date: Tue, 3 Sep 2013 05:53:58 -0700 (PDT) Subject: [Ekiga-list] Rv: registrar over dnydns? In-Reply-To: <5225D1F3.5050803@web.de> References: <5223D011.6030907@web.de> <5223DFB7.7080004@verizon.net> <52245663.7060806@web.de> <52246B1A.9020800@verizon.net> <5225D1F3.5050803@web.de> Message-ID: <1378212838.91380.YahooMailNeo@web161603.mail.bf1.yahoo.com> I have a Fritz!Box 7390. I have my landline number set up there, which is under Telephony>Telephone numbers in the Fritz!Box interface. I also have two of my other SIP accounts set up there, with dummy telephone numbers. The result of all that is that if, for example, you contact my Ekiga SIP address, my phone rings. I can also use Ekiga softphone for video calls if I want, which doesn't use any of these Fritz!Box telephony "numbers", but uses my ADSL connection to the internet. Importantly, I use the SIP registrar for softphones to make video calls, which means specifying the SIP server address as the registrar (eg. ekiga.net or sip.diamondcard.us and the corresponding usernames). I myself have set up dyndns for my Fritz!Box IP address, but I haven't used it for a long time since AVM (the Fritz!Box manufacturer) made MyFritz! available for Android. ? Greg Flint PO Box 642 Parap NT 0804 Australia SIP: el_gallo_azul at ekiga.net Phone +61 (0)8 8945 1725 Mobile +61 (0)428 279 021 Australian Central Standard Time (ACST) = UTC/GMT+9.5 ----- Mensaje reenviado ----- De: Oliver Friedrich Para: Ekiga mailing list Enviado: Martes 3 de septiembre de 2013 21:41 Asunto: Re: [Ekiga-list] registrar over dnydns? On 02.09.2013 12:40, junk_no_spam wrote: > On 09/02/2013 04:12 AM, Oliver Friedrich wrote: > >> in my case the "provider" is my fritzbox (router) that forwards the >> calls to ekiga. As I said - with the ip address it work. The problem is >> only that I want to use dyndns. > > Let's pick some terms to agree upon. > Your Internet Service Provider (ISP) provides you with an Internet > connection. > > You have selected dyndns to be a domain name provider. It joins your > dyndns domain name to your ISP ip address. > > All ekiga wants is a Voice Over IP (VOIP) provider which you use in > ekiga Account registar and Name fields. > > When you fire up ekiga, it calls your VOIP provider's server, gives > your id/pw and your VOIP's servers now knows your ip address provided > by your ISP. > > It then sends any calls back to that IP, which happens to be your > router's Internet WAN address. > > As you can see, dyndns was nowhere in the loop. For ekiga software to > receive a call, someone calls your VOIP id, the VOIP server looks up > your id, gets the ip address where your id/pw showed up on, and sends > a udp packet to that IP on port 5060. Your router should forward that > WAN packet to your LAN ip node where the ekiga application would > accept the incoming call. > > In my setup, I have three nodes on my LAN. I have to tell the router > to forward the ekiga/sip ports to the WAN ip address where I have the > ekiga application running in order to originate or receive any calls. > > You either hard code the LAN ip address to forward your SIP traffic, > or you have to configure your router to dynamically configure the > required ports to the LAN ip address which opens port 3478 or 3479, if > possible. > > I am pretty sure you will not get dyndns to provide your LAN ip > address unless your router is in a bridge mode where the LAN ip > address is the WAN ip address. Okay - let me put that straight: I can use ekiga with the WAN IP of my router as registrar (since it works obviously perfectly) but I can't use the dyndns which should be (per definition) nothing else but a mapping between hostname an ip. It sounds a bit weird to me. Also I don't use the voip provider directly (which I wanted to make clear by saying: the registrar is my router). It is connected to the isp (which in my case is the voip provider) and forwards calls to it's clients - e.g. ekiga (or the "normal" telephone). And since it shall forward the calls not only in LAN but over WAN, I need to tell ekiga the WAN ip of my router - and here I want to use dyndns..... So you see: in this loop there is dyndns which doesn't work :( _______________________________________________ ekiga-list mailing list ekiga-list at gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From grep at gmx.us Wed Sep 4 14:46:51 2013 From: grep at gmx.us (That Guy) Date: Wed, 04 Sep 2013 10:46:51 -0400 Subject: [Ekiga-list] usability Message-ID: <522747DB.4000302@gmx.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 snip >> You either hard code the LAN ip address to forward your SIP traffic, >> or you have to configure your router to dynamically configure the >> required ports to the LAN ip address which opens port 3478 or 3479, if >> possible. >> >> I am pretty sure you will not get dyndns to provide your LAN ip >> address unless your router is in a bridge mode where the LAN ip >> address is the WAN ip address. > Okay - let me put that straight: > I can use ekiga with the WAN IP of my router as registrar (since it > works obviously perfectly) but I can't use the dyndns which should be > (per definition) nothing else but a mapping between hostname an ip. It > sounds a bit weird to me. > Also I don't use the voip provider directly (which I wanted to make > clear by saying: the registrar is my router). > It is connected to the isp (which in my case is the voip provider) and > forwards calls to it's clients - e.g. ekiga (or the "normal" telephone). > And since it shall forward the calls not only in LAN but over WAN, I > need to tell ekiga the WAN ip of my router - and here I want to use > dyndns..... snip WOW! OK I don't feel so dumb anymore and it is clear to me why none of these have caught on and why people still use $kype. If this is what you've got to do/understand to get an FOSS VoIP client up and running I'm guessing that $kype will continue to have a long LONG life of spying ahead. Even if one get this up and running the chances that the person you hope to communicate will also be able to are slim to none. Sad... FOSS for once can't hold a candle to the proprietary crap and that really is a bummer. As long as this is the case none of these options will go anywhere beyond a TINY group of individuals and will eventually vanish. :-( I am not one to champion usability as I think that hurts lots of software but in this case... ya, you've got a usability problem! A HUGE ONE! The more I read on this mailing list the more helpless I feel. I not a complete noob by any stretch of the imagination... _________________________________________________________________________ GnuPG Fingerprint: 7770 D186 A06E A329 2217 3161 63EB F269 37B8 8644 _________________________________________________________________________ ?If you?re doing nothing wrong, you have nothing to hide from the giant surveillance apparatus that the government?s been hiding.? ? Stephen Colbert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSJ0fZAAoJEGPr8mk3uIZEo5MQANEcwrEi6Q4a1wIkUagrt+O2 r7TEYJmghkrETlRCePOKsnBmzeh3JbCxVf2ryn1RosBBmZRWVcCaWhTtBLwLsyEu S6yVY0gasGetz8jen1DuS1ZWww6xlRCLXpb3sPATkQLeOjKCWWU1sNSUOykWshW/ 9hT6c+n8yj7+2gxHLWQMBVuAqupovY098HAvcnHXsFjjCtwewICm9ghhFv1dGKxy A3n1ehMkQKXuu2Z41C2o/YcXjdOrdFXrkSuXLjVEDhUuhD9bTM0oMMLCPdIpv8nG blNpmssavRW3Awebk/hVymMF3hw7quLTntYJMBUQeTGsdshzAIZg+BpvKKpjrdRt AwCe0w8f0YbHbrONj9M9UDNXSEh5SAkmSCBjIRx61C7+X4m55I4rNy+VLZ2XaDb8 ja9p6H7BZwVFI3M6aWX9Bmw0QSdtsUzdDXm8ftt+ywXQ+h+7stQgm8kcdAmwviX0 aXnQRExKFX5VfZdO6kAbwBANKZQ7QcIFAHQ4mdqOFBwdKPpvog7l09WjhLSDoVsO hc0igFQM+bvc/gc78srtuYzq3pA9FaVtiJXOToPM01AksWwlWQtCnGbWGR32EVFE ZhK97RZrG/KjyljOMDYtPsQJgt3FzGh7Bi0N0zj0HoqoxIfh+xQmnODj5dZCGDW2 vtJ5BN0RxRxfx6p9+lME =m0l2 -----END PGP SIGNATURE----- From stuart at gathman.org Wed Sep 4 15:28:35 2013 From: stuart at gathman.org (Stuart Gathman) Date: Wed, 04 Sep 2013 11:28:35 -0400 Subject: [Ekiga-list] usability In-Reply-To: <522747DB.4000302@gmx.us> References: <522747DB.4000302@gmx.us> Message-ID: <522751A3.1040408@gathman.org> On 09/04/2013 10:46 AM, That Guy wrote: > snip > > WOW! OK I don't feel so dumb anymore and it is clear to me why none of > these have caught on and why people still use $kype. If this is what > you've got to do/understand to get an FOSS VoIP client up and running > I'm guessing that $kype will continue to have a long LONG life of spying > ahead. > Even if one get this up and running the chances that the person you > hope to communicate will also be able to are slim to none. Sad... > FOSS for once can't hold a candle to the proprietary crap and that > really is a bummer. As long as this is the case none of these options > will go anywhere beyond a TINY group of individuals and will eventually > vanish. :-( > I am not one to champion usability as I think that hurts lots of > software but in this case... ya, you've got a usability problem! A HUGE > ONE! The more I read on this mailing list the more helpless I feel. I > not a complete noob by any stretch of the imagination... > This is not a FOSS problem, but a protocol problem. All these complex problems are caused by a combination of NAT - which is a work around for IP4 running out of addresses, and multi-port protocols like SIP or H323. If IP6 was fully deployed, you would not have to do/know all that. If Ekiga used IAX, it would work much more transparently with NAT as well. Skype uses a protocol very similar to IAX in terms of muliplexing multiple logical channels over a single TCP/UDP port. But please note that you do NOT have do/know all that if you use a commercial intermediary (as you must do with Skype as well). Using Ekiga with diamondcard, nextiva, or other SIP providers is painless - NAT and all. All the tricky workarounds are done by the provider. Using SIP peer to peer is complex because both sides have to act as a server as well as a client - and the server side requires the NAT work arounds. From fred.k at member.fsf.org Thu Sep 5 05:21:08 2013 From: fred.k at member.fsf.org (fred k) Date: Thu, 05 Sep 2013 14:21:08 +0900 Subject: [Ekiga-list] usability In-Reply-To: <522747DB.4000302@gmx.us> References: <522747DB.4000302@gmx.us> Message-ID: <522814C4.9060203@member.fsf.org> Hi That Guy and all gals and guys, Let me discern technical issues and non-tech ones. Plus a question regarding "SIP provider" at the bottom. That Guy wrote: > $kype will continue to have a long LONG life of spying ahead. I agree but this is not a technical issue here. > ...the chances that the person you hope to communicate will also be able to are slim to none. Maybe right. I'm struggling to support non-techie users of Ekiga, including *me*, that's why I'm on this mailing list. I'm struggling to support non-techy Skype users, too, to some lesser degree. > FOSS for once can't hold a candle to the proprietary crap and ... Looks like half-tech issue, too. Assuming you said Freedom-and-Open-Source-Software, "can't hold" is an over-generalization. Free or proprietary, SIP or skype-proprietary protocol, user interface style one or the other, they are all *different* matters. You are mostly hitting protocol problem and user interface design problem. My observation is that Skype is hiding protocol problem (I'd say 'challenges' like NAT traverse, SIP, pure peer-to-peer) with their possibly dirty tricks a.k.a proprietary protocol. You can't rely these tricks in the free-and-open world where only clever tricks are allowed or you will be signed out. > ...beyond a *tiny* group of individuals and will eventually vanish. Right. Looks like non-tech issue but very political. Rest assured should we vanish, then the large and precious Ekiga resource will be picked up by the next *tiny* group and flourish. I'm happily optimistic about this model but I worry, rather, should I settle with the proprietary, even smaller number of companies (one?) would vanish or worse, charge us, snoop us, and/or force us into that dirty world. Stuart wrote: > This is not a FOSS problem, but a protocol problem. All these complex problems ... Yeah, I think I understand it clearly now. And learn IAX a bit. Thanks. > ... you do *not* have [to] do/know all that if you use a commercial... I have a question. When you use commercial SIP provider, do you mean your voice/video/data goes through a server at the SIP provider before reaching called party (i.e., non-peer-to-peer model)? If this is the case, why NAT problems goes away? (Pointer to this ML archive or another appreciated to save your time.) My understanding is that in Ekiga (or SIP in general, possibly), called party address to IP address:port translation is done at the SIP server and following call-setup/negotiations and payload communications are peer-to-peer. fred From sevmek at free.fr Thu Sep 5 14:58:08 2013 From: sevmek at free.fr (Yannick) Date: Thu, 05 Sep 2013 16:58:08 +0200 Subject: [Ekiga-list] usability In-Reply-To: <522814C4.9060203@member.fsf.org> References: <522747DB.4000302@gmx.us> <522814C4.9060203@member.fsf.org> Message-ID: <1378393088.3477.11.camel@athena.fbx.proxad.net> Le jeudi 05 septembre 2013 ? 14:21 +0900, fred k a ?crit : > > ... you do *not* have [to] do/know all that if you use a > commercial... > I have a question. When you use commercial SIP provider, do you mean > your voice/video/data goes through a server at the SIP provider before > reaching called party (i.e., non-peer-to-peer model)? If this is the > case, why NAT problems goes away? (Pointer to this ML archive or > another appreciated to save your time.) My understanding is that in > Ekiga (or SIP in general, possibly), called party address to IP > address:port translation is done at the SIP server and following > call-setup/negotiations and payload communications are peer-to-peer. I assume he was referring to a SIP proxy, i.e. the commercial SIP provider provide a proxy to relay the communications (audio, video, i.e. the RTP steams). In this case it is not end-to-end anymore, but it is part of the SIP specification. This can solve the NAT issue. The solution to avoid having a commercial provider and solve the NAT issue is something like the p2psip effort: https://en.wikipedia.org/wiki/P2psip http://www.ietf.org/mail-archive/web/p2psip/current/maillist.html Beside, we could improve the ekiga tools for supporting NAT with an ICE implementation: https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment Even if it will cover most cases and improve Ekiga, ICE will probably not be enough without a proxy somewhere, which p2psip try to implement directly in all clients. And I doubt IPV6 will solve this issue, as it will probably remains bad habits from some people to put NAT, justifying it by "security", even if the specification try explicitly to avoid NATs. Still IPv6 will certainly help a lot. Regards, Yannick From mtbc at ixod.org Thu Sep 5 16:58:11 2013 From: mtbc at ixod.org (Mark Carroll) Date: Thu, 05 Sep 2013 17:58:11 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87d2oslbf2.fsf@ixod.org> (Mark Carroll's message of "Sun, 01 Sep 2013 18:05:53 +0100") References: <87d2oslbf2.fsf@ixod.org> Message-ID: <87fvtjb3z0.fsf@ixod.org> Still no luck, latest log in http://pastebin.com/fnmF8CY0 where I tried configuring SIP to listen on 5050 instead: I hoped to be able to initiate calls, but I can't even register with ekiga.net. Basically, is it possible at all to use ekiga from behind NAT if UDP 5060 is blocked? (I have all the other ports forwarded.) -- Mark From stuart at gathman.org Thu Sep 5 18:38:23 2013 From: stuart at gathman.org (Stuart Gathman) Date: Thu, 05 Sep 2013 14:38:23 -0400 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87d2oslbf2.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> Message-ID: <5228CF9F.2020608@gathman.org> On 09/01/2013 01:05 PM, Mark Carroll wrote: > I am having trouble with ekiga not registering when behind a BT Home > Hub running software version 8.1.H.U (Type A), whether or not I enable > network detection in the preferences. The -d 4 log is pasted at > http://pastebin.com/bd6kAWgp > > In probing the port forwarding I set up, I discover that it is doing all > the forwarding correctly except for UDP port 5060. 5059 and 5061 are > forwarding just fine, as are UDP 3478,9 and TCP 1720. I am thus guessing > it has some built-in grabbing of 5060 for its own purposes. > > Would this forwarding issue explain the failure to register with > ekiga.net? > > Is it possible to use Ekiga, at least to initiate SIP calls, if it is > behind NAT that won't forward 5060? > > Is there some trick to getting this device to actually forward 5060? > You haven't established that the device is to blame. It could be your ISP blocking port 5060 (as some have infamously been know to do to promote their own VOIP solutions). If you are somewhat technical, consider running a linux firewall (including firewall on a CD) in place of the BT Home Hub. This will let you trace (tcpdump) packets coming into the router to determine if the ISP is blocking them. Short of that, you could connect your PC directly to the ISP, and either run a packet trace (does Windows have a packet trace?) or see if it starts working. If it starts working, that definitely blames the BT Home Hub. If it still doesn't work, you really need a packet trace to diagnose further. From mtbc at ixod.org Thu Sep 5 19:26:43 2013 From: mtbc at ixod.org (Mark Carroll) Date: Thu, 05 Sep 2013 20:26:43 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <5228CF9F.2020608@gathman.org> (Stuart Gathman's message of "Thu, 05 Sep 2013 14:38:23 -0400") References: <87d2oslbf2.fsf@ixod.org> <5228CF9F.2020608@gathman.org> Message-ID: <87zjrroyrw.fsf@ixod.org> Stuart Gathman writes: > You haven't established that the device is to blame. It could be your > ISP blocking port 5060 (as some have infamously been know to do to > promote their own VOIP solutions). True. The device does support incoming 5060 for people who use the ISP's VoIP service; I don't know if they might actually selectively firewall those who don't use it, rather than having their router/modem do it. Alas, I'm trying to sort this out remotely, but your suggestions are good, and next time I'm on-site I'll bring along a ADSL router I trust and see how things are with that in place instead. -- Mark From mtbc at ixod.org Thu Sep 5 19:27:21 2013 From: mtbc at ixod.org (Mark Carroll) Date: Thu, 05 Sep 2013 20:27:21 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <5228CF9F.2020608@gathman.org> (Stuart Gathman's message of "Thu, 05 Sep 2013 14:38:23 -0400") References: <87d2oslbf2.fsf@ixod.org> <5228CF9F.2020608@gathman.org> Message-ID: <87vc2foyqu.fsf@ixod.org> Obvious followup, though: if the ISP does firewall UDP 5060 upstream, then is there any hope? -- Mark From geo.cherchetout at laposte.net Thu Sep 5 19:42:27 2013 From: geo.cherchetout at laposte.net (gegetel) Date: Thu, 05 Sep 2013 21:42:27 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87d2oslbf2.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> Message-ID: <5228DEA3.2090608@laposte.net> Le 01/09/2013 19:05, *Mark Carroll* wrote: > Is it possible to use Ekiga, at least to initiate SIP calls, if it is > behind NAT that won't forward 5060? Using gconf-editor (apps > ekiga > protocols > sip), you can set listen_port = 5061 and place and receive SIP calls as well. :-) From fred.k at member.fsf.org Thu Sep 5 22:53:41 2013 From: fred.k at member.fsf.org (fred k) Date: Fri, 06 Sep 2013 07:53:41 +0900 Subject: [Ekiga-list] usability In-Reply-To: <1378393088.3477.11.camel@athena.fbx.proxad.net> References: <522747DB.4000302@gmx.us> <522814C4.9060203@member.fsf.org> <1378393088.3477.11.camel@athena.fbx.proxad.net> Message-ID: <52290B75.4050304@member.fsf.org> Thanks Yannick, very informative Yannick wrote(excerpts): > I assume he was referring to a SIP proxy, ... can solve the NAT issue. > ...we could improve the ekiga tools for supporting NAT with an ICE... > ...I doubt IPV6 will solve this issue... fred From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Sep 6 10:57:35 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 06 Sep 2013 12:57:35 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <5228DEA3.2090608@laposte.net> References: <87d2oslbf2.fsf@ixod.org> <5228DEA3.2090608@laposte.net> Message-ID: <5229B51F.10703@pu-pm.univ-fcomte.fr> On 05/09/13 21:42, gegetel wrote: > Le 01/09/2013 19:05, *Mark Carroll* wrote: > >> Is it possible to use Ekiga, at least to initiate SIP calls, if it is >> behind NAT that won't forward 5060? > > Using gconf-editor (apps > ekiga > protocols > sip), you can set > listen_port = 5061 and place and receive SIP calls as well. :-) Indeed, good idea to try. -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Sep 6 11:01:45 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 06 Sep 2013 13:01:45 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87d2oslbf2.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> Message-ID: <5229B619.1090100@pu-pm.univ-fcomte.fr> On 01/09/13 19:05, Mark Carroll wrote: > I am having trouble with ekiga not registering when behind a BT Home > Hub running software version 8.1.H.U (Type A), whether or not I enable > network detection in the preferences. The -d 4 log is pasted at > http://pastebin.com/bd6kAWgp Both logs report symmetric nat, and in this case ekiga voluntarily *prevents* you from registering. This is probably caused by 5060 being blocked. Are 5063 to 5060 blocked too or not? > In probing the port forwarding I set up, I discover that it is doing all > the forwarding correctly except for UDP port 5060. 5059 and 5061 are > forwarding just fine, as are UDP 3478,9 and TCP 1720. I am thus guessing > it has some built-in grabbing of 5060 for its own purposes. > > Would this forwarding issue explain the failure to register with > ekiga.net? I think yes, but I am not sure :( I have to make tests for that. > Is it possible to use Ekiga, at least to initiate SIP calls, if it is > behind NAT that won't forward 5060? I think yes, but I am not sure :( I have to make tests for that. So a good idea is to make ekiga use a port different than 5060, as written in previous e-mail. -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Sep 6 11:05:39 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 06 Sep 2013 13:05:39 +0200 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <5223D011.6030907@web.de> References: <5223D011.6030907@web.de> Message-ID: <5229B703.8080308@pu-pm.univ-fcomte.fr> On 02/09/13 01:38, friedrich_o at web.de wrote: > Hello > > when I enter the local domain name of the registrar (in my case > "fritz.box") there is no problem. But this only works in LAN. > Over the internet I could use the ip I got from my isp - but this is > unconvenient, although it works. So I thought I could just enter a > dyndns uri - but then ekiga doesn't connect to my router. > Is there no support for such connections or am I doing something wrong? > The debug messages don't show the resolved ip either but the uri (like > sip:123 at mydyndnsserver.com) To make short: could you send us/me a -d 4 log when using dyndns and tell what is the problem ("ekiga doesn't connect to my router" = does not register??)? -- Eugen From mtbc at ixod.org Fri Sep 6 11:10:10 2013 From: mtbc at ixod.org (Mark Carroll) Date: Fri, 06 Sep 2013 12:10:10 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <5229B619.1090100@pu-pm.univ-fcomte.fr> (Eugen Dedu's message of "Fri, 06 Sep 2013 13:01:45 +0200") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> Message-ID: <871u529pf1.fsf@ixod.org> Eugen Dedu writes: (snip) > Are 5063 to 5060 blocked too or not? All of UDP 5000 - 5100 are forwarded okay except for 5060. (snip) > So a good idea is to make ekiga use a port different than 5060, as > written in previous e-mail. Alas, it still fails if I try 5050, -d 4 at http://pastebin.com/fnmF8CY0 (That is forwarded okay.) If there's anything extra I can do at my end to help you test (compile a different version or something), I'm happy to try. Thanks, Mark From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Sep 6 11:20:23 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 06 Sep 2013 13:20:23 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <871u529pf1.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> Message-ID: <5229BA77.5020307@pu-pm.univ-fcomte.fr> On 06/09/13 13:10, Mark Carroll wrote: > Eugen Dedu writes: > (snip) >> Are 5063 to 5060 blocked too or not? > > All of UDP 5000 - 5100 are forwarded okay except for 5060. > > (snip) >> So a good idea is to make ekiga use a port different than 5060, as >> written in previous e-mail. > > Alas, it still fails if I try 5050, -d 4 at http://pastebin.com/fnmF8CY0 > (That is forwarded okay.) It still reports symmetric nat => registration stopped. > If there's anything extra I can do at my end to help you test (compile a > different version or something), I'm happy to try. An idea is to let registration be made even if it reports symmetric nat. In ekiga 4.0.1, in file lib/engine/components/opal/opal-call-manager.cpp, change at line 822: if (result == PSTUNClient::SymmetricNat || result == PSTUNClient::BlockedNat || result == PSTUNClient::PartialBlockedNat) { to this: if (result == PSTUNClient::BlockedNat || result == PSTUNClient::PartialBlockedNat) { Compile, and start ekiga with src/ekiga when being in ekiga directory. -- Eugen From gj.teune at gosensit.nl Fri Sep 6 13:53:34 2013 From: gj.teune at gosensit.nl (Gert-Jan Teune) Date: Fri, 06 Sep 2013 13:53:34 +0000 Subject: [Ekiga-list] SIP Domain Message-ID: When I phone to for example a mobile phone no, I have to add my SIP Domain. SIP:0612345678 at MySIPDomain.com Is it possible to add automaticly to al phone no's? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Sep 6 14:20:10 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 06 Sep 2013 16:20:10 +0200 Subject: [Ekiga-list] SIP Domain In-Reply-To: References: Message-ID: <5229E49A.3000006@pu-pm.univ-fcomte.fr> On 06/09/13 15:53, Gert-Jan Teune wrote: > When I phone to for example a mobile phone no, I have to add my SIP Domain. > SIP:0612345678 at MySIPDomain.com > > Is it possible to add automaticly to al phone no's? You can call either using roster, or manually entering the number each time. In the first case you can add your domain once for all for each contact. In the second, you *have to* choose from the combobox which automatically opens when typing. Does this "feature" (no need to type @ host part) really matter to you? -- Eugen From geo.cherchetout at laposte.net Sat Sep 7 07:25:49 2013 From: geo.cherchetout at laposte.net (gegetel) Date: Sat, 07 Sep 2013 09:25:49 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87d2oslbf2.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> Message-ID: <522AD4FD.6040206@laposte.net> Le 01/09/2013 19:05, *Mark Carroll* wrote: > I am having trouble with ekiga not registering when behind a BT Home > Hub running software version 8.1.H.U (Type A) If BT means British Telecom, perhaps your "BT Home Hub" is really a Technicolor/Thomson modem ? This kind of hardware needs specific settings for you to use SIP softphones, but all these settings maybe are only possible if the firmware is a complete firmware rather than a "castrated" one. The most important of these settings is transforming symmetric NAT to Cone Nat, another one is to disable SIP ALG, but there is still another one I have to remember about STUN. Do you have telnet access to your Home Hub ? Do you have ftp access to your Home Hub ? Assuming you have http access to it, using the appropriate menu, please backup its configuration and say us if this backup is a human readable file. From geo.cherchetout at laposte.net Sat Sep 7 08:38:30 2013 From: geo.cherchetout at laposte.net (gegetel) Date: Sat, 07 Sep 2013 10:38:30 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522AD4FD.6040206@laposte.net> References: <87d2oslbf2.fsf@ixod.org> <522AD4FD.6040206@laposte.net> Message-ID: <522AE606.7050200@laposte.net> This *could* be useful to get a complete firmware, but be very careful! http://www.josephn.net/unlocking_bt_home_hub From friedrich_o at web.de Sat Sep 7 12:03:19 2013 From: friedrich_o at web.de (Oliver Friedrich) Date: Sat, 07 Sep 2013 14:03:19 +0200 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <5229B703.8080308@pu-pm.univ-fcomte.fr> References: <5223D011.6030907@web.de> <5229B703.8080308@pu-pm.univ-fcomte.fr> Message-ID: <522B1607.40304@web.de> On 06.09.2013 13:05, Eugen Dedu wrote: > On 02/09/13 01:38, friedrich_o at web.de wrote: >> Hello >> >> when I enter the local domain name of the registrar (in my case >> "fritz.box") there is no problem. But this only works in LAN. >> Over the internet I could use the ip I got from my isp - but this is >> unconvenient, although it works. So I thought I could just enter a >> dyndns uri - but then ekiga doesn't connect to my router. >> Is there no support for such connections or am I doing something wrong? >> The debug messages don't show the resolved ip either but the uri (like >> sip:123 at mydyndnsserver.com) > > To make short: could you send us/me a -d 4 log when using dyndns and > tell what is the problem ("ekiga doesn't connect to my router" = does > not register??)? > Of course: http://nopaste.info/1230fb41f5.html From mtbc at ixod.org Sat Sep 7 16:02:36 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sat, 07 Sep 2013 17:02:36 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522AD4FD.6040206@laposte.net> (gegetel's message of "Sat, 07 Sep 2013 09:25:49 +0200") References: <87d2oslbf2.fsf@ixod.org> <522AD4FD.6040206@laposte.net> Message-ID: <87fvtgk4bn.fsf@ixod.org> Thank you. I couldn't find any telnet access and in looking at its configuration backup I don't recognize the kind of file at all. Among the binary code in the file, some of the earliest strings are, THENC CANT-2BT Home Hub 2.0A 8.1.H.U (so, model number, firmware version), but that's about as good as it gets. Still, it was a very good idea to look - it was worth a try! Perhaps it has a header and then is compressed after around the first 256 bytes, though not in a way I've yet unravelled. Some googling suggests that it's a Thompson TG797N with the telnet disabled, although one can still get in via JTAG and reenable it. http://www.psidoc.com/showthread.php/7-How-to-hack-or-unlock-your-home-hub-2.0A-via-software. described how to flash it with hacked firmware but hopefully I can avoid having to do that. -- Mark From mtbc at ixod.org Sat Sep 7 16:34:53 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sat, 07 Sep 2013 17:34:53 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <5229BA77.5020307@pu-pm.univ-fcomte.fr> (Eugen Dedu's message of "Fri, 06 Sep 2013 13:20:23 +0200") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> Message-ID: <87txhwegk2.fsf@ixod.org> Eugen Dedu writes: > An idea is to let registration be made even if it reports symmetric nat. > In ekiga 4.0.1, in file > lib/engine/components/opal/opal-call-manager.cpp, change at line 822: > > if (result == PSTUNClient::SymmetricNat > || result == PSTUNClient::BlockedNat > || result == PSTUNClient::PartialBlockedNat) { > to this: > if (result == PSTUNClient::BlockedNat > || result == PSTUNClient::PartialBlockedNat) { > > Compile, and start ekiga with src/ekiga when being in ekiga directory. Ha, success, thank you very much! That works just fine now, at least initiating a call with both audio and video. -- Mark From mtbc at ixod.org Sat Sep 7 16:36:42 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sat, 07 Sep 2013 17:36:42 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87txhwegk2.fsf@ixod.org> (Mark Carroll's message of "Sat, 07 Sep 2013 17:34:53 +0100") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> Message-ID: <87mwnoegh1.fsf@ixod.org> Oh, but I should add -- with Ekiga 4.0.1 at the receiving end, I still see the issue where for an incoming call nothing came up to let me pick it up, it just told me afterward it had missed the call. Downgrading to Ekiga 3.2.7 fixes that one. (Linux, with ctwm window manager.) -- Mark From Eugen.Dedu at pu-pm.univ-fcomte.fr Sat Sep 7 16:42:31 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Sat, 07 Sep 2013 18:42:31 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87mwnoegh1.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> Message-ID: <522B5777.6030705@pu-pm.univ-fcomte.fr> On 07/09/13 18:36, Mark Carroll wrote: > Oh, but I should add -- with Ekiga 4.0.1 at the receiving end, I still > see the issue where for an incoming call nothing came up to let me pick > it up, it just told me afterward it had missed the call. Downgrading to > Ekiga 3.2.7 fixes that one. (Linux, with ctwm window manager.) So when receiving a call, 3.2.7 works, but 4.0.1 with the modification I proposed does not? In this case, could you send me the log for 4.0.1? Be sure that what you wrote is true, i.e. test for several executions of ekiga. -- Eugen From mtbc at ixod.org Sat Sep 7 16:55:02 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sat, 07 Sep 2013 17:55:02 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522B5777.6030705@pu-pm.univ-fcomte.fr> (Eugen Dedu's message of "Sat, 07 Sep 2013 18:42:31 +0200") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522B5777.6030705@pu-pm.univ-fcomte.fr> Message-ID: <87eh90efmh.fsf@ixod.org> Eugen Dedu writes: > On 07/09/13 18:36, Mark Carroll wrote: >> Oh, but I should add -- with Ekiga 4.0.1 at the receiving end, I still >> see the issue where for an incoming call nothing came up to let me pick >> it up, it just told me afterward it had missed the call. Downgrading to >> Ekiga 3.2.7 fixes that one. (Linux, with ctwm window manager.) > > So when receiving a call, 3.2.7 works, but 4.0.1 with the modification I > proposed does not? In this case, could you send me the log for 4.0.1? Yes, I'll do that. (The other end is busy right now hosting family!) I didn't try your modified 4.0.1 at the receiving end, though, as at that end (not BT!) it happily sees a cone NAT anyway. > Be sure that what you wrote is true, i.e. test for several executions of > ekiga. It's certainly something I've seen before -- ah, yes, we talked about it in February and you mentioned libnotify and wanted me to try with 4.0.1 -- it seems very reproducible, so I'll get you a log of that. -- Mark From mtbc at ixod.org Sun Sep 8 09:05:25 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sun, 08 Sep 2013 10:05:25 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522B5777.6030705@pu-pm.univ-fcomte.fr> (Eugen Dedu's message of "Sat, 07 Sep 2013 18:42:31 +0200") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522B5777.6030705@pu-pm.univ-fcomte.fr> Message-ID: <87li37r8dm.fsf@ixod.org> Eugen Dedu writes: > Be sure that what you wrote is true, i.e. test for several executions of > ekiga. Ha, now I am getting the receiving call window just fine in 4.0.1. I am playing around a bit with what other system libraries are installed but that's probably irrelevant; if I see the problem again I'll grab the -d 4 output. Thank you very much (and to others) for your help. -- Mark From stuart at gathman.org Sun Sep 8 19:54:27 2013 From: stuart at gathman.org (Stuart Gathman) Date: Sun, 08 Sep 2013 15:54:27 -0400 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87mwnoegh1.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> Message-ID: <522CD5F3.8020106@gathman.org> On 09/07/2013 12:36 PM, Mark Carroll wrote: > Oh, but I should add -- with Ekiga 4.0.1 at the receiving end, I still > see the issue where for an incoming call nothing came up to let me pick > it up, it just told me afterward it had missed the call. Downgrading to > Ekiga 3.2.7 fixes that one. (Linux, with ctwm window manager.) > Yes, this still happens to me. The problem is actually with the Desktop environment, not with Ekiga (other than refusing to provide an alternative to broken notifiers). With 4.0.1, however, you can pick up by selecting "Video Preview" from the View menu - even after it starts ringing. This has an answer button that works! Now, if I can just convince the Ekiga people to allow putting the answer icon on the toolbar. I agree that notifiers are much nicer - but only when they actually work! (Which is not under the Ekiga authors control.) From mtbc at ixod.org Sun Sep 8 21:06:17 2013 From: mtbc at ixod.org (Mark Carroll) Date: Sun, 08 Sep 2013 22:06:17 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522CD5F3.8020106@gathman.org> (Stuart Gathman's message of "Sun, 08 Sep 2013 15:54:27 -0400") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> Message-ID: <87eh8z58hi.fsf@ixod.org> Stuart Gathman writes: > Yes, this still happens to me. The problem is actually with the Desktop > environment, not with Ekiga (other than refusing to provide an > alternative to broken notifiers). As I'm using a lightweight twm derivative, I am not sure I exactly have a "Desktop environment" -- I wonder if that was my problem. Mark From stuart at gathman.org Mon Sep 9 22:23:20 2013 From: stuart at gathman.org (Stuart Gathman) Date: Mon, 09 Sep 2013 18:23:20 -0400 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87eh8z58hi.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> Message-ID: <522E4A58.3040506@gathman.org> On 09/08/2013 05:06 PM, Mark Carroll wrote: > Stuart Gathman writes: > >> Yes, this still happens to me. The problem is actually with the Desktop >> environment, not with Ekiga (other than refusing to provide an >> alternative to broken notifiers). > As I'm using a lightweight twm derivative, I am not sure I exactly have > a "Desktop environment" -- I wonder if that was my problem. > Ekiga is supposed to check whether notifiers with buttons are supported, and automatically fall back to popping up the call window (with answer button) if not. So a Desktop that does not support notifiers should not be a problem, unless there is a bug in libnotify or ekiga. However, some DEs (Desktop Environments) claim to support notifiers with buttons, but actually don't. (Or the support is broken, e.g. one of the buttons is offscreen and unclickable.) From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 15:43:22 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 17:43:22 +0200 Subject: [Ekiga-list] registrar over dnydns? In-Reply-To: <522B1607.40304@web.de> References: <5223D011.6030907@web.de> <5229B703.8080308@pu-pm.univ-fcomte.fr> <522B1607.40304@web.de> Message-ID: <522F3E1A.8030906@pu-pm.univ-fcomte.fr> On 07/09/13 14:03, Oliver Friedrich wrote: > > On 06.09.2013 13:05, Eugen Dedu wrote: >> On 02/09/13 01:38, friedrich_o at web.de wrote: >>> Hello >>> >>> when I enter the local domain name of the registrar (in my case >>> "fritz.box") there is no problem. But this only works in LAN. >>> Over the internet I could use the ip I got from my isp - but this is >>> unconvenient, although it works. So I thought I could just enter a >>> dyndns uri - but then ekiga doesn't connect to my router. >>> Is there no support for such connections or am I doing something wrong? >>> The debug messages don't show the resolved ip either but the uri (like >>> sip:123 at mydyndnsserver.com) >> >> To make short: could you send us/me a -d 4 log when using dyndns and >> tell what is the problem ("ekiga doesn't connect to my router" = does >> not register??)? >> > Of course: > http://nopaste.info/1230fb41f5.html In this log no one answers the several REGISTER requests... Please send a log with dyndns and a log with IP. If I understand correctly, registration does not work in the first case, and does work in the second, is that right? In the above log, you have changed digits (IP address) with names, and have truncated it. Please do not truncate logs, and change digits by digits, and letters by letters, otherwise I become confused. Be sure that you do not change a private address to a public one and viceversa... -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 15:49:14 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 17:49:14 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522E4A58.3040506@gathman.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> Message-ID: <522F3F7A.9030308@pu-pm.univ-fcomte.fr> On 10/09/13 00:23, Stuart Gathman wrote: > On 09/08/2013 05:06 PM, Mark Carroll wrote: >> Stuart Gathman writes: >> >>> Yes, this still happens to me. The problem is actually with the Desktop >>> environment, not with Ekiga (other than refusing to provide an >>> alternative to broken notifiers). >> As I'm using a lightweight twm derivative, I am not sure I exactly have >> a "Desktop environment" -- I wonder if that was my problem. >> > Ekiga is supposed to check whether notifiers with buttons are supported, > and automatically fall back to popping up the call window (with answer > button) if not. So a Desktop that does not support notifiers should not > be a problem, unless there is a bug in libnotify or ekiga. However, > some DEs (Desktop Environments) claim to support notifiers with buttons, > but actually don't. (Or the support is broken, e.g. one of the buttons > is offscreen and unclickable.) You are right: Ekiga does the right job, but notification programs are sometimes bad (do not show long strings), or notification server is bad (says it supports buttons, but it does not). So your request (to always show the call window) is good, I do not know what to answer, and Damien is against it anyway... -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 15:51:44 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 17:51:44 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87txhwegk2.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> Message-ID: <522F4010.1040105@pu-pm.univ-fcomte.fr> On 07/09/13 18:34, Mark Carroll wrote: > Eugen Dedu writes: > >> An idea is to let registration be made even if it reports symmetric nat. >> In ekiga 4.0.1, in file >> lib/engine/components/opal/opal-call-manager.cpp, change at line 822: >> >> if (result == PSTUNClient::SymmetricNat >> || result == PSTUNClient::BlockedNat >> || result == PSTUNClient::PartialBlockedNat) { >> to this: >> if (result == PSTUNClient::BlockedNat >> || result == PSTUNClient::PartialBlockedNat) { >> >> Compile, and start ekiga with src/ekiga when being in ekiga directory. > > Ha, success, thank you very much! That works just fine now, at least > initiating a call with both audio and video. To sum up, could you do several tests and tell us whether ekiga works or not in sending and receiving calls, both with or without the modification I proposed? -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 15:58:50 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 17:58:50 +0200 Subject: [Ekiga-list] black video sent from ekiga on linux mint In-Reply-To: <521F9CEB.8050805@psu.edu> References: <521F9CEB.8050805@psu.edu> Message-ID: <522F41BA.5040009@pu-pm.univ-fcomte.fr> On 29/08/13 21:11, Alex Frase wrote: > Hi, > > (Apologies if this ends up posting twice; I sent it before subscribing > and it may have gotten lost in moderation) > > I'm trying to use Ekiga v4.0.1 on Linux Mint 15 (based on Ubuntu, based > on Debian) but can't seem to transmit video via h.323. > > I am able to connect to two different h.323 endpoints, and in both cases > I can see and hear the other side just fine, and they can hear me, but > they see only a black screen instead of the video from my side. > > I know that the camera works and Ekiga recognizes it, because I can see > my own video preview picture-in-picture. Skype also works just fine for > both audio and video in both directions. > > I can also successfully call the ekiga.net echo test > (sip:500 at ekiga.net), and I see my video echo (with a slight delay vs. my > local video picture-in-picture), so it seems to work okay via SIP. It's > just over h.323 that the other side does not receive my video. > > While connected via h.323, the call tooltip says "Codecs: PCMU - H264"; > when I call the echo test via SIP, the tooltip instead says "Codecs: > PCMA - H261". I've tried disabling the H264 video codec, but then the > remote side reports not even seeing a black screen -- instead they just > see their own camera on the whole screen, as if no video signal is being > received by them whatsoever. When the H264 codec is enabled, then they > see their video picture-in-picture on top of a black screen. So perhaps > the problem is the H264 encoder producing only black frames? Sorry to answer so late. You wrote that you see video on your computer. Do the others see their video too? I ask this because a bug has recently been fixed about not seeing video on local computer. Do the other use ekiga too or not? So when you call them, nobody sees video, but see black as image, is that right? It is not an error to have H261 on sip echo test, and H264 with the others: very likely the others do not support (checked off) H261, hence the next one on the list (H264) is chosen. If they check off H264 as well, then no common video codec is found: this is normal too. Finally, please send us/me a -d 4 log from your machine when you call and you see a black image. -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 16:06:31 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 18:06:31 +0200 Subject: [Ekiga-list] ekiga to Polycom Viewstation 1419 H.323 In-Reply-To: References: Message-ID: <522F4387.9090404@pu-pm.univ-fcomte.fr> On 30/08/13 13:33, Mikael Abrahamsson wrote: > On Fri, 30 Aug 2013, Mikael Abrahamsson wrote: > >> >> Hello. >> >> I'm trying to make Ekiga 4.0.1 on Linux Ubuntu 13.10 talk to an rather >> old Polycom Viewstation 1419 using H.323. I have attached a "-d 4" >> from when I try to do this. >> >> What happens is the call is connected, audio only, I can hear sound >> from the ekiga Linux machine on the polycom, nothing from the polycom >> to the ekiga client. I can see using tcpdump on linux machine that >> it's sending packets, none coming back from the polycom. >> >> When I use the Polycom to connect to another Polycom (audio+video), it >> claims in the info menu about ongoing call, to use: >> >> Tx/Rx Clock rate: 768k >> >> Video Protocol: H.263 >> Video format: CIF >> Audio Protocol: G.722 >> Comm Protocol: H.323 >> >> I provice pcap packet dump files from this if it would help, but it >> looked like the log file logged the entire capability exchange so that >> might not be needed. The two machines are connected to the same IPv4 >> subnet on a L2 switch. > > This email ended up in the moderator queue. Since I don't know if file > attachments are allowed, I have also put the file on my web server: > Hi, Bad luck, Mikael. I am sorry, but I do not see where the problem is, and I do not know much of H323... I suggest you to wait until we release ekiga > 4.2.0, which is based on a new opal which probably fixes your issue... -- Eugen From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 16:11:00 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 18:11:00 +0200 Subject: [Ekiga-list] Test Call from Linphone In-Reply-To: <20130823231439.3056@binki> References: <20130823231439.3056@binki> Message-ID: <522F4494.5000602@pu-pm.univ-fcomte.fr> On 25/08/13 16:33, henny.banzai at gmail.com wrote: > > > I am a registered member of this group. Why is my mail being sequestered? It is not... > Operational Questin: > > I have a registered SIP account with Linphone. > I'd like to test the SIP client. Can I call ekiga.net's call-back test, which I think > is at: sip:500 at ekiga.net ? I do not understand exactly your request, who does prevent you from calling? See also https://bugzilla.gnome.org/show_bug.cgi?id=624751. > I also have an ekiga.net SIP account, but would like to test interoperability of the implemented SIP protocol. -- Eugen From mtbc at ixod.org Tue Sep 10 16:45:11 2013 From: mtbc at ixod.org (Mark Carroll) Date: Tue, 10 Sep 2013 17:45:11 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522F3F7A.9030308@pu-pm.univ-fcomte.fr> (Eugen Dedu's message of "Tue, 10 Sep 2013 17:49:14 +0200") References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> Message-ID: <87ioy839t4.fsf@ixod.org> Eugen Dedu writes: > You are right: Ekiga does the right job, but notification programs are > sometimes bad (do not show long strings), or notification server is bad > (says it supports buttons, but it does not). So your request (to always > show the call window) is good, I do not know what to answer, and Damien > is against it anyway... Make it a gconf configurable thing? -- Mark From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 17:56:59 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 19:56:59 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <87ioy839t4.fsf@ixod.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> <87ioy839t4.fsf@ixod.org> Message-ID: <522F5D6B.2060708@pu-pm.univ-fcomte.fr> On 10/09/13 18:45, Mark Carroll wrote: > Eugen Dedu writes: > >> You are right: Ekiga does the right job, but notification programs are >> sometimes bad (do not show long strings), or notification server is bad >> (says it supports buttons, but it does not). So your request (to always >> show the call window) is good, I do not know what to answer, and Damien >> is against it anyway... > > Make it a gconf configurable thing? Relying on configuration settings to work is not an ideal solution either... Imagine someone starts ekiga and does not work. He has to search for this error on Internet to find out the gconf setting. This is not good "citizen"... -- Eugen From ford.davidj at gmail.com Tue Sep 10 19:28:04 2013 From: ford.davidj at gmail.com (David Ford) Date: Tue, 10 Sep 2013 20:28:04 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522F5D6B.2060708@pu-pm.univ-fcomte.fr> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> <87ioy839t4.fsf@ixod.org> <522F5D6B.2060708@pu-pm.univ-fcomte.fr> Message-ID: If there is no ideal solution - then perhaps a bad solution is the best thing - pop the window up may not be elegant but it is the one thing that does actually work. David On 10 September 2013 18:56, Eugen Dedu wrote: > On 10/09/13 18:45, Mark Carroll wrote: > >> Eugen Dedu > >> writes: >> >> You are right: Ekiga does the right job, but notification programs are >>> sometimes bad (do not show long strings), or notification server is bad >>> (says it supports buttons, but it does not). So your request (to always >>> show the call window) is good, I do not know what to answer, and Damien >>> is against it anyway... >>> >> >> Make it a gconf configurable thing? >> > > Relying on configuration settings to work is not an ideal solution > either... Imagine someone starts ekiga and does not work. He has to > search for this error on Internet to find out the gconf setting. This is > not good "citizen"... > > -- > Eugen > ______________________________**_________________ > ekiga-list mailing list > ekiga-list at gnome.org > https://mail.gnome.org/**mailman/listinfo/ekiga-list > -- Read My Blog http://www.ja2da.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at gathman.org Tue Sep 10 19:54:34 2013 From: stuart at gathman.org (Stuart Gathman) Date: Tue, 10 Sep 2013 15:54:34 -0400 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> <87ioy839t4.fsf@ixod.org> <522F5D6B.2060708@pu-pm.univ-fcomte.fr> Message-ID: <522F78FA.1030307@gathman.org> On 09/10/2013 03:28 PM, David Ford wrote: > If there is no ideal solution - then perhaps a bad solution is the > best thing - pop the window up may not be elegant but it is the one > thing that does actually work. What we have how is already a decent solution for broken notifiers. Just click on the "Video Preview" (icon of a web cam, or from the View menu), then click the answer button. Only two clicks to answer the phone. If notifiers do work, then only one click is required. From ford.davidj at gmail.com Tue Sep 10 20:03:42 2013 From: ford.davidj at gmail.com (David Ford) Date: Tue, 10 Sep 2013 21:03:42 +0100 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522F78FA.1030307@gathman.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> <87ioy839t4.fsf@ixod.org> <522F5D6B.2060708@pu-pm.univ-fcomte.fr> <522F78FA.1030307@gathman.org> Message-ID: I'll give it a try David On 10 September 2013 20:54, Stuart Gathman wrote: > On 09/10/2013 03:28 PM, David Ford wrote: > >> If there is no ideal solution - then perhaps a bad solution is the best >> thing - pop the window up may not be elegant but it is the one thing that >> does actually work. >> > What we have how is already a decent solution for broken notifiers. Just > click on the "Video Preview" (icon of a web cam, or from the View menu), > then click the answer button. Only two clicks to answer the phone. If > notifiers do work, then only one click is required. > > ______________________________**_________________ > ekiga-list mailing list > ekiga-list at gnome.org > https://mail.gnome.org/**mailman/listinfo/ekiga-list > -- Read My Blog http://www.ja2da.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eugen.Dedu at pu-pm.univ-fcomte.fr Tue Sep 10 20:20:34 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Tue, 10 Sep 2013 22:20:34 +0200 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522F78FA.1030307@gathman.org> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> <87ioy839t4.fsf@ixod.org> <522F5D6B.2060708@pu-pm.univ-fcomte.fr> <522F78FA.1030307@gathman.org> Message-ID: <522F7F12.4080201@pu-pm.univ-fcomte.fr> On 10/09/13 21:54, Stuart Gathman wrote: > On 09/10/2013 03:28 PM, David Ford wrote: >> If there is no ideal solution - then perhaps a bad solution is the >> best thing - pop the window up may not be elegant but it is the one >> thing that does actually work. > What we have how is already a decent solution for broken notifiers. Just > click on the "Video Preview" (icon of a web cam, or from the View menu), > then click the answer button. Only two clicks to answer the phone. If > notifiers do work, then only one click is required. I have added some text to http://wiki.ekiga.org/index.php/Manual#Answer_calls, waiting to find the ideal solution. -- Eugen From stuart at gathman.org Tue Sep 10 20:29:46 2013 From: stuart at gathman.org (Stuart Gathman) Date: Tue, 10 Sep 2013 16:29:46 -0400 Subject: [Ekiga-list] BT HomeHub blocking UDP 5060 In-Reply-To: <522F7F12.4080201@pu-pm.univ-fcomte.fr> References: <87d2oslbf2.fsf@ixod.org> <5229B619.1090100@pu-pm.univ-fcomte.fr> <871u529pf1.fsf@ixod.org> <5229BA77.5020307@pu-pm.univ-fcomte.fr> <87txhwegk2.fsf@ixod.org> <87mwnoegh1.fsf@ixod.org> <522CD5F3.8020106@gathman.org> <87eh8z58hi.fsf@ixod.org> <522E4A58.3040506@gathman.org> <522F3F7A.9030308@pu-pm.univ-fcomte.fr> <87ioy839t4.fsf@ixod.org> <522F5D6B.2060708@pu-pm.univ-fcomte.fr> <522F78FA.1030307@gathman.org> <522F7F12.4080201@pu-pm.univ-fcomte.fr> Message-ID: <522F813A.7020409@gathman.org> On 09/10/2013 04:20 PM, Eugen Dedu wrote: > On 10/09/13 21:54, Stuart Gathman wrote: >> On 09/10/2013 03:28 PM, David Ford wrote: >>> If there is no ideal solution - then perhaps a bad solution is the >>> best thing - pop the window up may not be elegant but it is the one >>> thing that does actually work. >> What we have how is already a decent solution for broken notifiers. Just >> click on the "Video Preview" (icon of a web cam, or from the View menu), >> then click the answer button. Only two clicks to answer the phone. If >> notifiers do work, then only one click is required. > > I have added some text to > http://wiki.ekiga.org/index.php/Manual#Answer_calls, waiting to find > the ideal solution. > It is amazing that such a seemingly simple service like notifiers would be so commonly broken. From hugonz at gmail.com Thu Sep 19 07:37:57 2013 From: hugonz at gmail.com (=?UTF-8?Q?Hugo_Gonz=C3=A1lez_Monteverde?=) Date: Thu, 19 Sep 2013 02:37:57 -0500 Subject: [Ekiga-list] Using Ekiga with ALSA loopback for connection to JACK - not working Message-ID: Hello all, I'm trying to use Ekiga as a VoIP program (much better than Skype) but this means I have to do some juggling to get it to work with JACK and Internet DJ Console. The process involves creating some loopback devices in ALSA and then connecting them to Jack. The whole procedure is at http://www.penguinproducer.com/Blog/2011/09/bridging-the-gap-using-jack-with-non-jack-apps/ The thing is, I can listen to audio from Ekiga, but the capture is not working. Ekiga lists a device as Loopback (PTLIB/ALSA). I can use the loopback in Audacity, but the capture channel I have to use is "jack_capture_1" (an ALSA name) This device is not available in Ekiga, and if I select the device called "Loopback (PLIB/ALSA) for capture, it does not work Any ideas? Can I manually, in some config file, change the name of the ALSA input device for Ekiga and use one that's not being detected? Thanks a lot, Hugo From aim at aptech.co.za Wed Sep 25 20:57:00 2013 From: aim at aptech.co.za (Tony Moody) Date: Wed, 25 Sep 2013 22:57:00 +0200 Subject: [Ekiga-list] could not register with ekiga.net (Solved) Message-ID: <52434E1C.30855.112F373@aim.aptech.co.za> OK,thanks. I solved it myself by sloshing around. sip:tonymo at ekiga.net Seems like there is no-one out there at Call back Test and the Echo Test I am at GMT -2:00 Maybe all are asleep? -------------- next part -------------- An HTML attachment was scrubbed... URL: From el_gallo_azul at yahoo.com Wed Sep 25 21:45:44 2013 From: el_gallo_azul at yahoo.com (el_gallo_azul) Date: Wed, 25 Sep 2013 14:45:44 -0700 (PDT) Subject: [Ekiga-list] could not register with ekiga.net (Solved) In-Reply-To: <52434E1C.30855.112F373@aim.aptech.co.za> References: <52434E1C.30855.112F373@aim.aptech.co.za> Message-ID: <1380145544.43461.YahooMailNeo@web161606.mail.bf1.yahoo.com> There is never anybody there. Both of those SIP URIs are automatic. ? Greg Flint PO Box 642 Parap NT 0804 Australia SIP: el_gallo_azul at ekiga.net Phone +61 (0)8 8945 1725 Mobile +61 (0)428 279 021 Australian Central Standard Time (ACST) = UTC/GMT+9.5 ________________________________ De: Tony Moody Para: ekiga-list at gnome.org Enviado: Jueves 26 de septiembre de 2013 6:27 Asunto: [Ekiga-list] could not register with ekiga.net (Solved) OK,thanks.? I solved it myself by sloshing around. sip:tonymo at ekiga.net Seems like there is no-one out there at? Call back Test and the Echo Test I am at GMT -2:00? Maybe all are asleep? _______________________________________________ ekiga-list mailing list ekiga-list at gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From atf3 at psu.edu Fri Sep 27 17:38:29 2013 From: atf3 at psu.edu (Alex Frase) Date: Fri, 27 Sep 2013 12:38:29 -0500 Subject: [Ekiga-list] black video sent from ekiga on linux mint In-Reply-To: <522F41BA.5040009@pu-pm.univ-fcomte.fr> References: <521F9CEB.8050805@psu.edu> <522F41BA.5040009@pu-pm.univ-fcomte.fr> Message-ID: <5245C295.8010602@psu.edu> On 09/10/2013 10:58 AM, Eugen Dedu wrote: > On 29/08/13 21:11, Alex Frase wrote: >> Hi, >> >> (Apologies if this ends up posting twice; I sent it before subscribing >> and it may have gotten lost in moderation) >> >> I'm trying to use Ekiga v4.0.1 on Linux Mint 15 (based on Ubuntu, based >> on Debian) but can't seem to transmit video via h.323. >> >> I am able to connect to two different h.323 endpoints, and in both cases >> I can see and hear the other side just fine, and they can hear me, but >> they see only a black screen instead of the video from my side. >> >> I know that the camera works and Ekiga recognizes it, because I can see >> my own video preview picture-in-picture. Skype also works just fine for >> both audio and video in both directions. >> >> I can also successfully call the ekiga.net echo test >> (sip:500 at ekiga.net), and I see my video echo (with a slight delay vs. my >> local video picture-in-picture), so it seems to work okay via SIP. It's >> just over h.323 that the other side does not receive my video. >> >> While connected via h.323, the call tooltip says "Codecs: PCMU - H264"; >> when I call the echo test via SIP, the tooltip instead says "Codecs: >> PCMA - H261". I've tried disabling the H264 video codec, but then the >> remote side reports not even seeing a black screen -- instead they just >> see their own camera on the whole screen, as if no video signal is being >> received by them whatsoever. When the H264 codec is enabled, then they >> see their video picture-in-picture on top of a black screen. So perhaps >> the problem is the H264 encoder producing only black frames? > > Sorry to answer so late. > > You wrote that you see video on your computer. Do the others see their > video too? I ask this because a bug has recently been fixed about not > seeing video on local computer. > > Do the other use ekiga too or not? > > So when you call them, nobody sees video, but see black as image, is > that right? > > It is not an error to have H261 on sip echo test, and H264 with the > others: very likely the others do not support (checked off) H261, hence > the next one on the list (H264) is chosen. If they check off H264 as > well, then no common video codec is found: this is normal too. > > Finally, please send us/me a -d 4 log from your machine when you call > and you see a black image. > A few clarifications first: - I am testing with two call recipients: one uses a physical Polycom device and the other is a video bridge service which allows 3-way video calls, not sure what software/equipment is behind that - on my end (Ekiga on Linux Mint) I see my own video, and I see remote video; I do not see any black image on my end - on their end (Polycom device or video bridge service) they see their own video (and, via the bridge, eachothers video), but they do not see my video; they see black where my video should be - when I disable H264 in the Ekiga preferences then I can call the Polycom using H261 video and it works correctly (they can see me), but the video bridge service does not support H261 so that workaround doesn't work there However, this turns out to be a NAT/firewall problem and not a codec problem. I didn't mention that I'm behind a NAT because I had ruled that out previously, because a) putting my machine in my router's DMZ did *not* fix it, and b) changing the video codec to H261 instead of H264 *did* fix it. But apparently my router's DMZ does not do what I thought it did, and the choice of video codec affects the ports used during the call, because when I specifically forward all ports (1024-65535) to my local machine (in lieu of DMZ) then it works. However this also breaks almost all other network communication, not only for other machines on my local network, but even for the same machine which has all ports forwarded to it. Not sure why that is. I had previously been forwarding only the ports listed in the Ekiga manual (1720, 3478-3479, 5000-5100, 30000-30010). That avoids interference with other applications and allows calls to be received by me, but the other end does not receive my H264 video. What still puzzles me is that Ekiga on Windows on the same local network (a different machine behind the same NAT router) does not have this problem. I assume Windows must be doing something smarter about automatically configuring port forwarding (UPnP?) but I don't know how to configure Linux to do the same, or if it even can. Any suggestions for negotiating the NAT for H264 video? Thanks, -alex From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Sep 27 21:09:04 2013 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 27 Sep 2013 23:09:04 +0200 Subject: [Ekiga-list] black video sent from ekiga on linux mint In-Reply-To: <5245C295.8010602@psu.edu> References: <521F9CEB.8050805@psu.edu> <522F41BA.5040009@pu-pm.univ-fcomte.fr> <5245C295.8010602@psu.edu> Message-ID: <5245F3F0.70708@pu-pm.univ-fcomte.fr> On 27/09/13 19:38, Alex Frase wrote: > > > On 09/10/2013 10:58 AM, Eugen Dedu wrote: >> On 29/08/13 21:11, Alex Frase wrote: >>> Hi, >>> >>> (Apologies if this ends up posting twice; I sent it before subscribing >>> and it may have gotten lost in moderation) >>> >>> I'm trying to use Ekiga v4.0.1 on Linux Mint 15 (based on Ubuntu, based >>> on Debian) but can't seem to transmit video via h.323. >>> >>> I am able to connect to two different h.323 endpoints, and in both cases >>> I can see and hear the other side just fine, and they can hear me, but >>> they see only a black screen instead of the video from my side. >>> >>> I know that the camera works and Ekiga recognizes it, because I can see >>> my own video preview picture-in-picture. Skype also works just fine for >>> both audio and video in both directions. >>> >>> I can also successfully call the ekiga.net echo test >>> (sip:500 at ekiga.net), and I see my video echo (with a slight delay vs. my >>> local video picture-in-picture), so it seems to work okay via SIP. It's >>> just over h.323 that the other side does not receive my video. >>> >>> While connected via h.323, the call tooltip says "Codecs: PCMU - H264"; >>> when I call the echo test via SIP, the tooltip instead says "Codecs: >>> PCMA - H261". I've tried disabling the H264 video codec, but then the >>> remote side reports not even seeing a black screen -- instead they just >>> see their own camera on the whole screen, as if no video signal is being >>> received by them whatsoever. When the H264 codec is enabled, then they >>> see their video picture-in-picture on top of a black screen. So perhaps >>> the problem is the H264 encoder producing only black frames? >> >> Sorry to answer so late. >> >> You wrote that you see video on your computer. Do the others see their >> video too? I ask this because a bug has recently been fixed about not >> seeing video on local computer. >> >> Do the other use ekiga too or not? >> >> So when you call them, nobody sees video, but see black as image, is >> that right? >> >> It is not an error to have H261 on sip echo test, and H264 with the >> others: very likely the others do not support (checked off) H261, hence >> the next one on the list (H264) is chosen. If they check off H264 as >> well, then no common video codec is found: this is normal too. >> >> Finally, please send us/me a -d 4 log from your machine when you call >> and you see a black image. >> > > A few clarifications first: > > - I am testing with two call recipients: one uses a physical Polycom > device and the other is a video bridge service which allows 3-way video > calls, not sure what software/equipment is behind that > > - on my end (Ekiga on Linux Mint) I see my own video, and I see remote > video; I do not see any black image on my end > > - on their end (Polycom device or video bridge service) they see their > own video (and, via the bridge, eachothers video), but they do not see > my video; they see black where my video should be > > - when I disable H264 in the Ekiga preferences then I can call the > Polycom using H261 video and it works correctly (they can see me), but > the video bridge service does not support H261 so that workaround > doesn't work there > > > However, this turns out to be a NAT/firewall problem and not a codec > problem. I didn't mention that I'm behind a NAT because I had ruled that > out previously, because a) putting my machine in my router's DMZ did > *not* fix it, and b) changing the video codec to H261 instead of H264 > *did* fix it. > > But apparently my router's DMZ does not do what I thought it did, and > the choice of video codec affects the ports used during the call, > because when I specifically forward all ports (1024-65535) to my local > machine (in lieu of DMZ) then it works. However this also breaks almost > all other network communication, not only for other machines on my local > network, but even for the same machine which has all ports forwarded to > it. Not sure why that is. > > I had previously been forwarding only the ports listed in the Ekiga > manual (1720, 3478-3479, 5000-5100, 30000-30010). That avoids > interference with other applications and allows calls to be received by > me, but the other end does not receive my H264 video. > > What still puzzles me is that Ekiga on Windows on the same local network > (a different machine behind the same NAT router) does not have this > problem. I assume Windows must be doing something smarter about > automatically configuring port forwarding (UPnP?) but I don't know how > to configure Linux to do the same, or if it even can. > > Any suggestions for negotiating the NAT for H264 video? Hi Alex, I am puzzled of what happens, I do not understand how all this can happen. But having the Windows version of Ekiga working is a useful information. Could you send us/me the -d 4 log of the Linux machine when the others see black, and the -d 4 log of the Windows machine when the others see you correctly? Perhaps an error is shown in the log. -- Eugen From cookedbread at hushmail.com Sun Sep 29 08:45:21 2013 From: cookedbread at hushmail.com (cookedbread at hushmail.com) Date: Sun, 29 Sep 2013 02:45:21 -0600 Subject: [Ekiga-list] Bug prevents VPN use Message-ID: <20130929084521.9EFBB6013F@smtp.hushmail.com> I want to use Ekiga without a central server by manually entering IP addresses to connect directly to others. This works fine on a LAN. But on VPN it doesn't work because of a bug, and this bug actually exists with the LAN but it's not noticed. I am using Ekiga version 3.3.2-0ubuntu3 on Ubuntu 12.04. What happens is that when userA sends a message out to userB, Ekiga attempts to sends communications out to ALL Internet interfaces that userA is connected to. I discovered this from the firewall log. As an example of what's happening in my situation, say that userA has a LAN address of 192.168.1.1 but is also on a VPN with a VPN address of 10.8.0.6. When Ekiga is used to send a direct message to userB who is on the LAN with an address of 192.168.1.2 (sip:userB at 192.168.1.2), Ekiga sends this signal out from userA on both 192.168.1.2 and 10.8.0.6. So in the ufw firewall log of userA you will see something like this: OUT=eth0 SRC=192.168.1.1 DST=192.168.1.2 OUT=eth0 SRC=10.8.0.6 DST=192.168.1.2 Notice that the second one says "eth0" even though it's using the tun() interface. That's part of the bug. When this is over the LAN it's not a problem. But when trying to do it over a VPN it is a problem. So now let's say userB is far away in another building, but connected to the same VPN as userA. userB has a VPN address of 10.8.0.10. This time userA sends a message to userB using the VPN address. userA will enter "sip:userB at 10.8.0.10" into Ekiga. userA can actually send messages to userB and userB will see them. However, userB cannot send any messages back to userA. The firewall logs show why this is. Here is what the firewall log for userA will look like when sending the message out: OUT=tun0 SRC=192.168.1.1 DST=10.8.0.10 OUT=tun0 SRC=10.8.0.6 DST=10.8.0.10 Notice that the first one is tun0 but using the LAN as source. That's part of the bug. But it's able to send messages over the VPN to userB at 10.8.0.10. But when userB tries to send messages back, it tries to send them to the LAN address of userA. Here is what the firewall log will look like for userB when trying to send communications to userA. userB has a LAN address of 172.16.0.1 with a VPN address of 10.8.0.10 and is communicating to userA with "sip:userA at 10.8.0.6". Here is what the firewall log of userB looks like: OUT=tun0 SRC=172.16.0.1 DST=192.168.1.1 OUT=tun0 SRC=10.8.0.10 DST=192.168.1.1 Ekiga for userB is trying to send signals to the LAN address of userA, which is why userB cannot send signals back to userA over VPN. But userB shouldn't be able to see the LAN address of userA. I'm guessing Ekiga is sending this. And again notice that it's saying both interfaces are tun() when the first one is eth(). The correct thing to do, which all other programs do correctly over VPN, is for Ekiga to only use the tun() interface for sending signals out. If you connect to more interfaces, such more VPNs, it will do this for each one. When this is fixed, it will be a nice, easy way of using VOIP to communicate with anyone through VPN. The most difficult part is setting up VPN, which is pretty straightforward if following step-by-step the server guide for Ubuntu 12.04. Ekiga using direct connect over LAN is easy, so fixing this bug will make Ekiga into a nice skype alternative for people who are capable of setting up a VPN using OpenVPN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsandras at seconix.com Sun Sep 29 15:53:58 2013 From: dsandras at seconix.com (Damien Sandras) Date: Sun, 29 Sep 2013 17:53:58 +0200 Subject: [Ekiga-list] Bug prevents VPN use In-Reply-To: <20130929084521.9EFBB6013F@smtp.hushmail.com> References: <20130929084521.9EFBB6013F@smtp.hushmail.com> Message-ID: <52484D16.4040005@seconix.com> What Ekiga is supposed to do, is to send one message per interface with the interface IP address as source. If your routing is well configured, then only one of the various SIP messages should reach the remote user. Please note that Ekiga 3.3.2 is an old development release which is not intended for public use... Le 29/09/13 10:45, cookedbread at hushmail.com a ?crit : > I want to use Ekiga without a central server by manually entering IP > addresses to connect directly to others. This works fine on a LAN. But > on VPN it doesn't work because of a bug, and this bug actually exists > with the LAN but it's not noticed. I am using Ekiga version > 3.3.2-0ubuntu3 on Ubuntu 12.04. > > What happens is that when userA sends a message out to userB, Ekiga > attempts to sends communications out to ALL Internet interfaces that > userA is connected to. I discovered this from the firewall log. As an > example of what's happening in my situation, say that userA has a LAN > address of 192.168.1.1 but is also on a VPN with a VPN address of > 10.8.0.6. When Ekiga is used to send a direct message to userB who is > on the LAN with an address of 192.168.1.2 (sip:userB at 192.168.1.2), > Ekiga sends this signal out from userA on both 192.168.1.2 and > 10.8.0.6. So in the ufw firewall log of userA you will see something > like this: > > OUT=eth0 SRC=192.168.1.1 DST=192.168.1.2 > OUT=eth0 SRC=10.8.0.6 DST=192.168.1.2 > > Notice that the second one says "eth0" even though it's using the > tun() interface. That's part of the bug. When this is over the LAN > it's not a problem. But when trying to do it over a VPN it is a > problem. So now let's say userB is far away in another building, but > connected to the same VPN as userA. userB has a VPN address of > 10.8.0.10. This time userA sends a message to userB using the VPN > address. userA will enter "sip:userB at 10.8.0.10" into Ekiga. userA can > actually send messages to userB and userB will see them. However, > userB cannot send any messages back to userA. The firewall logs show > why this is. Here is what the firewall log for userA will look like > when sending the message out: > > OUT=tun0 SRC=192.168.1.1 DST=10.8.0.10 > OUT=tun0 SRC=10.8.0.6 DST=10.8.0.10 > > Notice that the first one is tun0 but using the LAN as source. That's > part of the bug. But it's able to send messages over the VPN to userB > at 10.8.0.10. But when userB tries to send messages back, it tries to > send them to the LAN address of userA. Here is what the firewall log > will look like for userB when trying to send communications to userA. > userB has a LAN address of 172.16.0.1 with a VPN address of 10.8.0.10 > and is communicating to userA with "sip:userA at 10.8.0.6". Here is what > the firewall log of userB looks like: > > OUT=tun0 SRC=172.16.0.1 DST=192.168.1.1 > OUT=tun0 SRC=10.8.0.10 DST=192.168.1.1 > > Ekiga for userB is trying to send signals to the LAN address of userA, > which is why userB cannot send signals back to userA over VPN. But > userB shouldn't be able to see the LAN address of userA. I'm guessing > Ekiga is sending this. And again notice that it's saying both > interfaces are tun() when the first one is eth(). > > The correct thing to do, which all other programs do correctly over > VPN, is for Ekiga to only use the tun() interface for sending signals > out. If you connect to more interfaces, such more VPNs, it will do > this for each one. > > When this is fixed, it will be a nice, easy way of using VOIP to > communicate with anyone through VPN. The most difficult part is > setting up VPN, which is pretty straightforward if following > step-by-step the server guide for Ubuntu 12.04. Ekiga using direct > connect over LAN is easy, so fixing this bug will make Ekiga into a > nice skype alternative for people who are capable of setting up a VPN > using OpenVPN. > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > https://mail.gnome.org/mailman/listinfo/ekiga-list ------------------------------------------------------------------------ Damien SANDRAS *Ekiga Project* http://www.ekiga.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ekigaicon.png Type: image/png Size: 877 bytes Desc: not available URL: From cookedbread at hushmail.com Sun Sep 29 19:13:42 2013 From: cookedbread at hushmail.com (cookedbread at hushmail.com) Date: Sun, 29 Sep 2013 13:13:42 -0600 Subject: [Ekiga-list] Bug prevents VPN use In-Reply-To: <52484D16.4040005@seconix.com> References: <20130929084521.9EFBB6013F@smtp.hushmail.com> <52484D16.4040005@seconix.com> Message-ID: <20130929191342.D742C6013F@smtp.hushmail.com> Every other service I use on VPN only uses the interface for the VPN address that I enter. I don't know why Ekiga would send it out to every interface. Plus, part of the reason for using Ekiga over VPN is to have a private conversation, so sending signals out to every interface makes noise that I don't want. I could live with this for the time being, so just having a fix for the response of Ekiga for userB would make me satisfied for now. The routing is configured correctly, as you can see from my firewall log examples. It's Ekiga for userB that's trying to communicate with the LAN address instead of the VPN address. Does the latest Ekiga do this correctly through VPN? One of the main reasons I'm using Ubuntu 12.04 is that it's long term support until 2017, so if the latest version of Ekiga cannot get into the Ubuntu repository, that could be a problem for me. If installing the latest version from source is a solution, I could live with it. On 09/29/2013 at 10:04 AM, "Damien Sandras" wrote: What Ekiga is supposed to do, is to send one message per interface with the interface IP address as source. If your routing is well configured, then only one of the various SIP messages should reach the remote user. Please note that Ekiga 3.3.2 is an old development release which is not intended for public use... Le 29/09/13 10:45, cookedbread at hushmail.com a ?crit : I want to use Ekiga without a central server by manually entering IP addresses to connect directly to others. This works fine on a LAN. But on VPN it doesn't work because of a bug, and this bug actually exists with the LAN but it's not noticed. I am using Ekiga version 3.3.2-0ubuntu3 on Ubuntu 12.04. What happens is that when userA sends a message out to userB, Ekiga attempts to sends communications out to ALL Internet interfaces that userA is connected to. I discovered this from the firewall log. As an example of what's happening in my situation, say that userA has a LAN address of 192.168.1.1 but is also on a VPN with a VPN address of 10.8.0.6. When Ekiga is used to send a direct message to userB who is on the LAN with an address of 192.168.1.2 (sip:userB at 192.168.1.2), Ekiga sends this signal out from userA on both 192.168.1.2 and 10.8.0.6. So in the ufw firewall log of userA you will see something like this: OUT=eth0 SRC=192.168.1.1 DST=192.168.1.2 OUT=eth0 SRC=10.8.0.6 DST=192.168.1.2 Notice that the second one says "eth0" even though it's using the tun() interface. That's part of the bug. When this is over the LAN it's not a problem. But when trying to do it over a VPN it is a problem. So now let's say userB is far away in another building, but connected to the same VPN as userA. userB has a VPN address of 10.8.0.10. This time userA sends a message to userB using the VPN address. userA will enter "sip:userB at 10.8.0.10" into Ekiga. userA can actually send messages to userB and userB will see them. However, userB cannot send any messages back to userA. The firewall logs show why this is. Here is what the firewall log for userA will look like when sending the message out: OUT=tun0 SRC=192.168.1.1 DST=10.8.0.10 OUT=tun0 SRC=10.8.0.6 DST=10.8.0.10 Notice that the first one is tun0 but using the LAN as source. That's part of the bug. But it's able to send messages over the VPN to userB at 10.8.0.10. But when userB tries to send messages back, it tries to send them to the LAN address of userA. Here is what the firewall log will look like for userB when trying to send communications to userA. userB has a LAN address of 172.16.0.1 with a VPN address of 10.8.0.10 and is communicating to userA with "sip:userA at 10.8.0.6". Here is what the firewall log of userB looks like: OUT=tun0 SRC=172.16.0.1 DST=192.168.1.1 OUT=tun0 SRC=10.8.0.10 DST=192.168.1.1 Ekiga for userB is trying to send signals to the LAN address of userA, which is why userB cannot send signals back to userA over VPN. But userB shouldn't be able to see the LAN address of userA. I'm guessing Ekiga is sending this. And again notice that it's saying both interfaces are tun() when the first one is eth(). The correct thing to do, which all other programs do correctly over VPN, is for Ekiga to only use the tun() interface for sending signals out. If you connect to more interfaces, such more VPNs, it will do this for each one. When this is fixed, it will be a nice, easy way of using VOIP to communicate with anyone through VPN. The most difficult part is setting up VPN, which is pretty straightforward if following step-by-step the server guide for Ubuntu 12.04. Ekiga using direct connect over LAN is easy, so fixing this bug will make Ekiga into a nice skype alternative for people who are capable of setting up a VPN using OpenVPN. _______________________________________________ ekiga-list mailing list ekiga-list at gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list ------------------------- Damien SANDRAS Ekiga Project http://www.ekiga.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrisb at avpresentations.com Mon Sep 30 14:44:51 2013 From: morrisb at avpresentations.com (Morris Beverly) Date: Mon, 30 Sep 2013 10:44:51 -0400 Subject: [Ekiga-list] ekiga-list Digest, Vol 86, Issue 16 In-Reply-To: References: Message-ID: <52498E63.8090407@avpresentations.com> On 09/28/2013 08:00 AM, ekiga-list-request at gnome.org wrote: > On 27/09/13 19:38, Alex Frase wrote: >> >> On 09/10/2013 10:58 AM, Eugen Dedu wrote: >>> On 29/08/13 21:11, Alex Frase wrote: >>>> Hi, >>>> >>>> (Apologies if this ends up posting twice; I sent it before subscribing >>>> and it may have gotten lost in moderation) >>>> >>>> I'm trying to use Ekiga v4.0.1 on Linux Mint 15 (based on Ubuntu, based >>>> on Debian) but can't seem to transmit video via h.323. >>>> >>>> I am able to connect to two different h.323 endpoints, and in both cases >>>> I can see and hear the other side just fine, and they can hear me, but >>>> they see only a black screen instead of the video from my side. >>>> >>>> I know that the camera works and Ekiga recognizes it, because I can see >>>> my own video preview picture-in-picture. Skype also works just fine for >>>> both audio and video in both directions. >>>> >>>> I can also successfully call the ekiga.net echo test >>>> (sip:500 at ekiga.net), and I see my video echo (with a slight delay vs. my >>>> local video picture-in-picture), so it seems to work okay via SIP. It's >>>> just over h.323 that the other side does not receive my video. >>>> >>>> While connected via h.323, the call tooltip says "Codecs: PCMU - H264"; >>>> when I call the echo test via SIP, the tooltip instead says "Codecs: >>>> PCMA - H261". I've tried disabling the H264 video codec, but then the >>>> remote side reports not even seeing a black screen -- instead they just >>>> see their own camera on the whole screen, as if no video signal is being >>>> received by them whatsoever. When the H264 codec is enabled, then they >>>> see their video picture-in-picture on top of a black screen. So perhaps >>>> the problem is the H264 encoder producing only black frames? >>> Sorry to answer so late. >>> >>> You wrote that you see video on your computer. Do the others see their >>> video too? I ask this because a bug has recently been fixed about not >>> seeing video on local computer. >>> >>> Do the other use ekiga too or not? >>> >>> So when you call them, nobody sees video, but see black as image, is >>> that right? >>> >>> It is not an error to have H261 on sip echo test, and H264 with the >>> others: very likely the others do not support (checked off) H261, hence >>> the next one on the list (H264) is chosen. If they check off H264 as >>> well, then no common video codec is found: this is normal too. >>> >>> Finally, please send us/me a -d 4 log from your machine when you call >>> and you see a black image. >>> >> A few clarifications first: >> >> - I am testing with two call recipients: one uses a physical Polycom >> device and the other is a video bridge service which allows 3-way video >> calls, not sure what software/equipment is behind that >> >> - on my end (Ekiga on Linux Mint) I see my own video, and I see remote >> video; I do not see any black image on my end >> >> - on their end (Polycom device or video bridge service) they see their >> own video (and, via the bridge, eachothers video), but they do not see >> my video; they see black where my video should be >> >> - when I disable H264 in the Ekiga preferences then I can call the >> Polycom using H261 video and it works correctly (they can see me), but >> the video bridge service does not support H261 so that workaround >> doesn't work there >> >> >> However, this turns out to be a NAT/firewall problem and not a codec >> problem. I didn't mention that I'm behind a NAT because I had ruled that >> out previously, because a) putting my machine in my router's DMZ did >> *not* fix it, and b) changing the video codec to H261 instead of H264 >> *did* fix it. >> >> But apparently my router's DMZ does not do what I thought it did, and >> the choice of video codec affects the ports used during the call, >> because when I specifically forward all ports (1024-65535) to my local >> machine (in lieu of DMZ) then it works. However this also breaks almost >> all other network communication, not only for other machines on my local >> network, but even for the same machine which has all ports forwarded to >> it. Not sure why that is. >> >> I had previously been forwarding only the ports listed in the Ekiga >> manual (1720, 3478-3479, 5000-5100, 30000-30010). That avoids >> interference with other applications and allows calls to be received by >> me, but the other end does not receive my H264 video. >> >> What still puzzles me is that Ekiga on Windows on the same local network >> (a different machine behind the same NAT router) does not have this >> problem. I assume Windows must be doing something smarter about >> automatically configuring port forwarding (UPnP?) but I don't know how >> to configure Linux to do the same, or if it even can. >> >> Any suggestions for negotiating the NAT for H264 video? > Hi Alex, > > I am puzzled of what happens, I do not understand how all this can > happen. But having the Windows version of Ekiga working is a useful > information. Could you send us/me the -d 4 log of the Linux machine > when the others see black, and the -d 4 log of the Windows machine when > the others see you correctly? Perhaps an error is shown in the log. > Hi, I work with polycom gear fairly regularly and have had similar issues. If you can connect to the unit with all your local ports forwarded, but not when only the "correct" ports are forwarded, it is probably a polycom thing. In the admin settings on the polycom, there is an option to limit the ports used. As I remember, you can set the port range, but I believe that the defaults under that option will work. Unless you do this, the polycom will use a completely random set of ports and you will see a basic connection start (which happens on udp 1725 I believe) but the connection will never complete since it's sending to a random port that you probably do not have forwarded on your router. This can only be fixed on the polycom end unless you forward all your ports as you mentioned above. For doing calls from my office, I have a a static ip that i dedicate to video conferencing and just hook my polycom directly to it. Certainly not very secure, but I physically disconnect the cable when I'm done. On the h264 side, I have never ever been able to use it for a video codec successfully with a polycom unit. This is a shame since it would be really nice to have ekiga as a backup for my system. I'm guessing that there is some silly thing in the headers that polycom ignores or refuses to work with. My experience with them is that they are extraordinarily non-open (and in many cases, just plain unhelpful) in their technical specs. If anyone has been able to get this to work, please let me know since being able to use ekiga to diagnose problems with connections to polycom would be a big help in my work. As far as the bridge goes, it may make a difference on who initiates the call. Many companies that do allow outside video conference connections only do so if they initiate the call. I have one client that swears their firewall does not block me but after working correctly for over a year, it stopped and would only allow calls to me if the bridge initiated the call (this is with all polycom gear, not even attempting to use ekiga). It's very possible that some security rule either in the bridge's firewall or the application itself that won't accept your call. In general, and please don't take this the wrong way as I am a long time supporter of all Damien's (and other's) work on this great project, I've found that ekiga seems to be moving away from it's formerly strong support of h323 in favor of sip. This of course makes perfect sense since 323 is entirely unsuited for work across the internet and sip works much more reliably. I know that the project is meant to be an internet soft phone and not really a complete video conferencing system. However it used to be really nice to be able to connect up to other 323 hardware platforms like polycom, tandberg and the rest. I also realize that the difficulties are usually because vendors have implemented things in a way to make interoperability difficult so they can keep market share through lock in. Alas, I know that I'm in the minority and with limited developer hours things have to be prioritized to help the greatest number of users. I guess I'm just longing for the old days, back before I became a grumpy old man ;) In any case, if someone needs to test with polycom gear, let me know and I can set up a unit on a public ip that you can connect to temporarily. thanks, morris -- Morris Beverly http://www.avpresentations.com From Jim.Diamond at acadiau.ca Mon Sep 30 15:11:24 2013 From: Jim.Diamond at acadiau.ca (Jim Diamond) Date: Mon, 30 Sep 2013 12:11:24 -0300 Subject: [Ekiga-list] ekiga-list Digest, Vol 86, Issue 16 In-Reply-To: <52498E63.8090407@avpresentations.com> References: <52498E63.8090407@avpresentations.com> Message-ID: <20130930151124.GH21024@jdiamond-nb2.acadiau.ca> On Mon, Sep 30, 2013 at 10:44 (-0400), Morris Beverly wrote: > In general, and please don't take this the wrong way as I am a long > time supporter of all Damien's (and other's) work on this great > project, I've found that ekiga seems to be moving away from it's > formerly strong support of h323 in favor of sip. This of course > makes perfect sense since 323 is entirely unsuited for work across > the internet and sip works much more reliably. I know that the > project is meant to be an internet soft phone and not really a > complete video conferencing system. However it used to be really > nice to be able to connect up to other 323 hardware platforms like > polycom, tandberg and the rest. I also realize that the > difficulties are usually because vendors have implemented things in a > way to make interoperability difficult so they can keep market share > through lock in. Alas, I know that I'm in the minority and with > limited developer hours things have to be prioritized to help the > greatest number of users. I guess I'm just longing for the old days, > back before I became a grumpy old man ;) Don't be too harsh on yourself. Sometimes I need to connect with Polycom equipment, and so reduction in h323 functionality is troubling for me as well. Also, even between two instances of ekiga, sometimes I can get h323 to work when sip just won't go. So FWIW, I'd like to see h323 to stay. But maybe I'm just an old grumpy guy too. (Ow!) Jim