Re: [Ekiga-list] Echo tests on ekiga
On Mon, Feb 23, 2015 at 09:52:30PM +0100, Eugen Dedu wrote: > > Well, ekiga migrated to testing on 4th november... > > Anyway, I noticed that sometimes all the codecs get selected when installing > or upgrading. I will analyse this, it is on my todo list. > > (It is an ekiga problem, not a debian one.) Ok. I guess Kilian is listening to this list, so I wasn't planning a debian bug report. I looked back to that original dumpcap file and indeed the problem INVITE was 1568 long while the MTU was (of course) 1500. I have now noticed the ICMP fragment reassembly error packets *were* passed back through the firewall to ekiga (well the right port). Should ekiga not have repackaged the INVITE? Or at least reported the error? Maybe this is in the wiki: I ought to check. ael ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Echo tests on ekiga
On 23/02/15 19:44, ael wrote: On Mon, Feb 23, 2015 at 06:38:47PM +0100, Eugen Dedu wrote: On 23/02/15 18:21, ael wrote: Yes. I found that all 7 of the video codecs were enabled! I hadn't thought of looking there because I was just testing audio. Seems a bit wrong headed that my distribution (debian for now) ship by default a configuration that can't connect to the standard echo test. Have you just upgraded ekiga? Don't think so: debian testing kept up to date. Looking at /var/log/dpkg*, I see the latest update was "2015-01-11 12:29:42 status installed ekiga:amd64 4.0.1-5" Well, ekiga migrated to testing on 4th november... Anyway, I noticed that sometimes all the codecs get selected when installing or upgrading. I will analyse this, it is on my todo list. (It is an ekiga problem, not a debian one.) -- Eugen ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Echo tests on ekiga
Le lundi 23 février 2015 à 14:35 +, ael a écrit : > I am trying to understand properly how to navigate firewalls using > ekiga. I have read the wiki and even contributed to it in the past. > > Just now I using wireshark to compare a failed echo test (ekiga.net's own > on 500) and the ideal sip successful echo test when sent via ekiga net. > > ekiga is set to use udp_port_range (on this machine) of 5081:5089 and > the firewall forwards those ports & 5080 to this machine. The sip > listen_port is 5080. ATM I am testing audio only, so although > tcp_port_range is set to 3:30010, the firewall is *not* forwarding > those ports. > > I attach the two simple (wide) text flow recordings from wireshark > of the successful and failed calls. Wireshark does not decode the > udp audio packets in the successful call, so that is not shown. > > In the failed call to 5...@ekiga.net, the first INVITE goes out, > and ekiga.net replies with the 407 Authentication request. > ekiga responds with the ACK and the modified INVITE, but ekiga.net > never responds (or is blocked by the firewall) thereafter. > > Is this enough for an expert to explain what is happening? > > I can of course post a -d4 log etc. if more information is needed, but I > wanted to keep this initial post simple and short. > > Thanks in advance for any enlightenment. My suspicion would be that too many audio codecs are enabled and you reach the MTU once the authentication information has been added : the packet never reaches ekiga.net. Can you try removing some codecs ? -- Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Echo tests on ekiga
I am trying to understand properly how to navigate firewalls using ekiga. I have read the wiki and even contributed to it in the past. Just now I using wireshark to compare a failed echo test (ekiga.net's own on 500) and the ideal sip successful echo test when sent via ekiga net. ekiga is set to use udp_port_range (on this machine) of 5081:5089 and the firewall forwards those ports & 5080 to this machine. The sip listen_port is 5080. ATM I am testing audio only, so although tcp_port_range is set to 3:30010, the firewall is *not* forwarding those ports. I attach the two simple (wide) text flow recordings from wireshark of the successful and failed calls. Wireshark does not decode the udp audio packets in the successful call, so that is not shown. In the failed call to 5...@ekiga.net, the first INVITE goes out, and ekiga.net replies with the 407 Authentication request. ekiga responds with the ACK and the modified INVITE, but ekiga.net never responds (or is blocked by the firewall) thereafter. Is this enough for an expert to explain what is happening? I can of course post a -d4 log etc. if more information is needed, but I wanted to keep this initial post simple and short. Thanks in advance for any enlightenment. ael |Time | shelf.conquest| | | | ekiga.net | |19.710059000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |19.733743000| 407 Proxy Authentica |SIP Status | |(5080) <-- (5060) | |19.734424000| ACK | |SIP Request | |(5080) --> (5060) | |19.73862| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |20.26005| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |21.260591000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |23.260083000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |27.260152000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |31.260685000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |35.261727000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |39.262237000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |Time | shelf.conquest| | | | ekiga.net | |6.994588000| INVITE SDP (Speex g7 |SIP From: "ael" (5060) | |7.017845000| 100 Giving a try |SIP Status | |(5080) <-- (5060) | |8.363391000| 200 OK SDP (g711U g7 |SIP Status | |(5080) <-- (5060) | |8.366462000| ACK | |SIP Request | |(5080) --> (5060) | |8.475639000| INVITE SDP (g711U te |SIP From: "ael" (5060) | |8.499757000| 100 Giving a try |SIP Status | |(5080) <-- (5060) | |8.620696000| 200 OK SDP (g711U te |SIP Status | |(5080) <-- (5060) | |8.622031000| ACK | |SIP Request | |(5080) --> (5060) | |13.692827000| BYE | |SIP Request | |(5080) --> (5060) | |13.837151000| 200 OK| |SIP Status | |(5080) <-- (5060) | ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
