Patch it!

I sent in my big patch today. Hopefully this is the first of many contributions to Sip-Communicator. I've had a whole lot of fun working on this project and I've got a whole big list of features that didn't make the cut for the Summer.

well, it looks nice in my head

So I coded up the configuration form for the Mailbox. Right now it doesn't do anything, but I was hoping that I could at least do a build/run and see if the buttons ended up the way I wanted them to.

Unfortunately, I can't get it to show in the GUI.

I took the PluginManager as a template, and I think that the mailbox is doing everything that PluginManager is doing, including

-A new class implements Configuration Form and Extends JPanel
-Activator Class Creates a new Instance of this class on Bundle Start
-Activator Class grabs the current configuration window from UIService.getConfigurationWindow()
-Activator Class calls addConfigurationForm() method to add my form to the configuration window

...but nothing happens. Not even an exception. A few logger.logInfo() statements suggest that the Mailbox form is being properly added to the list of config forms. I'm out of ideas.

where the hell am I

after a long hiatus I am back to hacking! It feels very good to be getting work done again... I think that working on this project is going to be hard to stop once the school year starts ;) Anyway, I've got the message cap working properly... the mailbox hangs up on the call when the incoming message hits X seconds (60 seconds is the default).

Up next is coding up a GUI form for the mailbox config parameters. I'm a bit worried that my Swing-fu has gotten weak from lack of exercise, so I may have my nose buried in a tutorial for a good portion of the rest of this evening.

Wish me luck.

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.

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.