Search found 277 matches
- Thu Mar 15, 2012 3:13 pm
- Forum: Technical Support
- Topic: Taking longer to make calls
- Replies: 5
- Views: 972
Re: Taking longer to make calls
Could be the stun server. The client waits for the stun server reply until it times out. I had that happened in the remote past.
- Sun Jan 15, 2012 9:34 pm
- Forum: Technical Support
- Topic: No Incoming Calls to softphone (Blink) after a while
- Replies: 7
- Views: 1697
Re: No Incoming Calls to softphone (Blink) after a while
This is something off topic. I remember the keepalive interval over TCP connection is the same 10s as over UDP. I had a thought maybe it can be longer like 10 or 15 minutes over TCP without introducing extra complexity or load to the server. Mkae sense?
- Sun Jan 15, 2012 9:24 pm
- Forum: Technical Support
- Topic: Connecting to SipSorcery on TLS connection
- Replies: 13
- Views: 3257
Re: Connecting to SipSorcery on TLS connection
I tried several combinations. It looks like when the header (From: maybe) strings contain the trailing port number, i.e. sipsorcery.com:5061, the server will reply "domain not serviced". Without the trailing port number, softphones use default port 5061 and connection will be successful. I don't use...
- Sun Jan 15, 2012 9:04 pm
- Forum: Technical Support
- Topic: SSH access
- Replies: 1
- Views: 618
Re: SSH access
I was able to SSH into console using PUTTY and main account(web portal username). Looks like I forgot how to use sub account or filter sub account or maybe it is not possible to get sub account output via console.
- Sun Jan 15, 2012 8:57 pm
- Forum: Technical Support
- Topic: GV "_rnr_se key" error problem is back
- Replies: 32
- Views: 17100
Re: GV "_rnr_se key" error problem is back
Looks like Aaron has to set up a proxy for everyone to log in Google Voice via Sipsorcery IP, or maybe it is time Aaron to contact Google Voice team..
- Fri May 06, 2011 1:58 am
- Forum: Report a bug
- Topic: Broken: LastDialled.TransactionFinalResponse.StatusCode
- Replies: 4
- Views: 1732
Re: Broken: LastDialled.TransactionFinalResponse.StatusCode
The dial plan display bug was gone, and I did a quick test. The dial code I tried was: sys.Dial("xxx@provider.com", short_timeout) And the error occured again. It looks that if the provider does not respond within the timeout period, then LastDialled[0].TransactionFinalResponse or StatusCode is nil....
- Fri May 06, 2011 1:22 am
- Forum: Report a bug
- Topic: Broken: LastDialled.TransactionFinalResponse.StatusCode
- Replies: 4
- Views: 1732
Re: Broken: LastDialled.TransactionFinalResponse.StatusCode
I was about to do some more tests but found my dial plans all showed up as strange long strings. But calls went through fine. Minutes ago the dial plan showed up fine. I'll try later.
- Fri May 06, 2011 1:16 am
- Forum: Report a bug
- Topic: Broken: LastDialled.TransactionFinalResponse.StatusCode
- Replies: 4
- Views: 1732
Re: Broken: LastDialled.TransactionFinalResponse.StatusCode
The console message was the line posted above: "There was a missing method exception in your dial plan: undefined method `StatusCode' for nil:NilClass." I just now tried to replicate the issue but it is gone. Is it possible that in some specific situations the sys.LastDialled[0] be a null pointer? A...
- Thu May 05, 2011 8:26 pm
- Forum: Report a bug
- Topic: Broken: LastDialled.TransactionFinalResponse.StatusCode
- Replies: 4
- Views: 1732
Broken: LastDialled.TransactionFinalResponse.StatusCode
Just noticed my dial plan stopped working. The console gave the following message:
There was a missing method exception in your dial plan: undefined method `StatusCode' for nil:NilClass.
Guess Aaron was doing the improvement and changed something.
There was a missing method exception in your dial plan: undefined method `StatusCode' for nil:NilClass.
Guess Aaron was doing the improvement and changed something.
- Fri Apr 01, 2011 9:45 pm
- Forum: General VoIP Discussions
- Topic: GV+SIPGATE+SIPSORCERY problem
- Replies: 1
- Views: 1133
Re: GV+SIPGATE+SIPSORCERY problem
Try to enable STUN in your setup. The recent Google Voice provdier/dial-out implementation seems to have degraded NAT ability. My setups that don't have STUN enabled (to deal with other issues) encountered the same problem. With STUN enabled, voice came through fine. Aaron may have changed strategie...