Re: [Ekiga-list] calling a contact

[Jānis Rukšāns <thedogfarted gmail com>]

On Fri, Jul 16, 2010 at 12:36 AM, Eugen Dedu
<Eugen Dedu 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.

-- 
Ian