[sip-comm-dev] GSoC 2009 - Sound Level Indicator - Mid Term Report

#1

Hi !

Here goes a brief report on my work in implementing a sound level indicator
up to now..
The following are my goals for the term.

Define the interfaces of the media service that allow tracking sound level
for a single call session (done)
Implement the above extensions (done)
Create unit tests for the above (not yet)
Define similar interfaces in the protocol provider service allowing to
retrieve SL info for a call participant (done)
Implement the above making them relay information received the media service
(done)
Add a linear (1-dimension) widget in the UI that displays information
received from the above mechanisms in a 1-to-1 call (done)

So with that implementing the sound level indicator for a 1 to 1 call is
completed. Here is a
screenshot<http://img200.imageshack.us/img200/1946/screeniip.jpg>which
shows the sound level indicator working for a 1 to 1 call.

In the next term I'll be focusing on these points along with the creating
unit tests part..

Make the media service interfaces and impl compatible with conference calls
Implement support for retrieving/sending per-participant sound level
information in RTP packets

Thank you..

Cheers
Dilshan.

#2

Hey Dilshan,

Dilshan Kanchana wrote:

Add a linear (1-dimension) widget in the UI that displays information
received from the above mechanisms in a 1-to-1 call (done)

So with that implementing the sound level indicator for a 1 to 1 call is
completed. Here is a screenshot
<http://img200.imageshack.us/img200/1946/screeniip.jpg> which shows the
sound level indicator working for a 1 to 1 call.

I was wondering whether there was a particular reason/problem that made
you put the levels on top and not below the image as Yana suggested.
Don't hesitate to let us know in case you are having trouble placing
them underneath the image.

In the next term I'll be focusing on these points along with the
creating unit tests part..

That would be tricky actually. We could lower the priority of this one
since I am not sure there's a sensible way to do the unit testing here.
Not at this stage at least.

Make the media service interfaces and impl compatible with conference calls

You can start by the GUI and a simulated conference (i.e. a call that
adds artificial participants). I am currently working on redesigning the
whole media package so that it would be more straightforward and usable
for Jingle. This would mean that any work you do on the media package is
likely to become irrelevant in the following week or two.

Implement support for retrieving/sending per-participant sound level
information in RTP packets

This is probably same as above.

This means that you can either concentrate on the conferencing UI or
take another temporary task. I suggested a possibility to Seb (improved,
nio based support for TCP), so let me know what you think of it.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#3

Hi Emil and all !

I was wondering whether there was a particular reason/problem that made

you put the levels on top and not below the image as Yana suggested.
Don't hesitate to let us know in case you are having trouble placing
them underneath the image.

In fact, I tried a lot to do this. And at last I was successful. I just
committed the code. Here is a screen shot of call dialog after the change
has been done.
http://img193.imageshack.us/img193/9393/sli.jpg

In the next term I'll be focusing on these points along with the
> creating unit tests part..

That would be tricky actually. We could lower the priority of this one
since I am not sure there's a sensible way to do the unit testing here.
Not at this stage at least.

Ok. Then I will forget about unit testing for the moment.

You can start by the GUI and a simulated conference (i.e. a call that
adds artificial participants). I am currently working on redesigning the
whole media package so that it would be more straightforward and usable
for Jingle. This would mean that any work you do on the media package is
likely to become irrelevant in the following week or two.

I'm glad to start creating a UI for the conference in the way Yana
suggested.

This means that you can either concentrate on the conferencing UI or
take another temporary task. I suggested a possibility to Seb (improved,
nio based support for TCP), so let me know what you think of it.

At the moment I'm talking with Sebastien to get more details about this
temporary task. I will come back soon with my ideas about it.

Cheers
Dilshan

#4

Dilshan Kanchana wrote:

Hi Emil and all !

    I was wondering whether there was a particular reason/problem that made
    you put the levels on top and not below the image as Yana suggested.
    Don't hesitate to let us know in case you are having trouble placing
    them underneath the image.

