[Ekiga-list] Coexistence of ekiga with an ATA

[ael]

Damien Sandras wrote:
> Le mercredi 03 janvier 2007 à 22:57 +0000, ael a écrit :
> 
>>Background:
>>----------
>>
>>I use an ATA (Analogue Telephone Adapter, a sip based unit) connected to
>>a standard handset, to my landline and to a cordless unit. This works
>>even when my computers are not booted and allows me to make and accept
>>voip calls away from my desktop. Also I prefer a conventional handset
>>sometimes.
>>
>>The ATA is upstream of my computers so that it can give its voip ports
>>priority when a call (via the ATA) is in progress.
>>
>>[Cable modem] ==== [ATA intercepting ports 5004,5060] ==== [Router] ===
>>[local network]
>>
>>I also use ekiga for several reasons including the ability to register
>>simultaneously with several sip servers, and I like to use a headset and
>>have my hands free on most occasions. If I used a webcam, that would be
>>another reason.
>>
>>On my various computers, I set ekiga to use ports other than those used
>>by the ATA. On the machine that I am using to send this email, ekiga is
>>set to use rtc ports 5010:5059 and udp ports 5062:5100, for example.
>>
>>Problem
>>--------
>>All of this works fine, except for one minor problem which is the point
>>of this email.
>>
>>Ekiga --> Preferences-->Protocols --> Network settings is set to STUN.
>>
>>When I start ekiga, it registers with the sip servers properly, but then
>>calls fail, or partially fail, often with "Abnormal call termination".
>>However, if I navigate through the preferences as above and set and
>>reset the STUN, there is a brief message on the screen about the STUN
>>being partially blocked (presumably it is detecting the ports used by
>>the ATA). Thereafter, ekiga works properly until it is restarted.

[..snip..]

> However, if STUN detects "Partially blocked NAT", it is because the
> forwarded ports on the router do not correspond to the ports used by
> Ekiga.

I have now solved the problem. It was nothing to do with the ATA. Rather
it was the rule that I was using in the router (a DLInk DI-604, although
I think many routers will behave similarly).

By default the router seems to behave as a symmetric CONE. For those who
 have not read the relevant RFCs this essentially means that the router
will bounce all incoming packets except those matching precisely (ie,
both port and address) a previous outgoing packet.

The STUN protocol allows one to "punch a hole" in the NAT (router) so
that certain incoming packets can be accepted without a precisely
matching outgoing packet. In particular the "other end" of a voip call.
But this will not work in general for a symmetric CONE.

One option is to use a rule for port forwarding (to a specific machine),
but that means that only that one machine on a local network can use ekiga.

But most NAT/routers support "application rules" which open a restricted
hole dynamically when triggered by particular ports. But the
documentation that I have seen is very rudimentary, and does not really
explain just what happens.

After playing with ethereal to watch the traffic, I realized that if I
used a rule that triggered on the STUN ports ( 3478 & 3479 ) and then
opened the sip and rtp ports, the STUN protocol would then find a full
CONE NAT. That is what I did and everything now works.

My rule has
Trigger ports: 3478-3479
Public ports:  3478-3479, 5000-5100
Protocol:      UDP

I am not sure that I need to open all those public ports: I may
experiment further, but I don't think it will do any harm.

I hope this is useful to others. I haven't found any other references to
triggering on STUN ports while I was googling for help on solving the
problem.

A E Lawrence