Problem with connecting IPphone to OBi110
Siteweb65:
Hi Guys
Sorry for the long delay, life took over for a while ;-)
OK, Ive tried all the above fixes, but still have no audio :-(
The phone connects and dials the number OK, I can listen in on a seperate phone plugged into the PSTN line after dialing and hear my message service, but still no audio on the DX800.
Is there any way of drilling down deeper to see if voice packets are being passed between the two Obi devices ?
hwittenb:
Quote from: Siteweb65 on October 31, 2014, 04:41:50 am
Hi Guys
Sorry for the long delay, life took over for a while ;-)
OK, Ive tried all the above fixes, but still have no audio :-(
The phone connects and dials the number OK, I can listen in on a seperate phone plugged into the PSTN line after dialing and hear my message service, but still no audio on the DX800.
Is there any way of drilling down deeper to see if voice packets are being passed between the two Obi devices ?
I would run a syslog trace on the call to see the sip signalling to see if that gives a clue to the problem.
As I said audio problems are usually caused by one side or the other sending a local ip address instead of an external ip address or vice versa. It can also be caused by incomplete call signalling where one side doesn't receive an expected acknowledgement. A further problem can be caused when routers are changing port numbers. A sip trace is used to try to pin down the cause of the problem.
To run a syslog trace you download and install a syslog program on your computer and make some configuration settings. Obihai has instructions here and a simple pc syslog program for download:
http://www.obihai.com/faq/Troubleshooting-sec/collect-syslog-from-OBi
A more sophisticated trace can be obtained with the WireShark packet trace program but that requires that the computer running the program to be able to see all the packets going and coming from the OBi.
Siteweb65:
Hi hwittenb
Thanks for your reply, I already have Wireshark so I'll see what I can do with that, my question was more a wonder if the Obi's had internal logging of packets that I could view.
My setup here is 100% internal on the LAN, no external IP's are referenced within this set up (though I have other SIP services running that use external SIP providers), thats why I find it strange, I'd have thought that packets would have naturally been routed to other internal devices.
i'll come back with any findings, thanks again
hwittenb:
If WireShark can see all the packets it has a feature where after a capture you can click on VoIP calls and it will highlight the calls and then the signalling for a particular call. It is really a useful tool. If rtp packets are being sent they are also easy to see because they dominate a capture.
In my opinion Obihai never intended for people to use direct ip addressing for calling. I don't believe it is part of their software regression testing, the admin manuals don't discuss it.
Siteweb65:
OK, wireshark coulnt see all packets so Im using the suggested logger
Log from OBi101
[Oct 31 16:19:14][192.168.1.101]<7> FXO:make new call
[Oct 31 16:19:14][192.168.1.101]<7> [DAA]: FXO OFFHOOK
[Oct 31 16:19:14][192.168.1.101]<7> FXO:NewTermState:offhook
[Oct 31 16:19:15][192.168.1.101]<7> FXO:Start Tone 3
[Oct 31 16:19:15][192.168.1.101]<7> [CPT] --- FXO s/w tone generator (3) ---
[Oct 31 16:19:15][192.168.1.101]<7> FXO:Stop Tone
[Oct 31 16:19:15][192.168.1.101]<7> FXO:Start Tone 1
[Oct 31 16:19:15][192.168.1.101]<7> [CPT] --- FXO s/w tone generator (1) ---
[Oct 31 16:19:15][192.168.1.101]<7> FXO:Stop Tone
[Oct 31 16:19:16][192.168.1.101]<7> FXO:Start Tone 0
[Oct 31 16:19:16][192.168.1.101]<7> [CPT] --- FXO s/w tone generator (0) ---
[Oct 31 16:19:16][192.168.1.101]<7> FXO:Stop Tone
[Oct 31 16:19:16][192.168.1.101]<7> FXO:Start Tone 3
[Oct 31 16:19:16][192.168.1.101]<7> [CPT] --- FXO s/w tone generator (3) ---
[Oct 31 16:19:16][192.168.1.101]<7> FXO:Stop Tone
[Oct 31 16:19:16][192.168.1.101]<7> FXO:ConnectRightAway
[Oct 31 16:19:16][192.168.1.101]<7> FXO:OutboundConnected
[Oct 31 16:19:16][192.168.1.101]<7> RTP:DtmfTxMtd:1(1),0
[Oct 31 16:19:16][192.168.1.101]<7> RTP:Start->c0a80166:16606(81);0;0;0:0:0;0(26
[Oct 31 16:19:54][192.168.1.101]<7> [DAA]: FXO ONHOOK MONITOR
[Oct 31 16:19:54][192.168.1.101]<7> FXO:NewTermState:onhook
[Oct 31 16:19:54][192.168.1.101]<7> RTP:Del Channel
[Oct 31 16:19:54][192.168.1.101]<7> [JB] call overall status --
peer: 192.168.1.102:16606,
local: 192.168.1.101:17610,
pkt_tx: 1874,
pkt_rx: 1867,
bytes_tx: 322328,
bytes_rx: 321124,
clk_diff: -48 PPM,
pkt_in_jb: 3,
pkt_ooo: 0,
pkt_lost: 0,
pkt_late: 0,
pkt_loss_rate: 0 %,
pkt_drop_rate: 0 %,
jb_len: 180 ms,
curr_rcvd_jitter: 4 ms,
rcvd_digits: 0,
underruns: 0,
overruns: 0,
seq_num_broken: 0,
pkt_interp: 0,
skew_comp: 0 ms,
frm_in_pkt: 2
[Oct 31 16:20:26][192.168.1.101]<7> [DAA]: FXO ring on
[Oct 31 16:20:26][192.168.1.101]<7> [0]Ring On
[Oct 31 16:20:26][192.168.1.101]<7> FXO:NewTermState:ringing
[Oct 31 16:20:26][192.168.1.101]<7> ------ caller id (pcm_id: 1) received! -----
------
[Oct 31 16:20:26][192.168.1.101]<7> [0]DAA CND ,,,,,
[Oct 31 16:20:26][192.168.1.101]<7> [0]DAA CND ,,,,,
[Oct 31 16:20:30][192.168.1.101]<7> fxo: cp proceeding
[Oct 31 16:20:31][192.168.1.101]<7> [DAA]: FXO ring off
[Oct 31 16:20:31][192.168.1.101]<7> [0]Ring Off
[Oct 31 16:20:31][192.168.1.101]<7> FXO:NewTermState:onhook
[Oct 31 16:20:31][192.168.1.101]<7> FXO tell cc end-call
[Oct 31 16:20:31][192.168.1.101]<7> [DAA]: FXO ONHOOK MONITOR
Log from OBi200
[Oct 31 16:19:14][192.168.1.102]<7> CCTL:NewCallOn Term 10[0] obi200->3103@192.1
68.1.101:5060,3103@192.168.1.101:5060
[Oct 31 16:19:16][192.168.1.102]<7> RTP:DtmfTxMtd:1(1),0
[Oct 31 16:19:16][192.168.1.102]<7> RTP:DtmfTxMtd:1(1),0
[Oct 31 16:19:16][192.168.1.102]<7> RTP:Start->c0a80165:17610(80 0);0;0;0:0:0;0(40)
[Oct 31 16:19:16][192.168.1.102]<7> RTP:Start->c0a80164:5016(80 0);0;0;0:0:0;0(38)
[Oct 31 16:19:54][192.168.1.102]<7> RTP:Del Channel
[Oct 31 16:19:54][192.168.1.102]<7> RTP:Del Channel
Does that make any sense to you ? ???
Navigation
[0] Message Index
[#] Next page
[*] Previous page