[sip-comm-dev] Conference calls with SIP


#1

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on the
target features (e.g., Audio, and maybe Video, visual idnetification of
the speaker as in Skype), all involved RFCs, and ways of implementation
in our architecture.

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


#2

ACK. I think the idea of collaborating on the conferencing is absolutely great!

I'm currently working on fine-tuning the video support and I expect it to take this and next week because there're numerous issues I want to look into while the related functionality is fresh in my mind. Anyway, we could start the brianstorming in the meantime.

Best regards,
Lubo

Emil Ivov wrote:

···

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on the
target features (e.g., Audio, and maybe Video, visual idnetification of
the speaker as in Skype), all involved RFCs, and ways of implementation
in our architecture.

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

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


#3

All,

regarding "conference call": a 3-way conference call or a multi-way
conference call?

Implementing a 3-way would be nice, at least for audio - needs a
second SIP session and a second set of RTP/SRTP session - even
works using ZRTP if all participating parties support ZRTP and
SC is the "conference bridge".

Multi-way conferencing: IMHO this would be too much - because
the algorithms to mix the audio streams are fairly complex (there
are several algos known and in use). Also this topic is addressed
in projects at java.net (and associated sites). You may have a look
here:
<http://research.sun.com/projects/mc/confmgr.html>

and here:
<https://jvoicebridge.dev.java.net/>

Ideas? Thoughts?

Regards,
Werner

Lubomir Marinov schrieb:

···

ACK. I think the idea of collaborating on the conferencing is absolutely
great!

I'm currently working on fine-tuning the video support and I expect it
to take this and next week because there're numerous issues I want to
look into while the related functionality is fresh in my mind. Anyway,
we could start the brianstorming in the meantime.

Best regards,
Lubo

Emil Ivov wrote:

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on the
target features (e.g., Audio, and maybe Video, visual idnetification of
the speaker as in Skype), all involved RFCs, and ways of implementation
in our architecture.

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

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

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


#4

Hey Werner,

Werner Dittmann wrote:

All,

regarding "conference call": a 3-way conference call or a multi-way
conference call?

Implementing a 3-way would be nice, at least for audio

Guess that would be a good start indeed and hence a first milestone.

needs a
second SIP session and a second set of RTP/SRTP session - even
works using ZRTP if all participating parties support ZRTP and
SC is the "conference bridge".

Multi-way conferencing: IMHO this would be too much - because
the algorithms to mix the audio streams are fairly complex

It would all depend on the effort it takes to get to the first milestone
but I am not certain we should stop there. I agree it would not be
trivial but I feel it's quite important to us. From a purely user
perspective, if we are to become a viable Skype alternative (which in
many ways we already are) we'd need to be able to offer support for at
least what you already have with there. Audio multi conferencing is
arguably one of its most popular features.

(there
are several algos known and in use). Also this topic is addressed
in projects at java.net (and associated sites). You may have a look
here:
<http://research.sun.com/projects/mc/confmgr.html>

and here:
<https://jvoicebridge.dev.java.net/>

As a matter of fact we did discuss the possibility of using jvoicebridge
inside SIP Communicator when I met Nicole, Joe, and Jon in Boston. (I am
CCing them in case they would like to offer comments/insight). I
remember that back at the time I was stunned by how well their bridge
worked, so I'd be very happy if we could integrate parts that would be
relevant to a conferencing feature in SC.

Cheers
Emil

···

Ideas? Thoughts?

Regards,
Werner

Lubomir Marinov schrieb:

ACK. I think the idea of collaborating on the conferencing is absolutely
great!

I'm currently working on fine-tuning the video support and I expect it
to take this and next week because there're numerous issues I want to
look into while the related functionality is fresh in my mind. Anyway,
we could start the brianstorming in the meantime.

Best regards,
Lubo

Emil Ivov wrote:

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on the
target features (e.g., Audio, and maybe Video, visual idnetification of
the speaker as in Skype), all involved RFCs, and ways of implementation
in our architecture.

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

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

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

---------------------------------------------------------------------
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 Werner, All,

As a user I find that 3/4/5/6 way Skype audio conferencing is very useful.
Starting with 3-way is already a large step and will satisfy many demands.
Worry about multi-way later, 3-way is good enough for now.

One other point to consider is many-point *broadcasting*, e.g. 1 to many.
I wish to convey my ideas to a group of people. I talk to a group of 10
to 20 people, who can only listen. I have participated in such broadcasts
and most people thought positive about this way of communicating. If
this can be realized easily, it is a possibility to consider. If it is difficult to
implement, then forget it. This is NOT a priority item, it can wait.

As far as video conferencing goes, I find that no matter which USB Webcam
or computer that I use, the CPU load goes to 100%, even just looking at
a local test window. This is not surprising since in contrast to Firewire,
USB is a dumb protocol in order to manufacture cheap devices. All the
muscle must be delivered by the CPU. Therefore 2- or 3-way video
conferencing is the maximum to be considered. Also connection bandwidth
is limited for many people due to distance to DSLAM.
Also, just receiving a Skype video call with no cam on my side takes 70%
CPU load.

Regards, Earl

Emil Ivov wrote:

···

Hey Werner,

Werner Dittmann wrote:
  

All,

regarding "conference call": a 3-way conference call or a multi-way
conference call?

Implementing a 3-way would be nice, at least for audio
    
Guess that would be a good start indeed and hence a first milestone.

needs a
second SIP session and a second set of RTP/SRTP session - even
works using ZRTP if all participating parties support ZRTP and
SC is the "conference bridge".

Multi-way conferencing: IMHO this would be too much - because
the algorithms to mix the audio streams are fairly complex
    
It would all depend on the effort it takes to get to the first milestone
but I am not certain we should stop there. I agree it would not be
trivial but I feel it's quite important to us. From a purely user
perspective, if we are to become a viable Skype alternative (which in
many ways we already are) we'd need to be able to offer support for at
least what you already have with there. Audio multi conferencing is
arguably one of its most popular features.

(there
are several algos known and in use). Also this topic is addressed
in projects at java.net (and associated sites). You may have a look
here:
<http://research.sun.com/projects/mc/confmgr.html>

and here:
<https://jvoicebridge.dev.java.net/>
    
As a matter of fact we did discuss the possibility of using jvoicebridge
inside SIP Communicator when I met Nicole, Joe, and Jon in Boston. (I am
CCing them in case they would like to offer comments/insight). I
remember that back at the time I was stunned by how well their bridge
worked, so I'd be very happy if we could integrate parts that would be
relevant to a conferencing feature in SC.

Cheers
Emil

Ideas? Thoughts?

Regards,
Werner

Lubomir Marinov schrieb:
    

ACK. I think the idea of collaborating on the conferencing is absolutely
great!

I'm currently working on fine-tuning the video support and I expect it
to take this and next week because there're numerous issues I want to
look into while the related functionality is fresh in my mind. Anyway,
we could start the brianstorming in the meantime.

