Audio/Video Mailbox for SIP-Communicator

Patch it!

2007-08-17T00:27:00.000-07:00

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

2007-08-14T01:09:00.000-07:00

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

2007-08-13T20:19:00.000-07:00

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

2007-07-25T20:30:00.001-07:00

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

2007-07-25T07:47:00.000-07:00

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

2007-07-24T23:27:00.000-07:00

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

2007-07-24T23:04:00.000-07:00

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.

check one more thing off my list

2007-07-15T21:43:00.000-07:00

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.

can you hear me knockin?

2007-07-11T12:46:00.001-07:00

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.

Leave a message after the tone

2007-07-10T13:23:00.000-07:00

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

2007-07-10T08:06:00.000-07:00

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.

the internet is nice sometime

2007-07-06T15:12:00.000-07:00

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.

in your head, in your head. zombie

2007-07-05T21:46:00.000-07:00

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."

It works better!

2007-06-28T12:48:00.001-07:00

Based on a conversation with Emil today, I changed the way that the DataSource is switched over to a file. Instead of changing the default data source, I have sip-communicator make a new instance of MediaControl, instantiate it with the outgoing message file, and place the mapping of that particular mediacontrol to that particular call in a hashmap. Once the call ends, said mapping is removed. In this way, calls that are picked up normally get the usual DataSource while calls that are picked up by the mailbox get the outgoing message.

And to top it all off, it actually works!

I suppose that My next goal is to get the input from the remote caller redirected to a file and save the incoming message. Wish me luck.

It Works!

2007-06-27T14:33:00.001-07:00

I got an outgoing message to play today!

So what was that insidious bug, lurking around in my code, preventing the file from playing?

I forgot to tell the Mailbox to quit waiting after it starts to connect the call. It just kept looping, re-starting the call every 10 seconds.

D'oh.

Right away I noticed that I forgot to set SIP-Communicator's data source back to default after the call ends, so the next call gets connected to the outgoing message even if you click the "connect" button. so fixing that is my next step.

Luckily, the CallListener interface (that Mailbox already implements) has a CallEnded method that will be called when a call ends. So I will insert code there that will check to see if the data source is set to default and re-initialize it if it is not.

Easy, right? Ah, the hubris of optimism.

Datasources in the mist

2007-06-25T10:26:00.000-07:00

This morning I observed how sip-communicator plays out from a file while in its natural habitat. I knew that sip-communicator had such functionality from looking at the code, but as until a recent conversation with Emil I hadn't known how to turn it on. turns out that is as easy as adding the following little tidbit to sip-communicator.xml:

(NOTE: Blogger ate my XML, so I replaced the angle brackets with square brackets. You get the idea)

[media]
[debug_data_source_url value="file:///home/ryan/Desktop/lostinspace.mov"/]
[/debug_data_source_url]
[/media]
[/impl]

notice that the tag is nested within the tag. The namespace resolution for the system properties follows the structure of the xml document.
Some.System.Property.Here corresponds to [some][system][property][here value="stuff"/][/here][/property][/system][/some]

I also installed JMStudio so that I can be sure that if a file doesn't play in the future that it is my fault and not JMF's

Easier than I thought

2007-06-21T11:47:00.000-07:00

I found a much easier way to load up two instances of sip communicator with different config files (and therefore different sip accounts).

It turns out that the first place that sip communicator looks for a configuration file is the current directory, IE the directory from which ant is called. So I just have a separate sip-communicator.xml file in my sc-avmailbox directory.

I'm not going to mention the system that I had in place earlier. Such Kludges ought not be discussed in mixed company.

more little issues

2007-06-20T08:08:00.000-07:00

spent the morning tracking down some new problems with importing sip-communicator's build.xml. I want to say that I've got it all figured out and I can now focus all my energies on getting the mailbox to work properly, but I've said that before ;)

Anyway, at least I know that my repository has everything it needs, in case I need to do a spontaneous reformat/reinstall like I did yesterday. Long story short, backups are good.

I feel like I contributed something

2007-06-19T16:45:00.000-07:00

My patch got accepted and I can now build sip-communicator and sc-avmailbox using the cvs copy.

I figured out why files were mysteriously missing from my svn repository today after I did a checkout. It turns out that copying over backed-up files into a blank repository and including the ".svn" folder will make svn think that files are in the repository when they are not. I think I've got it all sorted out though.

