On 16/07/10 12:18, Jānis Rukšāns wrote:
On Fri, Jul 16, 2010 at 12:36 AM, Eugen Dedu
<eugen.d...@pu-pm.univ-fcomte.fr> wrote:
On 12/07/10 23:02, Leo Butler wrote:
On Mon, 12 Jul 2010, Leo Butler wrote:
< As I originally said, the problem arises when trying to connect with
< another ekiga client. Only one of the two clients is able to connect
< to the other, and only the initiator can hang-up (the other party can
< hang-up, but ekiga freezes and must be killed).
<
< I will run my ekiga client in debug mode and post the output.
Ok, here is debugging info for a session where ekiga reported me and
another client online but I was unable to phone the other client (i.e.
after clicking on 'call contact', and ekiga reporting it was making
the call, it would report after a long pause that the other end had
dropped the call. I know that the other end's client did not report
any incoming calls).
http://ekiga-debug.pastebin.com/GQcyaDwN
I see in this output that you send the INVITE to the other party, and you
receive Giving a Try, afterwards you do not receive anything for 30 seconds,
and you finally receive Request Timeout.
In a normal communication, you send INVITE, and you receive a
Proxy-Authorization packet, you resend the INVITE with authorization, and
you receive Giving a Try and OK afterwards, so the communication is done.
I really do not understand what happens in your case. Maybe you do not use
STUN (see Preferences, Network Detection). However, I see that STUN is
used...
**** Does anyone with SIP knowledge have an idea of what hapens? ***
Unless I'm missing something very obvious, everything is working as it
should for the caller. Most likely the culprit is the callee's
NAT/firewall, or the callee is registering with a bad IP or port (less
likely).
Leo, is it only the particular contact you are not able to call, or
everyone? Also, is it only you who can't call the particular contact?
I guess what's happening is:
The callee sends REGISTER to ekiga.net. There's a NAT/firewall
in-between which makes a binding and keeps it open for some time. If
the NAT/firewall binding expires sooner than REGISTER, there's a time
window when the callee is registered but not reachable. If the caller
now sends INVITE, ekiga.net sees the callee is registered and online,
responds with 100 Giving a Try and forwards the INVITE to the contact
from the callee's REGISTER. The NAT/firewall binding has expired and
the INVITE is blocked at the callee. This results in transaction
timeout, and ekiga.net responds with 408 Request Timeout.
The calling works with the roles reversed because when the other end
is calling, NAT gets opened again and the call setup succeeds. During
the call RTP/RTCP bindings are kept open because there's constant
packet flow. On the contrary, binding for SIP signalling expires,
resulting in only one end being able to drop the call.
You are certainly right! The NAT binding is not correctly made by
callee, since he uses version 3.2.6 (3.2.6 advertises a wrong port, so
ekiga.net's forwarded request never reaches the callee).
Now, so I understand better: You say that Giving a try is the packet
sent by ekiga.net to caller right before forwarding the INVITE request
to the callee, is that right? And that ekiga.net sends OK right after
reception of callee response?
Also, why the Proxy-Auth packet is not received by caller (I suppose it
is sent by ekiga.net solely)?
--
Eugen
_______________________________________________
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
