[Sean Conner]

I'm currently running Phlink 1.6, but have had this problem sporadically with previous versions. A message is being recorded and for whatever reason, Phlink stops recording or cuts the message off — the person leaving the message is unaware of any problem and thinks their message was properly recorded. I'm not sure what the problem is since it is sporadic, although it occurs enough that I'm losing all trust in Phlink.

System details:
1) B/W G3 tower
2) Mac OS X Server 10.3.6
3) Phlink 1.6
4) ring script for Phlink Message Center integration
5) greeting script that plays a recorded message and also filters telemarketer numbers
6) message recording time = 240 sec
7) hang up after 7 sec of silence
8) messages are emailed

Log does not seem to indicate "long period of silence for detected, hanging up" when the problem occurs. It only says that the greeting is played, then "Recording Emailed."

I'm including the scripts — in case this is the problem. Anyone have the same experience, any suggestions? solutions?

ring script follows:

property webrootpath : "Solitude:Shared:web:phlink:"

on incoming_call given call:c, callername:n, callerid:cid
set my_call_again to false
if the length of n is 1 then
set n to "Unknown Caller"
end if
if the length of cid is not 0 then


set Areacode to (characters 1 thru 3 of cid) as text
set num1 to (characters 4 thru 6 of cid) as text
set num2 to (characters 7 thru 10 of cid) as text

set this_data to "<tr><td class=row2>" & ((current date) as string) & "</td><td class=row2>" & n & "</td><td class=row2> (" & Areacode & ") " & num1 & "-" & num2 & "</td></tr>" & return
set this_file to (webrootpath & "call_log.txt")
my write_to_file(this_data, this_file, true)

else
-- Don't do anything: the caller's info was already logged

set my_call_again to true
end if
return my_call_again
end incoming_call


on write_to_file(this_data, target_file, append_data)
try
set the target_file to the target_file as text
set the open_target_file to ¬
open for access file target_file with write permission
if append_data is false then ¬
set eof of the open_target_file to 0
write this_data to the open_target_file starting at eof
close access the open_target_file
return true
on error
try
close access file target_file
end try
return false
end try
end write_to_file

try
--replace this line with your statements
on error error_message number error_number
set this_error to "Error: " & error_number & ". " & ¬
error_message & return
-- change the following line to the name and location desired
set the log_file to (("Solitude:Shared:web:phlink:Messages:") as text) & "Script Error Log"
my write_to_file(this_error, log_file, true)
end try


greeting.scpt follows

property my_recipient : ""
property the_kill_file_name : "kill.txt"
property the_kill_sound_file_name : "kill.wav"


on do_action given call:the_call, callerid:the_callerid
tell application "Ovolab Phlink"
set the_items_folder to the items folder
end tell
tell application "Finder"
set the_kill_list to paragraphs of (read file ((the_items_folder as text) & the_kill_file_name))
set the_kill_sound_file_reference to ((the_items_folder as text) & the_kill_sound_file_name) as alias
end tell

tell application "Ovolab Phlink"
if the_kill_list contains the_callerid then

tell the_call
set beep after greeting to false
delete every recording
play the_kill_sound_file_reference

-- Provide a bit of time to ensure that playback has commenced.
delay 1

-- Keep polling to determine when playback has completed.
repeat until playback status is stopped
delay 1
end repeat
-- Bye, bye!
hang up
end tell
else
tell the_call
log ("Message for " & my_recipient) as text
--delete every recording
set beep after greeting to true

set my_dest to "Solitude:Shared:web:phlink:Messages:"
tell application "Finder"
copy (my_dest as text) & my_recipient & ":" to my_dest
end tell
--tell the_call to play outgoing message
play ("Solitude:Library:Application Support:Phlink Items:Outgoing:greeting.aif") as alias

--start recording message
start recording
set the recordings folder to (my_dest as alias)
set my_name to the filename of the current recording
set my_name to (my_name & "-" & the name of the calling party)
set the filename of the current recording to my_name
end tell
end if
end tell
end do_action

[rhi]

I've seen this also.

The Phlink log window shows the duration of the call as longer than the actual duration that is encoded/email.

Are you, by chance, using the 3GPP Quicktime compression ?

I'm wondering if this may be some sort of Quicktime issue, since Phlink seems to show a recording time longer than that acutally saved.

Rich

[Sean Conner]

Rich
I am using the default AAC encoding. Is there a reason I should suspect encoding? It is an interesting possibility. Any suggestions on how I could test it if this is the case? I only see the problem sporadically. Does Quicktime have a error log or something I could check? I've never run across it. I don't see anything in the System.log.