Best regards,
Lubo

Emil Ivov wrote:
      

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on the
target features (e.g., Audio, and maybe Video, visual idnetification of
the speaker as in Skype), all involved RFCs, and ways of implementation
in our architecture.

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


#6

Hi guys,

If I had to start implementing conferencing, I'd prefer to begin with a simple case and then enhance it i.e. I'd rather vote for 3-way for now.

However, it seems very limited to me to have only 3-way. For what it's worth, we were a bunch of roughly 10 SIP Communicator contributers at this year's FOSDEM and I'm not quite sure how we could find 3-way sufficient to collaborate.

Could you please share some more information on the differences between 3-way and multi-way conferencing from the point of the difficulty levels of implementing either of them? While I understand I could google the answer, I think it will be quite useful for any future contributer following this thread to have the answer here.

Thank you,
Lubo

Earl wrote:

···

Hi Werner, All,

As a user I find that 3/4/5/6 way Skype audio conferencing is very useful.
Starting with 3-way is already a large step and will satisfy many demands.
Worry about multi-way later, 3-way is good enough for now.

One other point to consider is many-point *broadcasting*, e.g. 1 to many.
I wish to convey my ideas to a group of people. I talk to a group of 10
to 20 people, who can only listen. I have participated in such broadcasts
and most people thought positive about this way of communicating. If
this can be realized easily, it is a possibility to consider. If it is difficult to
implement, then forget it. This is NOT a priority item, it can wait.

As far as video conferencing goes, I find that no matter which USB Webcam
or computer that I use, the CPU load goes to 100%, even just looking at
a local test window. This is not surprising since in contrast to Firewire,
USB is a dumb protocol in order to manufacture cheap devices. All the
muscle must be delivered by the CPU. Therefore 2- or 3-way video
conferencing is the maximum to be considered. Also connection bandwidth
is limited for many people due to distance to DSLAM.
Also, just receiving a Skype video call with no cam on my side takes 70%
CPU load.

Regards, Earl

Emil Ivov wrote:

Hey Werner,

Werner Dittmann wrote:

All,

regarding "conference call": a 3-way conference call or a multi-way
conference call?

Implementing a 3-way would be nice, at least for audio

Guess that would be a good start indeed and hence a first milestone.

needs a
second SIP session and a second set of RTP/SRTP session - even
works using ZRTP if all participating parties support ZRTP and
SC is the "conference bridge".

Multi-way conferencing: IMHO this would be too much - because
the algorithms to mix the audio streams are fairly complex

It would all depend on the effort it takes to get to the first milestone
but I am not certain we should stop there. I agree it would not be
trivial but I feel it's quite important to us. From a purely user
perspective, if we are to become a viable Skype alternative (which in
many ways we already are) we'd need to be able to offer support for at
least what you already have with there. Audio multi conferencing is
arguably one of its most popular features.

(there
are several algos known and in use). Also this topic is addressed
in projects at java.net (and associated sites). You may have a look
here:
<http://research.sun.com/projects/mc/confmgr.html>

and here:
<https://jvoicebridge.dev.java.net/>
    
As a matter of fact we did discuss the possibility of using jvoicebridge
inside SIP Communicator when I met Nicole, Joe, and Jon in Boston. (I am
CCing them in case they would like to offer comments/insight). I
remember that back at the time I was stunned by how well their bridge
worked, so I'd be very happy if we could integrate parts that would be
relevant to a conferencing feature in SC.

Cheers
Emil

Ideas? Thoughts?

Regards,
Werner

Lubomir Marinov schrieb:
   

ACK. I think the idea of collaborating on the conferencing is absolutely
great!

I'm currently working on fine-tuning the video support and I expect it
to take this and next week because there're numerous issues I want to
look into while the related functionality is fresh in my mind. Anyway,
we could start the brianstorming in the meantime.

Best regards,
Lubo

Emil Ivov wrote:
     

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on the
target features (e.g., Audio, and maybe Video, visual idnetification of
the speaker as in Skype), all involved RFCs, and ways of implementation
in our architecture.

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

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


#7

Hi all,

Though i was reading the thread throughout, i felt reluctant to write on to
it because i was quite new to it. Meanwhile I read about it in several
articles.

On my personal opinion, I think it is good to design the architecture so as
we can support multi-way video conferencing one day through SC; without
totally changing the design and the architecture to move from 3-way to
multi-way.

Following I mention some of the ideas I came across while searching on this
topic,(well.., they may not help directly to design the architecture for
secure video conferencing in the context of SC.)

A Framework for Conferencing with the Session Initiation Protocol
(SIP),which is an internet draft; defines a framework for communication
sessions with multiple participants.

(You can read it here:
http://www.jdrosen.net/papers/draft-ietf-sipping-conferencing-framework-01.html
)

For the convenience, I have copied the following section form the above
linked document
Overview of Conferencing Architecture

multimediaConferencing_webService.pdf (833 KB)

···

+-----------+

                           > >

                           > >

                           >Participant>

                           > 4 |

                           > >

                           +-----------+

                                 >

                                 >SIP

                                 >Dialog

                                 >4

                                 >

   +-----------+ +-----------+ +-----------+

   > > > > > >

   > > > > > >

   >Participant>-----------| Focus |------------|Participant|

   > 1 | SIP | | SIP | 3 |

   > > Dialog | | Dialog | |

   +-----------+ 1 +-----------+ 3 +-----------+

                                 >

                                 >

                                 >SIP

                                 >Dialog

                                 >2

                                 >

                           +-----------+

                           > >

                           > >

                           >Participant>

                           > 2 |

                           > >

                           +-----------+

The central component (literally) in a SIP conference is the focus. The
focus maintains a SIP signaling relationship with each participant in the
conference. The result is a star topology, shown in Figure.

The focus is responsible for making sure that the media streams which
constitute the conference are available to the participants in the
conference. It does that through the use of one or more mixers, each of
which combines a number of input media streams to produce one or more output
media streams. The focus uses the media policy to determine the proper
configuration of the mixers.

The focus has access to the conference policy (composed of the membership
and media policies), an instance of which exist for each conference.
Effectively, the conference policy can be thought of as a database which
describes the way that the conference should operate. It is the
responsibility of the focus to enforce those policies. Not only does the
focus need read access to the database, but it needs to know when it has
changed. Such changes might result in SIP signaling (for example, the
ejection of a user from the conference using BYE), and most changes will
require a notification to be sent to subscribers using the conference
notification service.

The conference is represented by a URI, which identifies the focus. Each
conference has a unique focus and a unique URI identifying that focus.
Requests to the conference URI are routed to the focus for that specific
conference.

Users usually join the conference by sending an INVITE to the conference
URI. As long as the conference policy allows, the INVITE is accepted by the
focus and the user is brought into the conference. Users can leave the
conference by sending a BYE, as they would in a normal call.

