[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