I just setup an Obi100 with callwithus as my outgoing SIP and IPKall (free) as my incoming. If I call OUT from my Obi line, all is well.
However, if I call from a land line IN to my Obi line (the free IPKall Washington State phone number) they can hear me but I cannot hear the person on the other end.
IT seems to be a problem with the Obi configuration because on my softphone configured to the same SIP account (callwithus for outgoing linked to IPKall for incoming) everything works great.
Any tips on how to fix?
I've tried port forwarding on my Router and I've also tried STUN but I'm not sure I was doing it right. I clicked the Enable Stun box then entered the stun address in the box.
As you know, the CallWithUs FAQ has the following entry about forwarding a DID to your CallWithUs account:
Q. I have my own VoIP DID, can I redirect it to you server via SIP?
A. Yes. If you want to redirect the DID to ring your SIP client registered with our server, set the DID calls forward with your DID provider to username@did.callwithus.com, where username is your 9 digits username. Your SIP client must have STUN enabled or be on a public IP address, we do not handle media and NAT for DIDs from a third party. If you want to redirect the DID to ring your PSTN number using our service or to have additional features provided by our service like caller ID with name, multiple DID destinations or handle NAT issues by our server, we need to know the DID number to enter it to our system as a DID with $0.5 monthly price and $2 setup fee. Set the DID call forwarding with your provider to didnumber@did.callwithus.com that case.
An audio problem where you have one way audio like you describe is usually due to not properly transmitting your external ip address or external port number inside the sip signalling packets, i.e. a NAT problem.
It sounds like you have STUN enabled correctly on the Sip SPX that you have registered to your account at CallWithUs. You can use any STUN server, however callwithus provides this service at stun.callwithus.com. Since this didn't solve the problem I would also try enabling ICE along with STUN. ICE (Interactive Connectivity Establishment) is an additional protocol to alleviate NAT problems and is enabled, like STUN, on the ITSP Profile-->General Tab at X_ICEEnable [check]
When I test my OBi with an IPKall number with my callwithus account it works fine, with or without the addtional STUN and ICE settings but I have a different local network router than you do.
Here's what I've got. I tried varying a few things.
Is there anything obviously wrong here:
(http://www.rocketfireguitars.com/forums/other/Computing/Obi.png)
The weird thing here is that my wife's windows softphone (PhonerLite) works great (two way). Obi isn't so fortunate for some reason. I may have to try another ATA if I can't find the problem here. Seems like otherwise the Obi is pretty straight forward. Just this one problem.
Just put your Obi into DMZ on your router. They will tell you all kinds of stories how dangerous that supposedly is, I do it for nearly 2 years with 2 accounts and no problems ( of course, you use super strong passwords for everything and no automatic balance refill anyway). i had no other choice because my gateway will block VOIP traffic no matter what unless I engage DMZ.
I just ran into another problem. I call forked to my cell (android) and it's ringing now which is great!
But I can't transmit voice either direction. Any ideas what this could be?
...by the way Carl, I tried the DMZ mode and no change. Actually I bypassed the router completely without any change. Seems to be a setting or issue with the obi.
It sounds like you are doing the right things. I would run a detailed syslog on an incoming test call to see the packet detail of the sip signalling on the call to see if that gives any clue on what is going wrong. You are having problems starting up the voice rtp packet stream.
To run a detailed syslog you download and install a syslog program on a local pc. On the OBi's System Management --> Device Admin Tab you put the local network address for your pc running the syslog program in the Server box. The Syslog level should be the highest ... 7. On the Voice Services --> SPx Service Tab you set X_SipDebugOption to "Log All Messages"
The following OBi thread has a simple Windows pc Syslog program that you could download:
http://www.obitalk.com/forum/index.php?topic=707.0
As the thread indicates you can startup the program with the following Syslogd.bat. The program stores a log file on the pc's hard drive.
Syslogd.bat
syslogd -nl -s=all
I have a log from the folks at IPKall, however I'm not sure how much of it should be posted publicly since it has some sensitive data (IP addresses, and SIP numbers). There'd probably need to be a lot of blanking out.
You can try pointing IPKall directly to your OBi bypassing CallWithUs.
Use "anything@xx.xx.xx.xx:5060" as the destination in IPKall where xx.xx.xx.xx is your public IP address.
I got my IPKall number to work without Stun or ICE. I had to port forward the RPT ports to the OBi.
You could also take callwithus up on their 50c/month offer
"If you want to redirect the DID to ring your PSTN number using our service or to have additional features provided by our service like caller ID with name, multiple DID destinations or handle NAT issues by our server, we need to know the DID number to enter it to our system as a DID with $0.5 monthly price and $2 setup fee. Set the DID call forwarding with your provider to didnumber@did.callwithus.com that case."
and see if they solved your problem.
Can you show your SIP page settings (under ITSP Profile) also?
Don't enable STUN or ICE yet. Disable them for now.
Instead try disabling DiscoverPublicAddress if you have it enabled (checked) at the moment.
Quote from: obiliving on September 12, 2013, 10:56:13 PM
Can you show your SIP page settings (under ITSP Profile) also?
Don't enable STUN or ICE yet. Disable them for now.
Instead try disabling DiscoverPublicAddress if you have it enabled (checked) at the moment.
Just tried this and no go. Thanks for the idea.
Also, I noticed at times settings seem to change back to where they were automatically. I have the 192.168.1.118 and the web version open at the same time. MAybe that's creating the issue.
Quote from: 777funk on September 13, 2013, 11:43:01 AM
Also, I noticed at times settings seem to change back to where they were automatically. I have the 192.168.1.118 and the web version open at the same time. MAybe that's creating the issue.
See http://www.obitalk.com/forum/index.php?topic=92.0
Quote from: 777funk on September 12, 2013, 10:44:51 AM
I have a log from the folks at IPKall, however I'm not sure how much of it should be posted publicly since it has some sensitive data (IP addresses, and SIP numbers). There'd probably need to be a lot of blanking out.
Then you should examine the log yourself and look for the sip signalling in IPKall's log and compare it with the detail that you can get in a log of your own.
Here is what to look for in a detailed syslog from your OBi:
I am not a sip programming expert, however I believe the log will show the following...
1. Examine the sip signalling for the call setup. You should see:
--> Sip INVITE
<-- 100 Trying
<-- 180 Ringing
<-- 200 OK
--> ACK
--> BYE
The incoming Sip INVITE from IPKall will show the OBi
1. The ip address for the sip signalling answer
Contact:
Remote Party ID:
2. The ip address to send the rtp voice stream to IPKall
Message Body: (c) IN IP4 [ip address]
3. The port to send the rtp voice stream
Message Body: (m) audio xxxxx [port]
The Sip 200 OK signals the OBi's call answer and will show IPKall
1. The ip address to send the ACK
Contact:
2. The ip address to send the rtp stream
Message Body: (c) IN IP4 (ip address)
3. The port to send the rtp voice stream
Message Body: (m) audio xxxxx [port]
The ACK will tell the OBI that IPKall received the 200 OK and is ready to receive the rtp stream. If the ACK is not received, the rtp stream will not startup. The ACK is sometimes not received if the response to the Sip INVITE (Sip 200 OK) doesn't have the correct ip address or port number.
The OBi starts up its rtp stream to IPKall
IPKall starts up its rtp stream to the OBI
The OBi log has a 1-line entry stating that it started its rtp stream showing the ip address where it sent it in hex and the destination port in decimal. Something like this
[Sep 14 18:06:57][192.168.1.108]<7> RTP:Start->42368c2e:17940(80);0;0;0:0:0;0(22)
I don't see an entry in the OBi log for receiving the rtp stream from IPKall, although it was received.
The following will convert a hex ip address to decimal:
http://ncalculators.com/digital-computation/ip-address-hex-decimal-binary.htm
Quote from: azrobert on September 12, 2013, 11:33:22 AM
You can try pointing IPKall directly to your OBi bypassing CallWithUs.
Use "anything@xx.xx.xx.xx:5060" as the destination in IPKall where xx.xx.xx.xx is your public IP address.
I got my IPKall number to work without Stun or ICE. I had to port forward the RPT ports to the OBi.
Could you provide some more detail about this specific to an OBi200 if possible, especially which RTP ports you had to forward, protocol, etc?
Service Providers -> ITSP Profile (A,B,C or D) -> RTP
LocalPortMin thru LocalPortMax is the port range you need to port forward to your OBi.
Port forward the range of the SP you're using.
It won't hurt to port forward all ranges.
Protocol is UDP.
Thanks.
I am a bit confused though. I am doing this:
Use "anything@xx.xx.xx.xx:5060" as the destination in IPKall where xx.xx.xx.xx is your public IP address.
And I am forwarding the suggested RTP ports for an SP I already have configured for CallWithUs.
Where does port 5060 figure into this - do I have to forward that port also?
Use "anything@xx.xx.xx.xx:5060" to forward IPKall to SP1
Then port forward ITSP A RTP ports and 5060 to the OBi.
Use "anything@xx.xx.xx.xx:5061" to forward IPKall to SP2
Then port forward ITSP B RTP ports and 5061 to the OBi.
Sorry, I forgot about 506x.
I have done as you suggested but when calling the IPKall number there is no ringing heard on the calling phone and the phone on the OBi does not ring.
I have forwarded TCP/UDP 5062, and UDP 17000-17098 to my OBi which has CallWithUs registered on SP3.
My IPKall number is aimed at mycallcentricID@my.ip.add.res:5062
What does your SP3 X_InboundCallRoute look like?
{>anything:ph}
I think the problem is I need complete start to finish setup guidance for this SP via the OBi's webpage, or how to use OBiTALK to modify one of the built in canned configurations.
You setup this SP to block SIP scanners, but will also block calls from IPKall.
For a test try this:
{>anything:ph},{ph}
I have started over using a clean SP4 (deleted then added back in again).
In my router, I have forwarded the appropriate UDP RTP ports 17100-17198 and port 5063.
X_InboundCallRoute is set to the default value of ph.
The OBi was then rebooted.
IPKall is set to forward calls to SIP URI: 123@my_IP_address:5063
When I place a call to my IPKall number I get a busy signal. The phone does not ring on my OBi and I see no blocked packets in my firewall log during the time of call.
I don't know where else to look.
Do you have a provider setup on SP4?
If SP4 is not defined, setup a dummy SIP definition like this:
Service Providers -> ITSP Profile D -> SIP -> ProxyServer : 127.0.0.1
Voice Services -> SP4 Service -> AuthUserName : (any userid)
Voice Services -> SP4 Service -> X_RegisterEnable : (unchecked)
Voice Services -> SP4 Service -> X_ServProvProfile : B
For some reason I can not get your suggested changes to stick. They revert back to what they were after a reboot.
If you are using the Web interface (not OBiTalk network) to update the OBi do the following:
System Management -> Auto Provisioning
Under OBiTalk Provisioning:
Method: Disabled
Make sure you are changing Method under OBiTalk.
YES. It now works. Thank you so very, very much for all your help and your patience with me.
Great news!
To block scanners do this:
Change IPKall to:
user1@xx.xx.xx.xx:5063
X_InboundCallRoute:
{>user1:ph}
I did not test the above.
UGH, I spoke too soon. The phone rings but no sound in either direction. I did enable stun and am using stun.callwithus.com
I tested this a long time ago and don't remember what I did.
According to my post (Reply #8) I did not use Stun
I also tried stunserver.org, no joy there either. Oh well. Thanks again for all your help.
Try it without Stun.
I did try it without stun initially, no sound, so I tried with stun.
My IPKall is currently pointed to a provider.
I'm not going to play with it tonight.
Tomorrow I'll see if I can get mine to work again straight to my OBi.
Do you want to do this because IPKall doesn't work with CallWithUs?
Do you have another provider you can route through?
Routing IPKall in thru CallWithUs SIP URI does not work fully. I get sound in one direction only. I would settle for getting this working since I have an SP provisioned for CallWithUs for outbound only anyway that I might use in May.
I can route IPKall in thru Callcentric IP Freedom SIP URI and it works fine.
Please do not change anything in your OBi. I don't want to inconvenience you to that degree and possibly have you hose your setup.
Thanks again for all your help.
I was able to get IPKall to forward to CallWithUs SIP URI with sound in both directions by port fording the UDP RTP ports. I can live with this for now.
I found the problem.
I tried pointing my IPKall to SP2 on my OBi110.
I got 2 way audio.
The difference in our configs is my SP2 is registered to a provider.
Unregistering SP2 produced no audio.
I fixed the problem with the unregistered SP2 by doing this:
Service Providers -> ITSP Profile X -> SIP
X_DiscoverPublicAddress: Disabled (unchecked)
X_PublicIPAddress: xx.xx.xx.xx (your public IP address)
Do the above or use IPKall with a registered provider.
To block scanners:
Change IPKall to:
gderf@xx.xx.xx.xx:5063
X_InboundCallRoute:
{>gderf:ph}
Edit:
If you want to point IPKall to the SP CallWithUs is defined do:
Change IPKall to:
YourCallWithUs-ID@xx.xx.xx.xx:5062
And leave X_InboundCallRoute unchanged.
Thanks, I will try this.
I already have IPKall -> SP registered with CallWithUs. I needed to forward RTP ports to get two way audio though. This will be my fallback if I still can't get IPKall -> my_IP_Address working.
Edit: IPKall -> my_IP_Address rings but no sound in either direction.