it works!

2007-06-14T11:44:00.000-07:00

I sent in what is (hopefully) my first working patch to the dev mailing list today.

After tracking down a few nit-picky errors, I've got my project set up so that I can update sip-communicator from cvs, update sc-avmailbox from svn, and nothing breaks!

yet.

check back in a few days and see if I'm so optimistic.

Anyway, back to work on getting an outgoing message to play. Last I checked the call to manager.createDataSource was coming back null. Since this method usually throws an exception when it messes up (IE the NoDataSourceException described earlier), I'm not even sure what that means.

Modifying build.xml to be import-able

2007-06-12T21:57:00.000-07:00

My first hurdle in setting up the parallel repositories for my code and sip-communicator is the fact that the sip-communicator build.xml file does not refer to itself in a way that makes it importable.

I'd go on and explain, but really the apache documentation on the import function does a much better job. Basically I need to change the file so that input files are taken from /path/to/where/the/buildfile/is/src, but output files go to /path/to/where/the/buildfile/isrun/from/sc-bundles

Basically this post was written to give me a break in the find- and replacing.

:)

just realized that the blog is quite outdated

2007-06-12T20:49:00.000-07:00

all that business I was talking about before, forget it.

Here is the new new strategy for getting my code to work alongside sip-communicator:

-have both projects stored under /home/ryan/sip, side by side. My code is in /home/ryan/sip/sc-avmailbox and the sip-communicator sources are in /home/ryan/sip/sip-communicator.

-have the build.xml in sc-avmailbox import the build.xml in sip-communicator, redefining targets as necessary to build the files that I've added to sip-comm

-using some ant trickery, make sure that for any files in sip-comm that I modified, my version is built instead of the sip-comm version.

After a conversation with emil, I think that I'm ready to get all the little details in this strategy ironed out. Hopefully after I do so I'll be able to make a template that other people in a similar situation (having to develop an addon while staying current with main) can follow.

late breaking news

2007-06-04T22:04:00.000-07:00

svn is a working, building, complete copy of sip-communicator.

project website looks like it should.

I feel so fresh, so clean.

Anyway, back to work.

a little progress on both fronts

2007-06-04T21:58:00.000-07:00

on rebooting the repository:

Wow, was that a mess. But once I figured out that doing a "cp -R *" on a working copy retains a bunch of '.svn' files that mess up my attempts at cleaning out the repository and starting over. Duh. Ah well, after a bit of wasted time I think I'm waiting through the one great file transfer that will give me a real repository. Let's hope.

I also figured out that the project's website is copied in the www folder, so the website is currently blank. Should be able to fix that by the end of the night.

On the code:
I fixed all the compiler/design level problems (I think), but I get a NoDataSourceException when I try to set up a sendstream on the outgoing message file. More on that as I get to the bottom of it.

fork this

2007-06-02T14:15:00.001-07:00

I'm trying to see if my modifications to the MediaService class/interface to handle incoming calls worked, and I've got all sorts of build errors in different parts of the project. My original intent in setting up a build environment was to have an update-able copy of SIP-Communicator alongside any copies of files I'd need to modify in a separate folder connected to my svn repository.

That was a bad idea.

Later tonight I am going to make a checkout of sip-communicator, move the necessary files over to my project folder, and do a reboot of my svn repository. I'll worry about merging back into mainline at a later date. Better than worrying about it every time I want to do a build.

while you were out

2007-05-30T11:58:00.000-07:00

I've been involved in a few different things that have taken me away from hacking for a few days, but I'm back for at least a little more code today.

Thankfully, Emil wrote a very helpful post that has clarified the direction I am taking to send out an outgoing message.

Education, but not much in the way of results

2007-05-20T02:41:00.000-07:00

Well, I think I've got a fairly decent graph about how Sip Communicator handles setting up an RTP stream for incoming calls.

Problem is, I can't touch any of it from my code.

So implementing CallListener means that the Mailbox bundle can receive CallEvents when a new call comes in. Right now it does that, and properly waits around for the call to go unanswered.

My plan after that was to expose the RTPManager associated with that call, have it create a new SendStream using a DataSource I set up from the outgoing message file, and then essentially make SIP Communicator think that I had pressed the "answer call button." After all the SIP handshaking, CallManager would start up my SendStream for me and I'd be rocking. Easy Peesy, right?

