I’m not familiar with eyebeam logs and there is a lot of log here, but I suspect it may have been configured to use a STUN server that doesn’t exist.
The “Unable to set DSCP/TOS value” error is an issue between eyebeam and Windows. It relates to options that might help transit times through a suitably configured router, but I doubt that your remote router is suitably configured. I would have classed it as a warning, as they are only performance options and can be ignored.
There are mentions of TLS in the log, but your end is using UDP. Either something is converting in the middle, or the is an artefact of the logging process.
Thank you so match “David” for your support, especially for your professional logic debugging this issue. Really thanks.
The problem was caused from Server domain Name. In fact, the remote end is configured to register/talk to server by its Domain Name (not its real IP). And this somehow blocks the transmission for a while (delay 3-4 s).
I don’t know if this is logical because as I know there is no difference between “Server Domain Name” and “Server Real IP”. But in brief, changing domain name by Server Ip in Sip account in remote end Soft-phone (host field), solve the problem and delay is gone.
Even soft-phone log show this :
[16-06-22]00:20:34.003 | Info (more) DNS | “DNS [query:ServerDomainName]” | sua::CDNS::StartTopologyLookup
[16-06-22]00:20:34.003 | Info (more) DNS | “DNS [query:ServerDomainName]” | sua::CDNS::StartTopologyLookup
[16-06-22]00:20:34.003 | Info (more) DNS | “DNS [query:ServerDomainName]” | sua::CDNS::StartTopologyLookup
[16-06-22]00:20:34.053 | Info (more) CCM | “DSCP marking is set for SIP or DNS signaling socket, where socket=2876, where transport type=1, where resip file is W:\HEAD\SUA\Library\sipfoundry\main\contrib\ares\ares_process.c, where resip line # is 706, where DSCP value=40” | sua::CCMAfterSocketCreationFuncPtr
[16-06-22]00:20:34.086 | Info (debug) RESIP:DNS | “no TTL to cache” |
[16-06-22]00:20:34.090 | Info (more) DNS | “DNS-Lookup performed: ‘_sip._udp.’ ‘ServerDomainName’ [default-port:5060][fallback to A/QA:T] - Results:” | sua::CDNS::InternalShutdown
[16-06-22]00:20:34.090 | Info (more) DNS | " 0 - [ip:ServerIP:5060][ttl:4294967295][P:0][W:0][query-name:ServerDomainName (A-Lookup)]" | sua::CDNS::InternalShutdown
[16-06-22]00:20:34.090 | Info (debug) RESIP:DNS | “no TTL to cache” | [16-06-22]00:20:34.090 | Info (more) DNS | “DNS [query:ServerDomainName] - No results” | sua::CDNS::InternalShutdown
this at call moment.
I don’t know if other potential things that you mentioned can affect, but I don’t think so because TLS and Tos things might have influence during the call, But here we have delay in the beginning of the call , after that things go normal as Normal Sip call.
Brief this modification solve the problem in case someone else confront this.
But I think this matter of Domain Name is related to Internet Service Provider as “astbox” said:
Because, one time I experienced “Timout” issue when calling Web site hosted in this server by this DomainName from North Africa site. Then I mentioned this to my ISP . After some days, I could reach this website, I don’t know if ISP issue or there is something wrong with this Domain Name (because I don’t really trust ISP people if they can fix such problem at least in this country ).
It sounds like the the remote site is doing a DNS lookup with the IP address, which will result in its trying to reverse resolve it. That is probably timing out.
Oh but there is. A domain is a word that a human can remember easily, an ip is the actual address of the machine. The machine doesn’t need the dns to know where it needs to send its data. As you can see there is a layer between the two that translates the domain to an IP address. The problem that your isp might have is that its dns servers are slow. If you want to keep using the domain name of your server try to use a different dns server at the remote site to resovle the address. Try google’s or opendns’s.
at least in this country ).