[Ekiga-list] Coexistence of ekiga with an ATA

ael law_ence.dev at ntlworld.com
Fri Jan 5 13:53:08 UTC 2007


Damien Sandras wrote:
> Le jeudi 04 janvier 2007 à 23:20 +0000, ael a écrit :
> 
> [...]
> 
> 
> 
>>The "magic" manipulation of the Network setting was logged as
>>
>>2007/01/04 22:57:41.372   0:48.346        GMStunClient:0853daa0 OPAL
>>STUN server "stun.ekiga.net" replies Cone NAT, external IP 86.3.137.146
>>
>>A failed call without that "magic" has debug entries like:
>>
>>------------------------------------------------------------------------
>>2007/01/04 23:12:12.923   1:13.466        GMURLHandler:084b7e38 PCSS
>>Outgoing call routed to sip:500 at ekiga.net for Call[1]-EP<pc>[Default]
>>2007/01/04 23:12:12.925   1:13.474        GMURLHandler:084b7e38 SIP
>>SetUpConnection: <sip:500 at ekiga.net>
>>2007/01/04 23:12:22.969   1:23.512        GMURLHandler:084b7e38 OpalUDP
>>Started connect to 86.64.162.35:5060
>>2007/01/04 23:12:22.994   1:23.537        GMURLHandler:084b7e38 RTP
>>STUN could not create RTP/RTCP socket pair; trying to create RTP socket
>>anyway.
>>2007/01/04 23:12:22.996   1:23.539        GMURLHandler:084b7e38 RTP
>>STUN could not create RTP socket either.
>>2007/01/04 23:12:22.997   1:23.541        GMURLHandler:084b7e38 RTP
>>STUN could not create RTP/RTCP socket pair; trying to create RTP socket
>>anyway.
>>
> 
> 
> When doing a call, the STUN protocol is used to determine which ports
> will be used by your router for outgoing traffic, that way, the remote
> application knows where to send back the data so that it is relayed to
> your computer.
> 
> The above message just tells that STUN can not determine those ports.
> I have no idea why triggering a STUN detection allows determining them
> again. It doesn't make sense :(
> 
> Check if there is not something to configure at the router level.

I played for a fair time with the router settings, but I think the
problem is that I don't know what the HandyTone ATA is actually doing.
It is at the front end just after the cable modem so I think that is
where the foible is hiding. Rarely I saw the STUN reporting symmetric
NAT and I gather that the STUN protocol can be nondeterministic in such
situations. My tests were with only 1 active machine on the network, so
the STUN server might be seeing the ATA as one host and the ekiga
machine as another.

I will run etherreal during a session to see whether this helps: I might
forward a log here in case someone can help with interpretation. But of
course, I will only see the traffic behind the router. Unless I
rearrange the network for testing purposes which I don't have time to do
 for now.

All that said, it seems to be quite reliable to use the "magic": start
ekiga, change the network protocol from STUN and back to STUN and then
everything works.

I haven't tried port forwarding because I would like to be able to use
ekiga on any local machine. I suspect that would work if I put the ATA
behind, rather than in front of, the main router and then forward
specific ports to the ATA. But if an incoming call arrived while I was
using all my bandwidth for a major download, I suspect that the voip
call quality would suffer (and I do get a few problems even now).

A E Lawrence



More information about the ekiga-list mailing list