Similarly, the focus can terminate a dialog with a participant, should the
conference policy change to indicate that the participant is no longer
allowed in the conference. A focus can also initiate an INVITE, should the
conference policy indicate that the focus needs to bring a participant into
the conference.

One thing to note is that above link directs to an internet draft, which
might be obsolete or replaced by now.

http://www.ietf.org/rfc/rfc4579.txt, is an RFC titled: Session Initiation
Protocol (SIP) Call Control -Conferencing for User Agents, which will be
helpful for us and which I think, is written using the above mentioned
internet draft as well. I will find out further whether a replacement for
that, is currently issued by IETF.

I came across several implementations of multimedia conferencing which I
thought would be helpful in deciding a suitable architecture for
conferencing in SC.

The first attachment to this mail, describes the multimedia conferencing web
service aspect of OSA-which defines an architecture that enables application
developers to make use of network functionality through an open standard
interface.

I felt, if we develop a web service like that and make the web service
client, a service of SC, we may be able to achieve conferencing as described
in it. I am afraid, it is a very abstract kind of idea, I still have no idea
whether it can conflict with the session management concept presented in
SIP.

Also, following are some ideas I gained by reading at:
http://www.vidyo.com/new_standard.html .

   - It would be good if SC client is made intelligent to do necessary
   arrangements to accommodate local resources such as processing power,
   bandwidth and screen resolution available to the endpoint SC is installed
   in, so that each participant in the conference experiences the very best
   they are capable of.
   - Since the processing power and bandwidth is dynamic, it would be great
   if SC test and recalibrate so that client is provided with the highest
   quality video it is capable of receiving.
   - Also I read there that there is an extension to the H.264 encoding,
   which we can think of using for video conferencing. It is SVC (Scalable
   Video Coding) extension to H.264. It is said that it provides high quality
   video at relatively low transmission bit rates-thus eliminating need for
   dedicated lines.

Well, those are few ideas and facts I came across while searching on this
topic and which I felt; would be relevant with regard to SC's implementation
of conferencing.

Please feel free to criticize about them because I am in the learning curve
and there may be lot of things I might have not seen.

Meanwhile, I would read more about it too and update the thread.

Thank you Emil for starting the thread and I look forward to see an exciting
brain storming session on this, as Lubomir too has mentioned.

Best regards,

Hasini.

On Fri, Feb 13, 2009 at 9:24 PM, Lubomir Marinov <lubomir.marinov@gmail.com>wrote:

Hi guys,

If I had to start implementing conferencing, I'd prefer to begin with a
simple case and then enhance it i.e. I'd rather vote for 3-way for now.

However, it seems very limited to me to have only 3-way. For what it's
worth, we were a bunch of roughly 10 SIP Communicator contributers at this
year's FOSDEM and I'm not quite sure how we could find 3-way sufficient to
collaborate.

Could you please share some more information on the differences between
3-way and multi-way conferencing from the point of the difficulty levels of
implementing either of them? While I understand I could google the answer, I
think it will be quite useful for any future contributer following this
thread to have the answer here.

Thank you,
Lubo

Earl wrote:

Hi Werner, All,

As a user I find that 3/4/5/6 way Skype audio conferencing is very useful.
Starting with 3-way is already a large step and will satisfy many demands.
Worry about multi-way later, 3-way is good enough for now.

One other point to consider is many-point *broadcasting*, e.g. 1 to many.
I wish to convey my ideas to a group of people. I talk to a group of 10
to 20 people, who can only listen. I have participated in such broadcasts
and most people thought positive about this way of communicating. If
this can be realized easily, it is a possibility to consider. If it is
difficult to
implement, then forget it. This is NOT a priority item, it can wait.

As far as video conferencing goes, I find that no matter which USB Webcam
or computer that I use, the CPU load goes to 100%, even just looking at
a local test window. This is not surprising since in contrast to
Firewire,
USB is a dumb protocol in order to manufacture cheap devices. All the
muscle must be delivered by the CPU. Therefore 2- or 3-way video
conferencing is the maximum to be considered. Also connection bandwidth
is limited for many people due to distance to DSLAM.
Also, just receiving a Skype video call with no cam on my side takes 70%
CPU load.

Regards, Earl

Emil Ivov wrote:

Hey Werner,

Werner Dittmann wrote:

All,

regarding "conference call": a 3-way conference call or a multi-way
conference call?

Implementing a 3-way would be nice, at least for audio

Guess that would be a good start indeed and hence a first milestone.

needs a
second SIP session and a second set of RTP/SRTP session - even
works using ZRTP if all participating parties support ZRTP and
SC is the "conference bridge".

Multi-way conferencing: IMHO this would be too much - because
the algorithms to mix the audio streams are fairly complex

It would all depend on the effort it takes to get to the first milestone
but I am not certain we should stop there. I agree it would not be
trivial but I feel it's quite important to us. From a purely user
perspective, if we are to become a viable Skype alternative (which in
many ways we already are) we'd need to be able to offer support for at
least what you already have with there. Audio multi conferencing is
arguably one of its most popular features.

(there
are several algos known and in use). Also this topic is addressed
in projects at java.net (and associated sites). You may have a look
here:
<http://research.sun.com/projects/mc/confmgr.html>

and here:
<https://jvoicebridge.dev.java.net/>

As a matter of fact we did discuss the possibility of using jvoicebridge
inside SIP Communicator when I met Nicole, Joe, and Jon in Boston. (I am
CCing them in case they would like to offer comments/insight). I
remember that back at the time I was stunned by how well their bridge
worked, so I'd be very happy if we could integrate parts that would be
relevant to a conferencing feature in SC.

Cheers
Emil

Ideas? Thoughts?

Regards,
Werner

Lubomir Marinov schrieb:

ACK. I think the idea of collaborating on the conferencing is
absolutely
great!

I'm currently working on fine-tuning the video support and I expect it
to take this and next week because there're numerous issues I want to
look into while the related functionality is fresh in my mind. Anyway,
we could start the brianstorming in the meantime.

Best regards,
Lubo

Emil Ivov wrote:

Hey all,

There have been a few mails on this list from people (Dmitry and
Hasini)claiming interest in the development of support for conference
calls in SIP Communicator. I already mentioned that Lubomir has
planned
to work on that but it would probably be wiser if we joined forces.

If you agrees (please ack) we could then start with a discussion on
the
target features (e.g., Audio, and maybe Video, visual idnetification
of
the speaker as in Skype), all involved RFCs, and ways of
implementation
in our architecture.

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

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


#8

Hi,

When you build an installation, the run.exe file seems to be copied over
completely and it is what is starts to run the installation. My problem
is that run.exe sets the classpath. I need to add a jar (i.e.
mysql-connector-java-5.0.8-bin.jar) to this path.

At the moment I actually do a binary edit of run.exe to accomplish this.
Can someone tell me that correct way to add jars to the installation?

thanks, Kim

···

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


#9

Hi all,

