IPKall - Calls IN to Obi can hear me but I can't hear them

[777funk]

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.

[hwittenb]

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.

[777funk]

Here's what I've got. I tried varying a few things.

Is there anything obviously wrong here:

[777funk]

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.

[carl]

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.

[777funk]

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.

[hwittenb]

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

[777funk]

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.

[azrobert]

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.

[hwittenb]

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.

[obiliving]

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.

[777funk]

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.

[Shale]

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

[hwittenb]

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

[gderf]

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?

[azrobert]

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.

[gderf]

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?

[azrobert]

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.

[gderf]

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

[azrobert]

What does your SP3 X_InboundCallRoute look like?