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:[EMAIL PROTECTED] for Call[1]-EP<pc>[Default] >>2007/01/04 23:12:12.925 1:13.474 GMURLHandler:084b7e38 SIP >>SetUpConnection: <sip:[EMAIL PROTECTED]> >>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 _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