I went through the GSoC 2009 ideas list and found that the idea about
implementing SIP conferencing functionality is not included there although
it was discussed in the dev list. Actually i am a student interested in
contributing to SIP Communicator in GSoC 2009. Also i was pretty interested
in looking in to SIP conferencing wth SC.

So could i please know whether it is not supposed for a GSoC participant to
apply on SIP Conferencing with SC?
Of course, I found some of the ideas that are already published in 2009
list, too interest me very much. But I would like to get to know whether
implementing sip conferencing is not in the scope of GSoC particpants; so
that i can look in to some other idea which i would like to work with SC in
GSoC.

Thank you.
Best Regards,
Hasini.


#10

Hey Kim,

Kim Michael Fairchild wrote:

Hi,

When you build an installation, the run.exe file seems to be copied over
completely and it is what is starts to run the installation. My problem
is that run.exe sets the classpath. I need to add a jar (i.e.
mysql-connector-java-5.0.8-bin.jar) to this path.

At the moment I actually do a binary edit of run.exe to accomplish this.
Can someone tell me that correct way to add jars to the installation?

You could create a bundle with your extension classes and include the
content of your mysql jar in there. This way you would only need to
modify felix.client.run.properties and make it start your bundle.

Alternately, you would need to modify the run.exe.jsmooth and add the
lib there. You would then have to regenerate run.exe. Note that in this
case you would also need to make the modifications in the sh files for
the other platform specific installers.

Hope this helps
Emil

···

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


#11

Hello Hasini,

Hasini Gunasinghe wrote:

Hi all,

I went through the GSoC 2009 ideas list and found that the idea about
implementing SIP conferencing functionality is not included there
although it was discussed in the dev list.

First, note that Google has not yet announced the list of accepted
organizations, so as of now there's no guarantee that we (or anyone else
for that matter) would be a part of the program this year.

Actually i am a student
interested in contributing to SIP Communicator in GSoC 2009. Also i was
pretty interested in looking in to SIP conferencing wth SC.

Yes, indeed, we thought that the development of the feature is quite
complex so we've decided to only post a simple part of it: the sound
level indicator:

http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

We were thinking that the rest would be better taken care of by core
experienced SIP Communicator developers. If you feel, however, that you
could handle it by yourself you could still propose the idea (again,
provided we are accepted for participation). If you decide to go this
way then you'd have to convince us that you are really capable of
carrying the task through to the end.

Hope this clears it out.

Cheers
Emil

···

So could i please know whether it is not supposed for a GSoC participant
to apply on SIP Conferencing with SC?
Of course, I found some of the ideas that are already published in 2009
list, too interest me very much. But I would like to get to know whether
implementing sip conferencing is not in the scope of GSoC particpants;
so that i can look in to some other idea which i would like to work with
SC in GSoC.

Thank you.
Best Regards,
Hasini.

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


#12

Emil Ivov wrote:

Thanks, I hadn't thought of creating a bundle for it. But I think I will
regenerate the run.exe first as it seems simpler to modify run.exe.jsmooth.

Can you tell me how I regenerate run.exe (under windows)?

I am embarrassed to ask this question now. Somehow I broke the installer
when trying to get this to work. I have gone back to backups but I still
get the same odd error. It seems that something in my Vista environment
has changed. I get this error message after the installer executes:

The jar-file "sip-communicator-windows.jar" could not be executed. (from
Izpack-launcher).

Any idea what this is? I thought that it might be the association for
the jar file but my other jar files open okay under windows file
explorer. I tried switching java, etc.

thanks, Kim

···

Hey Kim,

Kim Michael Fairchild wrote:
  

Hi,

When you build an installation, the run.exe file seems to be copied over
completely and it is what is starts to run the installation. My problem
is that run.exe sets the classpath. I need to add a jar (i.e.
mysql-connector-java-5.0.8-bin.jar) to this path.

At the moment I actually do a binary edit of run.exe to accomplish this.
Can someone tell me that correct way to add jars to the installation?
    
You could create a bundle with your extension classes and include the
content of your mysql jar in there. This way you would only need to
modify felix.client.run.properties and make it start your bundle.

Alternately, you would need to modify the run.exe.jsmooth and add the
lib there. You would then have to regenerate run.exe. Note that in this
case you would also need to make the modifications in the sh files for
the other platform specific installers.

Hope this helps
Emil

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

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


#13

Hi Kim,

Can you tell me how I regenerate run.exe (under windows)?

http://www.google.com/search?q=jsmooth should point you to the
application used to regenerate run.exe and its manual.

The jar-file "sip-communicator-windows.jar" could not be executed. (from
Izpack-launcher).

The IzPack-based Windows installer doesn't handle uninstallation
correctly so it's quite possible it malfunctions in other ways as
well. The MSI/WiX-based one is the newer and the preferred on Windows
so I'd suggest trying to work with it instead of the IzPack version.

Regards,
Lubo

···

On Fri, Feb 27, 2009 at 8:43 AM, Kim Michael Fairchild <ting4@ljade.com> wrote:

Emil Ivov wrote:

Thanks, I hadn't thought of creating a bundle for it. But I think I will
regenerate the run.exe first as it seems simpler to modify run.exe.jsmooth.

Can you tell me how I regenerate run.exe (under windows)?

I am embarrassed to ask this question now. Somehow I broke the installer
when trying to get this to work. I have gone back to backups but I still
get the same odd error. It seems that something in my Vista environment
has changed. I get this error message after the installer executes:

The jar-file "sip-communicator-windows.jar" could not be executed. (from
Izpack-launcher).

Any idea what this is? I thought that it might be the association for
the jar file but my other jar files open okay under windows file
explorer. I tried switching java, etc.

thanks, Kim

Hey Kim,

Kim Michael Fairchild wrote:

Hi,

When you build an installation, the run.exe file seems to be copied over
completely and it is what is starts to run the installation. My problem
is that run.exe sets the classpath. I need to add a jar (i.e.
mysql-connector-java-5.0.8-bin.jar) to this path.

At the moment I actually do a binary edit of run.exe to accomplish this.
Can someone tell me that correct way to add jars to the installation?

You could create a bundle with your extension classes and include the
content of your mysql jar in there. This way you would only need to
modify felix.client.run.properties and make it start your bundle.

Alternately, you would need to modify the run.exe.jsmooth and add the
lib there. You would then have to regenerate run.exe. Note that in this
case you would also need to make the modifications in the sh files for
the other platform specific installers.

Hope this helps
Emil

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

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

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


#14

FYI, I am also working on visualization, but on SWT. We will use inbound and
outbound RTP graphs for debugging in eclipse
http://img26.imageshack.us/img26/4985/screenshotjavaeclipsesd.png (the app
is based on a reduced version of sip communicator).

···

On Thu, Mar 12, 2009 at 1:04 PM, Emil Ivov <emcho@sip-communicator.org>wrote:

Hello Hasini,

