IPKall - Calls IN to Obi can hear me but I can't hear them
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:
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.
Shale:
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
hwittenb:
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
gderf:
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page