Hasini Gunasinghe wrote:
> On Thu, Mar 12, 2009 at 7:04 PM, Emil Ivov > <firstname.lastname@example.org <mailto:email@example.com> > > <mailto:firstname.lastname@example.org > <mailto:email@example.com>>> wrote:
> Hello Hasini,
> Hi all,
> Hasini Gunasinghe wrote:
> > Hi all,
> > I went through the GSoC 2009 ideas list and found that the
> > implementing SIP conferencing functionality is not included
> > 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
> 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.
> i was
> > pretty interested in looking in to SIP conferencing wth SC.
> Yes, indeed, we thought that the development of the feature is
> complex so we've decided to only post a simple part of it: the
> level indicator:
> We were thinking that the rest would be better taken care of
> experienced SIP Communicator developers. If you feel, however,
> could handle it by yourself you could still propose the idea
> provided we are accepted for participation). If you decide to
> 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
> agree upon a suitable architecture for conferencing in SIP for SC,
> before the application process ends, I hope I would be able to
> 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
> 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
> 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,
> First I felt ad-hoc would be good because it allows
> invite further participants but I found it is mentioned that it
> only a limited number of participants. Thus scheduled approach
> 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
> 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
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:
> 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:
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
> specifically upon widening my knowledge on this.
The sound level indicators are also one such part:
> Hope this clears it out.
> Thank you very much.
> > So could i please know whether it is not supposed for a GSoC
> > to apply on SIP Conferencing with SC?
> > Of course, I found some of the ideas that are already
> > list, too interest me very much. But I would like to get to know
> > implementing sip conferencing is not in the scope of GSoC
> > 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:
> For additional commands, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail: