Wednesday, July 25, 2007

well that was easy

I got it working so that the incoming message starts recording just as the outgoing message finishes.

So the mailbox sort of works. I'm pretty excited. Frankly I'm not sure what I should do next.

Some of the possible candidates:

-expose some sort of GUI functionality for playing received messages and/or alerting the user to the fact that messages were received. Seems like this would go on the "call list" tab on the SIP-communicator GUI.

-enable a time or size maximum on incoming messages. As it stands if the caller forgets to hang up it's possible that the incoming message might fill up the hard drive, which would be bad.

-Right now the incoming message is audio-only. Perhaps I could auto-detect if there is an incoming video stream and record to video if that is the case

-Set up custom outgoing messages, IE associate each outgoing message file with a contact so that if your mom calls she hears message A but if your boss calls he hears message B.

-Perhaps have a "record outgoing message" function from within SIP-Communicator? IDK if this is necessary as all the OSes SC comes on have some sort of sound recorder built in.



At first glance it seems as though a size cap on incoming messages is most important, followed by some sort of GUI exposure. But I'll probably put it to Emil and whoever else and see what rises to the top.

Good news in many varieties

Finally a bit of good news.

-Merged all the changes from mainline into the necessary media files. Also learned that meld is, for lack of a better phrase, pretty goddamned sweet.

-The config file works as expected.

-I figured out a way to get the output media file's duration (so I can wait that long to start recording). It seemed that the sanest way was to add a field in MediaControl called getOutputDuration(). This field performs a call to getDuration() on the Processor object it is using for outgoing media. This won't mean a whole lot if the output source is a microphone/webcam, but if it's a file then it properly returns how long the file is. This means that I can call mediaServCallBack.getMediaControl().getOutputDuration().getSeconds() and I know how many seconds I need to wait to start recording. Hopefully I'll have that implemented by the end of the day.

Tuesday, July 24, 2007

found it

someone made substantial changes to CallSessionImpl.java that need to be merged into my version.

Why it took me so long to realize that, I'll leave that as an exercise for the reader.

shouldn't have done that

Well, I committed the sin of "implementing feature B before testing feature A," and now here's where I am at:

Whenever I try to connect a call (either via clicking the answer button or via letting the mailbox pick it up) I get "java.net.BindException: Address already in use." This also happens when I try to create an outgoing call. This is caused by one of the following:

-something I did while trying to move some values to the configuration files
-something I did while trying to get the incoming message to wait for the outgoing message to finish before recording starts
-something else entirely.

Right now neither scenario is looking very likely.

Sunday, July 15, 2007

check one more thing off my list

The Mailbox now loads the settings for the outgoing message location, incoming message location, and wait time from the config file.

At least I think it does. I haven't had time to test it yet.

It does compile, though, so I am checking in and going to bed.

Wednesday, July 11, 2007

can you hear me knockin?

Outgoing message works. Incoming message works. Neither of them try to run when you pick up the phone.

This is good.

Anyway, I've got two things to fix right away:

1. The incoming message starts recording as soon as the call connects, so it picks up some of the outgoing message as well.

2. I need to move the settings for the location of the outgoing/incoming messages out of the code and into the config file.

Tuesday, July 10, 2007

Leave a message after the tone

After messing around with all the quirks in manager.createDataSink, I finally got incoming audio to record to a file. Very exciting.

Now I need to have the mailbox tell the media service which calls it needs to record and which it needs to play as normal.

breaking rocks in the hot sun

Yesterday I did some code tidying to get my project ready for some additional midterm eyeballs. This included removing the unnecessary Mailbox Service that I was exporting and changing the outgoing message to a location inside the repository instead of /home/ryan. Eventually I will use a config file entry to point to the outgoing messsage, but in the mean time at least it will work after a fresh checkout.

Friday, July 6, 2007

the internet is nice sometime

Tried to get sip-communicator recording all incoming audio to a file today (figured that was a good first step in getting it to record incoming audio to a file some of the time). My first go at it came back with an empty file and a NoDataSinkException. It turns out that someone else had a similar experience and the process for creating a data sink is a bit more complicated. However, it does appear fairly straightforward to create a processor and do a transcode, so hopefully I'll have incoming audio working soon.

Thursday, July 5, 2007

in your head, in your head. zombie

Had a major setback the last few days in the form of a rather nasty sinus/throat/sneeze/cough thing. Tried to sit down and hack a few times but I'm more or less useless in my sick/medicated state. On the bright side it feels like it's about to pass, so I should hopefully be able to get some definite progress on getting an incoming message recorded over the weekend. Hopefully.

At the very least, I'll try to keep posting more, even if it's a few more days of "too sick to code, drank lots of tea and watched movies all day."