Re: [Ekiga-list] calling a contact

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 16/07/10 12:18, Jānis Rukšāns wrote:
> 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.

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