Hasini Gunasinghe wrote:
> Hi all,
>
> I went through the GSoC 2009 ideas list and found that the idea about
> implementing SIP conferencing functionality is not included there
> although it was discussed in the dev list.

First, note that Google has not yet announced the list of accepted
organizations, so as of now there's no guarantee that we (or anyone else
for that matter) would be a part of the program this year.

> Actually i am a student
> interested in contributing to SIP Communicator in GSoC 2009. Also i was
> pretty interested in looking in to SIP conferencing wth SC.

Yes, indeed, we thought that the development of the feature is quite
complex so we've decided to only post a simple part of it: the sound
level indicator:

http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

We were thinking that the rest would be better taken care of by core
experienced SIP Communicator developers. If you feel, however, that you
could handle it by yourself you could still propose the idea (again,
provided we are accepted for participation). If you decide to go this
way then you'd have to convince us that you are really capable of
carrying the task through to the end.

Hope this clears it out.

Cheers
Emil

> So could i please know whether it is not supposed for a GSoC participant
> to apply on SIP Conferencing with SC?
> Of course, I found some of the ideas that are already published in 2009
> list, too interest me very much. But I would like to get to know whether
> implementing sip conferencing is not in the scope of GSoC particpants;
> so that i can look in to some other idea which i would like to work with
> SC in GSoC.
>
>
> Thank you.
> Best Regards,
> Hasini.
>
>
>

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


#15

Hello Hasini,

Hi all,

Hasini Gunasinghe wrote:
> Hi all,
>
> I went through the GSoC 2009 ideas list and found that the idea about
> implementing SIP conferencing functionality is not included there
> although it was discussed in the dev list.

First, note that Google has not yet announced the list of accepted
organizations, so as of now there's no guarantee that we (or anyone else
for that matter) would be a part of the program this year.

> Actually i am a student
> interested in contributing to SIP Communicator in GSoC 2009. Also i was
> pretty interested in looking in to SIP conferencing wth SC.

Yes, indeed, we thought that the development of the feature is quite
complex so we've decided to only post a simple part of it: the sound
level indicator:

http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

We were thinking that the rest would be better taken care of by core
experienced SIP Communicator developers. If you feel, however, that you
could handle it by yourself you could still propose the idea (again,
provided we are accepted for participation). If you decide to go this
way then you'd have to convince us that you are really capable of
carrying the task through to the end.

I too owe the fact that conferencing would be a complex task to be totally
handled by myself because I am new to both conferencing in SIP and Sip
Communicator itself. But I thought of giving it a try before giving up since
I am very much interested in. So if the community would agree upon a
suitable architecture for conferencing in SIP for SC, before the application
process ends, I hope I would be able to submit a proposal to carry out a
particular part of it.

Following I mention a summary of what I read about the subject and my
suggestions for implementing conferencing with regard to SC. If you all
could please give feed back on this, it would be a valuable guidance for me.

The main refference to the following section of my mail is the fisrt pdf
that I have attached.(It is a good article on basics of conferencing.)
There are several basics tasks to be achieved in conferencing:

1).Signalling: such as INVITE for a conference, leave a conference, expel
participants and configure media streams.
                  possible approaches: centralized(bridge or endpoint) and
mesh
                  I suggest end point implementation of centralized approach
for SC.
2).Media mixing and distribution:
                  same approaches as above are available but I suggest end
point centralized approach for SC, because although it makes SC complicated
when it acts as the focus, the other participants may but not necessarily
support conferencing.
3). Conference Creation:
                  possible approaches: ad-hoc, scheduled, dial in, dial out.
                  First I felt ad-hoc would be good because it allows invite
further participants but I found it is mentioned that it can join only a
limited number of participants. Thus scheduled approach would be preferable
where the focus call out to a list of participants and the participants call
in to a conference URL representing the focus.

When looking for the possible implementations, I found that web service(SIP
SOA) could be one option. My concern about it is, if we implement
conferencing in the bridge type of centralized approach that is mentioned
above, it would be feasible. But when it comes to the end point centralized
approach which I think is suitable for SC, will it be a possible thing?
because according to my basic knowledge of webservices, it should be hosted
in a server. If so we'd have to use a server like glass fish along with the
SC installation.

Anyway when looking for a solution which goes with the above idea, I found
an open source project called SailFin which develop a container for SIP
Servlets. Following is a link:
http://java.dzone.com/news/sailfin-when-java-ee-met-sip.

Though I still do not have a clear picture of what would be the best suited
implementation and tools with regard to conferencing in SC, I thought of
posting to the thread what I found, my suggestons and possible
implementations as I see, so that upon your feed back, suggestion and
guidance I hope I would be able to proceed well.

Also, if it is not feasible to implement the whole conferencing
functionality alone during the time limt, may I ask would I be able to
propose to implement a specific part of it? such as some specific logc in
the focus, filtergraph for media mixing and rendering in focus or some other
related part which I hope I would be able to propose more specifically upon
widening my knowledge on this.

Hope this clears it out.

Cheers
Emil

Thank you very much.
regards,
Hasini.

sip-conferencing.pdf (158 KB)

···

On Thu, Mar 12, 2009 at 7:04 PM, Emil Ivov <emcho@sip-communicator.org>wrote:

> So could i please know whether it is not supposed for a GSoC participant
> to apply on SIP Conferencing with SC?
> Of course, I found some of the ideas that are already published in 2009
> list, too interest me very much. But I would like to get to know whether
> implementing sip conferencing is not in the scope of GSoC particpants;
> so that i can look in to some other idea which i would like to work with
> SC in GSoC.
>
>
> Thank you.
> Best Regards,
> Hasini.
>
>
>

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


#16

Server side conferencing is of course best for most users. Client side
conferencing is not very common in SIP phones, but it certainly helped Skype
and MSN. Also, about server-side conferencing, not that SailFin is a bad
server, but it's not suited to do conferencing or media very well. I would
recommend the Mobicents Sip Servlets/Media Server solution as it offers the
Media part and the API out of the box. You can read more about conferencing
with Mobicetns here:
http://vladimirralev.blogspot.com/2009/02/rich-telco-applications-with-seam.html
http://vladimirralev.blogspot.com/2008/10/conference-demo-for-sip-servlets.html

···

On Mon, Mar 16, 2009 at 11:16 PM, Hasini Gunasinghe <hasi7786@gmail.com>wrote:

Anyway when looking for a solution which goes with the above idea, I found
an open source project called SailFin which develop a container for SIP
Servlets. Following is a link:
http://java.dzone.com/news/sailfin-when-java-ee-met-sip.

Though I still do not have a clear picture of what would be the best suited
implementation and tools with regard to conferencing in SC, I thought of
posting to the thread what I found, my suggestons and possible
implementations as I see, so that upon your feed back, suggestion and
guidance I hope I would be able to proceed well.


#17

Hey Hasini,

Hasini Gunasinghe wrote:

    Hello Hasini,

