while you were out

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

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

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

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

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

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

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

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

Setting up a test environment

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.