In fact, I tried a lot to do this. And at last I was successful. I just
committed the code. Here is a screen shot of call dialog after the
change has been done.
http://img193.imageshack.us/img193/9393/sli.jpg

Excellent!

I'm glad to start creating a UI for the conference in the way Yana
suggested.

Cool! We are all happy then.

    This means that you can either concentrate on the conferencing UI or
    take another temporary task. I suggested a possibility to Seb (improved,
    nio based support for TCP), so let me know what you think of it.

At the moment I'm talking with Sebastien to get more details about this
temporary task. I will come back soon with my ideas about it.

Here's what this is about. When using TCP (i.e. when creating a TCP
listening point) jain-sip initializes a ServerSocket and binds it to a
port that we specify. It is then able to accept connections on that
port. The trouble is that since the Java ServerSocket does not allow
initiating outbound connections all requests destined to the server
would then leave from another socket. This is especially problematic in
the presence of firewalls or NATs since no packet is ever going to leave
through the port of our ListeningPoint and hence the NAT/firewall is
never going to allow one from the server to come in.

One way to fix this would be to play with the socket factory and try to
make the ServerSocket share a channel with the client one.

Let me know what you think.

Cheers
Emil

P.S. I am also CCing Ranga in case he would like to share some insight.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#5

Hi !

Here's what this is about. When using TCP (i.e. when creating a TCP
listening point) jain-sip initializes a ServerSocket and binds it to a
port that we specify. It is then able to accept connections on that
port. The trouble is that since the Java ServerSocket does not allow
initiating outbound connections all requests destined to the server
would then leave from another socket. This is especially problematic in
the presence of firewalls or NATs since no packet is ever going to leave
through the port of our ListeningPoint and hence the NAT/firewall is
never going to allow one from the server to come in.

One way to fix this would be to play with the socket factory and try to
make the ServerSocket share a channel with the client one.

Ok. I think I got the problem in here. But I'm bit confused about the
solution. It may be because I'm not much comfortable with Jain-Sip yet.
Please correct me if I have got something wrong here.

First thing that came to my mind is why not Jain-Sip has already fixed this
issue. I think all this problem is because of the architecture of Jain-Sip.

Next thing is, even we fixed the issue by making the ServerSocket share a
channel with the client one, will that enable us to get messages directly to
our ListeningPoint? I dont think so as we are doing it inside the firewall.

And I'm also not clear about the purpose of having a ListeningPoint in our
application which really can't listen to anything directly.

Can you please help me to clear my doubts?

Also, I was wondering where to look for the related classes in the SC code.
I think it is in the net.java.sip.communicator.impl.protocol.sip package. I
guessed it is the SipStackSharing class mainly. Is this correct?

Cheers
Dilshan.

#6

Hi Dilshan, all,

First thing that came to my mind is why not Jain-Sip has already fixed
this issue. I think all this problem is because of the architecture
of Jain-Sip.

The task would precisely be to add this feature to JAIN SIP.

Next thing is, even we fixed the issue by making the ServerSocket
share a channel with the client one, will that enable us to get
messages directly to our ListeningPoint?

Yes.

I dont think so as we are doing it inside the firewall.

We're speaking about a NAT device which requires the connection to be
established from its inner side.

And I'm also not clear about the purpose of having a ListeningPoint in our
application which really can't listen to anything directly.

It can, but to keep the NAT binding alive, we need to be able to
generate traffic from the same port we listen on (what we already do
with UDP).

Also, I was wondering where to look for the related classes in the SC
code. I think it is in the
net.java.sip.communicator.impl.protocol.sip package. I guessed it is
the SipStackSharing class mainly. Is this correct?

The change would have to be made in JAIN-SIP, not in SIP Communicator
(but SC would directly benefit from it).

Cheers,

···

On Wed, Jul 15, 2009 at 03:43:43PM +0530, Dilshan Kanchana wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net