Hi all,

    Hasini Gunasinghe wrote:
    > Hi all,
    >
    > I went through the GSoC 2009 ideas list and found that the idea about
    > implementing SIP conferencing functionality is not included there
    > although it was discussed in the dev list.

    First, note that Google has not yet announced the list of accepted
    organizations, so as of now there's no guarantee that we (or anyone else
    for that matter) would be a part of the program this year.

    > Actually i am a student
    > interested in contributing to SIP Communicator in GSoC 2009. Also
    i was
    > pretty interested in looking in to SIP conferencing wth SC.

    Yes, indeed, we thought that the development of the feature is quite
    complex so we've decided to only post a simple part of it: the sound
    level indicator:

    http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

    We were thinking that the rest would be better taken care of by core
    experienced SIP Communicator developers. If you feel, however, that you
    could handle it by yourself you could still propose the idea (again,
    provided we are accepted for participation). If you decide to go this
    way then you'd have to convince us that you are really capable of
    carrying the task through to the end.

I too owe the fact that conferencing would be a complex task to be
totally handled by myself because I am new to both conferencing in SIP
and Sip Communicator itself. But I thought of giving it a try before
giving up since I am very much interested in. So if the community would
agree upon a suitable architecture for conferencing in SIP for SC,
before the application process ends, I hope I would be able to submit a
proposal to carry out a particular part of it.

I am afraid that's far too short of a deadline even for us, the core
developers, to come up with the final architecture for conferencing.

I believe I already mentioned we have related project ideas on
http://sip-communicator.org/gsoc (links below). You could start by
helping up with them. Then, once we are decided on how we are going to
handle conferencing you could still chime in and help with them. That is
of course if you are interested in doing this as a part of GSoC
(provided we get accepted). Otherwise you are most certainly free to
work on whatever you wish.

Following I mention a summary of what I read about the subject and my
suggestions for implementing conferencing with regard to SC. If you all
could please give feed back on this, it would be a valuable guidance for me.

The main refference to the following section of my mail is the fisrt pdf
that I have attached.(It is a good article on basics of conferencing.)
There are several basics tasks to be achieved in conferencing:

1).Signalling: such as INVITE for a conference, leave a conference,
expel participants and configure media streams.
                  possible approaches: centralized(bridge or endpoint)
and mesh
                  I suggest end point implementation of centralized
approach for SC.

Yes, that's the plan so far.

2).Media mixing and distribution:
                  same approaches as above are available but I suggest
end point centralized approach for SC, because although it makes SC
complicated when it acts as the focus, the other participants may but
not necessarily support conferencing.

Yup, this too is probably the way we'll be heading.

3). Conference Creation:
                  possible approaches: ad-hoc, scheduled, dial in, dial out.
                  First I felt ad-hoc would be good because it allows
invite further participants but I found it is mentioned that it can join
only a limited number of participants. Thus scheduled approach would be
preferable where the focus call out to a list of participants and the
participants call in to a conference URL representing the focus.

I am not sure I see the problem you mention about ad-hoc conferences.
This is most probably the model we will be adopting. Scheduled conf
calls make little sense for an application-hosted solution not to
mention that it would unnecessarily complicate the establishment
procedures for users.

When looking for the possible implementations, I found that web
service(SIP SOA) could be one option.

Again, I am not sure I follow. Why would we need to have web services to
handle conf calls? Conf call establishment (for an end-point hosted
scenario) could be completely handled by SIP semantics: The call creator
invites original participants. If others want to join later on they call
the host, who would take their calls and then reINVITE them to join the
conf. Makes sense?

My concern about it is, if we
implement conferencing in the bridge type of centralized approach that
is mentioned above, it would be feasible. But when it comes to the end
point centralized approach which I think is suitable for SC, will it be
a possible thing? because according to my basic knowledge of
webservices, it should be hosted in a server.

Yes, you are correct.

If so we'd have to use a server like glass fish along with the SC installation.

While we definitely need to support the use case of SC joining an RFC
compliant conf call hosted on a server like glassfish or mobicents, the
point of implementing conferencing in the client would be to make conf
calls also available to users whose servers do not support this service.

Anyway when looking for a solution which goes with the above idea, I
found an open source project called SailFin which develop a container
for SIP Servlets. Following is a link:
http://java.dzone.com/news/sailfin-when-java-ee-met-sip.

Though I still do not have a clear picture of what would be the best
suited implementation and tools with regard to conferencing in SC, I
thought of posting to the thread what I found, my suggestons and
possible implementations as I see, so that upon your feed back,
suggestion and guidance I hope I would be able to proceed well.

Also, if it is not feasible to implement the whole conferencing
functionality alone during the time limt, may I ask would I be able to
propose to implement a specific part of it? such as some specific logc
in the focus, filtergraph for media mixing and rendering in focus

You might be interested in this project idea:

http://www.sip-communicator.org/index.php/GSOC2009/FmjFiltergraph

or some other related part which I hope I would be able to propose more
specifically upon widening my knowledge on this.

The sound level indicators are also one such part:
http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

Cheers
Emil

···

On Thu, Mar 12, 2009 at 7:04 PM, Emil Ivov <emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>> wrote:

    Hope this clears it out.

    Cheers
    Emil

Thank you very much.
regards,
Hasini.

    > So could i please know whether it is not supposed for a GSoC
    participant
    > to apply on SIP Conferencing with SC?
    > Of course, I found some of the ideas that are already published in
    2009
    > list, too interest me very much. But I would like to get to know
    whether
    > implementing sip conferencing is not in the scope of GSoC particpants;
    > so that i can look in to some other idea which i would like to
    work with
    > SC in GSoC.
    >
    >
    > Thank you.
    > Best Regards,
    > Hasini.
    >
    >
    >

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

------------------------------------------------------------------------

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

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


#18

Hey Hasini,

Hi Emil,

First of all thank you very much for the reply.

Hasini Gunasinghe wrote:
>
> Hello Hasini,
>
>
> Hi all,
>
>
>
> Hasini Gunasinghe wrote:
> > Hi all,
> >
> > I went through the GSoC 2009 ideas list and found that the idea
about
> > implementing SIP conferencing functionality is not included there
> > although it was discussed in the dev list.
>
> First, note that Google has not yet announced the list of accepted
> organizations, so as of now there's no guarantee that we (or anyone
else
> for that matter) would be a part of the program this year.
>
> > Actually i am a student
> > interested in contributing to SIP Communicator in GSoC 2009. Also
> i was
> > pretty interested in looking in to SIP conferencing wth SC.
>
> Yes, indeed, we thought that the development of the feature is quite
> complex so we've decided to only post a simple part of it: the sound
> level indicator:
>
>
http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator
>
> We were thinking that the rest would be better taken care of by core
> experienced SIP Communicator developers. If you feel, however, that
you
> could handle it by yourself you could still propose the idea (again,
> provided we are accepted for participation). If you decide to go this
> way then you'd have to convince us that you are really capable of
> carrying the task through to the end.
>
>
> I too owe the fact that conferencing would be a complex task to be
> totally handled by myself because I am new to both conferencing in SIP
> and Sip Communicator itself. But I thought of giving it a try before
> giving up since I am very much interested in. So if the community would
> agree upon a suitable architecture for conferencing in SIP for SC,
> before the application process ends, I hope I would be able to submit a
> proposal to carry out a particular part of it.