not so much. It turns out that the method of CallSipImpl that exposes the CallSession object is not part of the Call interface, meaning I can't get to it from a package import. Same story with CallManager's AnswerCall method - it's not in an interface for a bundle so I can't get to it.

This is somewhat irritating, for a few reasons

-Since my experience with SIP Communicator and OSGI is quite limited, I was fooled by the fact that both of said methods have "public" scope.
-This means that neither of these problems show up at compile-time... all I get is a "NoClassDefFound." The compiler knows where these classes are via a simple import, but the runtime classloader can apparently only see the bundles that are listed in the application's manifest, and so trying to cast down to CallSipImpl fails miserably.
-All of this meant that I wasted a load of time trying to figure out what the problem was.

Ah well, que sedilla sedilla.

Anyway, I see the road ahead of me going in one of three directions

-I'm missing a really obvious way to set up a SendStream and I'll be kicking myself once I figure it out
-I need to handle all the SIP Handshaking as well as setting up a new RTP Manager all in the mailbox, which seems like way too much reinventing the wheel
-I need to change my whole design plan and instead focus on modifying the classes that already handle incoming calls. I don't even want to think about that one right now.

Anyway, day wasn't a total loss as at least I feel like I know what's going on.

deeper into the muck

2007-05-19T23:03:00.000-07:00

so it turns out that the process of "connect the call" is substantially more complicated than I had first imagined. However, I am slowly learning.

Thanks to a great collection of charts I think I understand the handshaking that normally works in connecting a call via SIP.

What I am trying to figure out is where along the line SIP-Communicator connects the actual RTP Stream, and how I can emulate that function in the mailbox service.

It worked

2007-05-19T16:57:00.000-07:00

I can now answer the phone even while the MailboxService is waiting to answer the phone.

And it appears that java threads die as I had imagined.

So all is well. Let's see if I can play back an audio file by the end of the night.

Threads in Sip Communicator

2007-05-19T16:13:00.000-07:00

Today I am investigating how threading is handled by SIP Communicator.

So far it appears that the standard way of handling some action that must run concurrently is to

1) create a nested class following the naming template "DoSomething" (example: LaunchBrowser within BrowserLauncherImpl.java). Have that class extend Thread (or implement Runnable) and contain what needs to be done in the run() method
2) When the time comes, invoke the necessary code with the new operator.

I am going to try and get this system working for waiting for incoming calls.

Right now my big question is whether a thread will die a proper death once it meets the end of the run() method. Intuitively, that would seem to make sense, but I'm going to try and confirm it in the docs before I code it.

I just got here, I'm going to try not to mess up the place by leaving threads all over.

I built something

2007-05-15T12:54:00.000-07:00

After far too much frustration and procrastination, I've got the following done:

-the mailbox service is built and deployed along with SIP-Communicator. Tricky, but the online tutorials proved very helpful

-the mailbox service now listens for an incoming call. I had it wait 10 seconds and then print out to the console, so the first milestone is complete. Sort of. Right now, when the mailbox service is informed about an incoming call, it loops until either the call is picked up or 10 seconds have elapsed. the problem with this is that the flow of execution is trapped within that method, so you can't actually pick up the call ;)

Problems to solve for next time - how can I wait for an incoming call while allowing the rest of the application to continue normally.

Next Milestone: connect the call and play a file.

This is london calling

2007-05-09T18:06:00.000-07:00

The SIP Communicator devs got me set up with two test accounts on an asterisk server, so now I can make test calls.

Goal for tomorrow is to get some code listening for call events and integrated into the build.xml

Wish me luck.

test call numbers

2007-05-08T20:55:00.000-07:00

Just found a page of SIP test numbers that will probably turn out to be pretty useful.

Setting up a test environment

2007-05-08T18:22:00.000-07:00

So today my goal was to set up a test call so that I can better observe how SIP communicator handles incoming calls. This turned out to be a little more challenging than I had hoped.

One of the big reasons that I've used Skype in the past instead of an SIP client is that I don't have a public IP address due to the fact that I am behind my campus NAT. So I need to find a way to set up SIP communicator to make a call either over a LAN or over the local machine. Since this is not the normal operation of SIP communicator, there's no obvious way to set this up. I asked for guidance on the dev mailing list, which also served as a decent excuse to introduce myself.

Let's hope that I can figure this nonsense out tomorrow.