[rhi]

Sean,

The only thing that lead me to wonder about Quicktime was that the Phlink log window seems to show call durations of 30-40 seconds (after answering) and there's only 15 or so seconds in the encoded file that gets emailed. I know it's not silence truncation, since in most cases the caller is cut off in mid-word.

It doesn't always happen, but it would be nice to pin this down.

Similarities in our systems: 10.3.6, B&W G3 (400 MHz, in my case), Phlink 1.6 and a ring.scpt script. I'm running a custom ring.scpt that I have set up to terminate annoying telemarketing calls.

Anyone else out there seeing this message truncation ?

Rich

[rhi]

OK, so it's a rainy day and I'm intent to procrastinate as much as possible before putting up the holiday decorations.

I decided to run some tests to see what the cause of the truncated messages could be.

Here's what I've learned. Perhaps Alberto can shed some light on whether any of this is significant or not. Maybe something here will help to track this down.

1. Unlike I'd originally suspected, this is not a Quicktime problem. I've reproduced it using 3GPP as well as AAC encoding.
2. It doesn't seem to matter whether Phlink is in the background or is the front most app.
3. This is sporadic. It does not happen every time.
4. This seems to happen more frequently on cellular calls, although since I've been doing the majority of testing with those, this may be a false data point.
5. Maximum call duration and Maximum slience setting are not involved.
6. When a call is abruptly terminated, the Phlink message window displays a little "empty plug" icon and says "Device not connected" or something to that effect. This happens everytime a call or message is improperly truncated.
7. There is an odd log entry that shows sane values for Time, Caller, Caller ID but shows a set of characters for the Event. This corresponds to the truncated calls as well. From looking in the log plist, here's the entry:

[Alberto]

[rhi]

[rhi]

Just an update...

Running the Ovolab adapter on the PCI USB card for the last 24 hours and there have been no dropped or prematurely terminated calls.

Debugging info is being logged to console.log, but there's nothing unusual there.

When I get a little time toward the weekend, I'll switch back to the on-board USB port and see if I can get it to act up again. The log entries might help nail down what's going on.

Rich

[okrauth]

Hmmm... I have the same machine B/W G3 (400Mhz) and I am experiencing the same problems as described.

Please keep us posted. I would like to know if your USB card solved the problem.


Otto

[rhi]

Otto,

The system has been completely reliable since I switched to the USB PCI card. I still haven't had the opportunity to switch back to onboard USB to see if I can replicate the problem, but I plan to do so as soon as I get a little time to play.

I don't think it matters - any PCI card should be fine - but the one I'm using is the IOGEAR USB 2.0 card. This card doesn't seem to support "deep sleep" mode, but I don't really mind since the Phlink G3 is powered up at all times anyway.

Hope this helps...

Rich

[okrauth]

I've install an IOGear USB/Firewire card on my G3 and placed the phone adapter there... reinstall PHlink (removed all the preferences, etc).. it asnwered one phone call and right after that it started dropping messages again... it doesn't even play the welcome message. I did notice the message "No device found" after the message was dropped!

Back to drawing board on this one... not sure what to do now... but so far I've lost all confidence on the device...

Otto

[equitek]

I was having all kinds of weird trouble until I downloaded a fresh copy of 1.6. I read elsewhere on these boards that there was a problem with the initial 1.6 posted, and that those that downloaded on the first day might have trouble with the initial 1.6 build. That was certainly the case for me.
_________________
-David Schaefer
Equitek, Inc. (equitek.com)

[okrauth]

UPDATE: I've installed a USB hub between the computer and the Phlink module and the problem seems to have gone away.... so far 24 hours, 10 phone calls recorded and no dropped calls!!!

Lets hope that the problem doesn't come back!!!


Otto

[Sean Conner]

It has been a while since my original post — busy with life as usual, but have had to tolerate the Phlink issue of dropped calls. I set the diagnostic from the terminal and am wondering what this means:

console reads:
AppleUSBCDC: start - initDevice failed

Does this mean I have a Phlink adaptor problem or a problem with my USB port? I suspect the USB port. I think I will try the suggested USB PCI card and see if that fixes the problem. If someone has another suggestion, I would love to hear it.

[Sean Conner]

I have now installed a new USB card and this has solved the dropped call problem. Phlink has functioned quite well without a single dropped call for about a three weeks. The diagnostics were helpful, I just wish there was a good way to determine this sort of hardware problem faster — without having to buy new hardware first. Thanks for the suggestion Rhi.