I am afraid that's far too short of a deadline even for us, the core
developers, to come up with the final architecture for conferencing.

I believe I already mentioned we have related project ideas on
http://sip-communicator.org/gsoc (links below). You could start by
helping up with them. Then, once we are decided on how we are going to
handle conferencing you could still chime in and help with them. That is
of course if you are interested in doing this as a part of GSoC
(provided we get accepted). Otherwise you are most certainly free to
work on whatever you wish.

Yes, I now feel the feasible approach would be that. I will look in to
contributing to SC with another already defined idea in the list with regard
to GSoC, and of course I am looking forward to join with conference handling
in the future.

> Following I mention a summary of what I read about the subject and my
> suggestions for implementing conferencing with regard to SC. If you all
> could please give feed back on this, it would be a valuable guidance for
me.
>
> The main refference to the following section of my mail is the fisrt pdf
> that I have attached.(It is a good article on basics of conferencing.)
> There are several basics tasks to be achieved in conferencing:
>
> 1).Signalling: such as INVITE for a conference, leave a conference,
> expel participants and configure media streams.
> possible approaches: centralized(bridge or endpoint)
> and mesh
> I suggest end point implementation of centralized
> approach for SC.

Yes, that's the plan so far.

> 2).Media mixing and distribution:
> same approaches as above are available but I suggest
> end point centralized approach for SC, because although it makes SC
> complicated when it acts as the focus, the other participants may but
> not necessarily support conferencing.

Yup, this too is probably the way we'll be heading.

> 3). Conference Creation:
> possible approaches: ad-hoc, scheduled, dial in, dial
out.
> First I felt ad-hoc would be good because it allows
> invite further participants but I found it is mentioned that it can join
> only a limited number of participants. Thus scheduled approach would be
> preferable where the focus call out to a list of participants and the
> participants call in to a conference URL representing the focus.

I am not sure I see the problem you mention about ad-hoc conferences.
This is most probably the model we will be adopting. Scheduled conf
calls make little sense for an application-hosted solution not to
mention that it would unnecessarily complicate the establishment
procedures for users.

Well..I am sorry if i have not mentioned it clearly. I happened to read in
RFC 4245 section 2 :
             "The conference focus can be implemented either by a
participant or by a separate application server. In the first case, a focus
is typically capable of hosting a simple ad hoc conference only." I might
have interpreted it wrongly. After reading the logic you have described
below, I understood that the procedure we follow for adding one participant
can be used to add several as well.

When looking for the possible implementations, I found that web
> service(SIP SOA) could be one option.

Again, I am not sure I follow. Why would we need to have web services to
handle conf calls? Conf call establishment (for an end-point hosted
scenario) could be completely handled by SIP semantics: The call creator
invites original participants. If others want to join later on they call
the host, who would take their calls and then reINVITE them to join the
conf. Makes sense?

Yes, Thank you for explaining.

> My concern about it is, if we
> implement conferencing in the bridge type of centralized approach that
> is mentioned above, it would be feasible. But when it comes to the end
> point centralized approach which I think is suitable for SC, will it be
> a possible thing? because according to my basic knowledge of
> webservices, it should be hosted in a server.

Yes, you are correct.

> If so we'd have to use a server like glass fish along with the SC
installation.

While we definitely need to support the use case of SC joining an RFC
compliant conf call hosted on a server like glassfish or mobicents, the
point of implementing conferencing in the client would be to make conf
calls also available to users whose servers do not support this service.

> Anyway when looking for a solution which goes with the above idea, I
> found an open source project called SailFin which develop a container
> for SIP Servlets. Following is a link:
> http://java.dzone.com/news/sailfin-when-java-ee-met-sip.
>
> Though I still do not have a clear picture of what would be the best
> suited implementation and tools with regard to conferencing in SC, I
> thought of posting to the thread what I found, my suggestons and
> possible implementations as I see, so that upon your feed back,
> suggestion and guidance I hope I would be able to proceed well.
>
> Also, if it is not feasible to implement the whole conferencing
> functionality alone during the time limt, may I ask would I be able to
> propose to implement a specific part of it? such as some specific logc
> in the focus, filtergraph for media mixing and rendering in focus

You might be interested in this project idea:

http://www.sip-communicator.org/index.php/GSOC2009/FmjFiltergraph

Yes, I have looked in to that idea too. Thank you for pointing it out.

or some other related part which I hope I would be able to propose more
> specifically upon widening my knowledge on this.

The sound level indicators are also one such part:
http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

Cheers
Emil

Thank you.
regards,
Hasini.

···

On Wed, Mar 18, 2009 at 6:10 PM, Emil Ivov <emcho@sip-communicator.org>wrote:

> On Thu, Mar 12, 2009 at 7:04 PM, Emil Ivov <emcho@sip-communicator.org > > <mailto:emcho@sip-communicator.org>> wrote:

>
>
>
> Hope this clears it out.
>
> Cheers
> Emil
>
>
> Thank you very much.
> regards,
> Hasini.
>
>
>
>
>
> > So could i please know whether it is not supposed for a GSoC
> participant
> > to apply on SIP Conferencing with SC?
> > Of course, I found some of the ideas that are already published in
> 2009
> > list, too interest me very much. But I would like to get to know
> whether
> > implementing sip conferencing is not in the scope of GSoC
particpants;
> > so that i can look in to some other idea which i would like to
> work with
> > SC in GSoC.
> >
> >
> > Thank you.
> > Best Regards,
> > Hasini.
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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


#19

Hey Hasini,

Hasini Gunasinghe wrote:

    Hey Hasini,

Hi Emil,

First of all thank you very much for the reply.

You are most welcome.

Emil

···

On Wed, Mar 18, 2009 at 6:10 PM, Emil Ivov <emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>> wrote:

    Hasini Gunasinghe wrote:
    > On Thu, Mar 12, 2009 at 7:04 PM, Emil Ivov > <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org> > > <mailto:emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>>> wrote:
    >
    > Hello Hasini,
    >
    >
    > Hi all,
    >
    >
    >
    > Hasini Gunasinghe wrote:
    > > Hi all,
    > >
    > > I went through the GSoC 2009 ideas list and found that the
    idea about
    > > implementing SIP conferencing functionality is not included
    there
    > > although it was discussed in the dev list.
    >
    > First, note that Google has not yet announced the list of accepted
    > organizations, so as of now there's no guarantee that we (or
    anyone else
    > for that matter) would be a part of the program this year.
    >
    > > Actually i am a student
    > > interested in contributing to SIP Communicator in GSoC 2009.
    Also
    > i was
    > > pretty interested in looking in to SIP conferencing wth SC.
    >
    > Yes, indeed, we thought that the development of the feature is
    quite
    > complex so we've decided to only post a simple part of it: the
    sound
    > level indicator:
    >
    >
    http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator
    >
    > We were thinking that the rest would be better taken care of
    by core
    > experienced SIP Communicator developers. If you feel, however,
    that you
    > could handle it by yourself you could still propose the idea
    (again,
    > provided we are accepted for participation). If you decide to
    go this
    > way then you'd have to convince us that you are really capable of
    > carrying the task through to the end.
    >
    >
    > I too owe the fact that conferencing would be a complex task to be
    > totally handled by myself because I am new to both conferencing in SIP
    > and Sip Communicator itself. But I thought of giving it a try before
    > giving up since I am very much interested in. So if the community
    would
    > agree upon a suitable architecture for conferencing in SIP for SC,
    > before the application process ends, I hope I would be able to
    submit a
    > proposal to carry out a particular part of it.

    I am afraid that's far too short of a deadline even for us, the core
    developers, to come up with the final architecture for conferencing.

    I believe I already mentioned we have related project ideas on
    http://sip-communicator.org/gsoc (links below). You could start by
    helping up with them. Then, once we are decided on how we are going to
    handle conferencing you could still chime in and help with them. That is
    of course if you are interested in doing this as a part of GSoC
    (provided we get accepted). Otherwise you are most certainly free to
    work on whatever you wish.

Yes, I now feel the feasible approach would be that. I will look in to
contributing to SC with another already defined idea in the list with
regard to GSoC, and of course I am looking forward to join with
conference handling in the future.

    > Following I mention a summary of what I read about the subject and my
    > suggestions for implementing conferencing with regard to SC. If
    you all
    > could please give feed back on this, it would be a valuable
    guidance for me.
    >
    > The main refference to the following section of my mail is the
    fisrt pdf
    > that I have attached.(It is a good article on basics of conferencing.)
    > There are several basics tasks to be achieved in conferencing:
    >
    > 1).Signalling: such as INVITE for a conference, leave a conference,
    > expel participants and configure media streams.
    > possible approaches: centralized(bridge or endpoint)
    > and mesh
    > I suggest end point implementation of centralized
    > approach for SC.

    Yes, that's the plan so far.

    > 2).Media mixing and distribution:
    > same approaches as above are available but I suggest
    > end point centralized approach for SC, because although it makes SC
    > complicated when it acts as the focus, the other participants may but
    > not necessarily support conferencing.

    Yup, this too is probably the way we'll be heading.

    > 3). Conference Creation:
    > possible approaches: ad-hoc, scheduled, dial in,
    dial out.
    > First I felt ad-hoc would be good because it allows
    > invite further participants but I found it is mentioned that it
    can join
    > only a limited number of participants. Thus scheduled approach
    would be
    > preferable where the focus call out to a list of participants and the
    > participants call in to a conference URL representing the focus.

    I am not sure I see the problem you mention about ad-hoc conferences.
    This is most probably the model we will be adopting. Scheduled conf
    calls make little sense for an application-hosted solution not to
    mention that it would unnecessarily complicate the establishment
    procedures for users.

Well..I am sorry if i have not mentioned it clearly. I happened to read
in RFC 4245 section 2 :
             "The conference focus can be implemented either by a
participant or by a separate application server. In the first case, a
focus is typically capable of hosting a simple ad hoc conference only."
I might have interpreted it wrongly. After reading the logic you have
described below, I understood that the procedure we follow for adding
one participant can be used to add several as well.

    > When looking for the possible implementations, I found that web
    > service(SIP SOA) could be one option.

    Again, I am not sure I follow. Why would we need to have web services to
    handle conf calls? Conf call establishment (for an end-point hosted
    scenario) could be completely handled by SIP semantics: The call creator
    invites original participants. If others want to join later on they call
    the host, who would take their calls and then reINVITE them to join the
    conf. Makes sense?

Yes, Thank you for explaining.

    > My concern about it is, if we
    > implement conferencing in the bridge type of centralized approach that
    > is mentioned above, it would be feasible. But when it comes to the end
    > point centralized approach which I think is suitable for SC, will
    it be
    > a possible thing? because according to my basic knowledge of
    > webservices, it should be hosted in a server.

    Yes, you are correct.

    > If so we'd have to use a server like glass fish along with the SC
    installation.

    While we definitely need to support the use case of SC joining an RFC
    compliant conf call hosted on a server like glassfish or mobicents, the
    point of implementing conferencing in the client would be to make conf
    calls also available to users whose servers do not support this service.

    > Anyway when looking for a solution which goes with the above idea, I
    > found an open source project called SailFin which develop a container
    > for SIP Servlets. Following is a link:
    > http://java.dzone.com/news/sailfin-when-java-ee-met-sip.
    >
    > Though I still do not have a clear picture of what would be the best
    > suited implementation and tools with regard to conferencing in SC, I
    > thought of posting to the thread what I found, my suggestons and
    > possible implementations as I see, so that upon your feed back,
    > suggestion and guidance I hope I would be able to proceed well.
    >
    > Also, if it is not feasible to implement the whole conferencing
    > functionality alone during the time limt, may I ask would I be able to
    > propose to implement a specific part of it? such as some specific logc
    > in the focus, filtergraph for media mixing and rendering in focus

    You might be interested in this project idea:

    http://www.sip-communicator.org/index.php/GSOC2009/FmjFiltergraph

Yes, I have looked in to that idea too. Thank you for pointing it out.

    > or some other related part which I hope I would be able to propose
    more
    > specifically upon widening my knowledge on this.

    The sound level indicators are also one such part:
    http://www.sip-communicator.org/index.php/GSOC2009/SoundLevelIndicator

    Cheers
    Emil

Thank you.
regards,
Hasini.

    >
    >
    >
    > Hope this clears it out.
    >
    > Cheers
    > Emil
    >
    >
    > Thank you very much.
    > regards,
    > Hasini.
    >
    >
    >
    >
    >
    > > So could i please know whether it is not supposed for a GSoC
    > participant
    > > to apply on SIP Conferencing with SC?
    > > Of course, I found some of the ideas that are already
    published in
    > 2009
    > > list, too interest me very much. But I would like to get to know
    > whether
    > > implementing sip conferencing is not in the scope of GSoC
    particpants;
    > > so that i can look in to some other idea which i would like to
    > work with
    > > SC in GSoC.
    > >
    > >
    > > Thank you.
    > > Best Regards,
    > > Hasini.
    > >
    > >
    > >
    >
    >
    ---------------------------------------------------------------------
    > To unsubscribe, e-mail:
    > dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > <mailto:dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
    > For additional commands, e-mail:
    > dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    > <mailto:dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>>
    >
    >
    >
    >
    ------------------------------------------------------------------------
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

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

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