[sip-comm-dev] Extending plugin support functionalities


#1

Hi all,

As a few of you know, I've been doing some work on a proprietary SC plugin
for the company I'm interning with, and this means I've been taking a close
look at the extensibility options that SC has. Every so often, I run into a
wall and think, gee, wouldn't it be nice if we could allow SC plugins to do
x. This is one of those cases.

As part of the system that we're using SC with, we need the capability to
have a SIP client add custom headers to SIP INVITE messages. I've written
some primitive code in SC that allows plugins to register a header
(basically an object that stores Strings containing the name, value, and
associated protocol for the header) as an OSGi service, and then added some
code in OperationSetBasicTelephonySipImpl to search for any registered
plugin headers, and create and add Headers to the INVITE accordingly. Please
see the attached code.

Is this functionality something that would be useful to include in SC, or is
this a unique requirement? Emil and I discussed this concept briefly a few
weeks ago, and he recommended that I circulate the proposed interface to get
more feedback.

Thanks,

-Alan

exthdr_interface.patch (9.5 KB)


#2

Can I get some feedback on this please? Thanks.

···

On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly <akoriolesfan@gmail.com> wrote:

Hi all,

As a few of you know, I've been doing some work on a proprietary SC plugin
for the company I'm interning with, and this means I've been taking a close
look at the extensibility options that SC has. Every so often, I run into a
wall and think, gee, wouldn't it be nice if we could allow SC plugins to do
x. This is one of those cases.

As part of the system that we're using SC with, we need the capability to
have a SIP client add custom headers to SIP INVITE messages. I've written
some primitive code in SC that allows plugins to register a header
(basically an object that stores Strings containing the name, value, and
associated protocol for the header) as an OSGi service, and then added some
code in OperationSetBasicTelephonySipImpl to search for any registered
plugin headers, and create and add Headers to the INVITE accordingly. Please
see the attached code.

Is this functionality something that would be useful to include in SC, or
is this a unique requirement? Emil and I discussed this concept briefly a
few weeks ago, and he recommended that I circulate the proposed interface to
get more feedback.

Thanks,

-Alan


#3

Hi Alan,

I don't want to get in the way of Emil with respect to this case
because I don't personally have a use case for the functionality in
question. But since you have, why not post a patch in this thread? I
mean that we may not have the use case right now but if it happens to
be of need later on, we could merge the patch into the repository at
that later time.

Thank you for the contribution anyway,
Lubo

···

On Wed, May 13, 2009 at 10:43 PM, Alan Kelly <akoriolesfan@gmail.com> wrote:

Can I get some feedback on this please? Thanks.

On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly <akoriolesfan@gmail.com> wrote:

Hi all,

As a few of you know, I've been doing some work on a proprietary SC plugin
for the company I'm interning with, and this means I've been taking a close
look at the extensibility options that SC has. Every so often, I run into a
wall and think, gee, wouldn't it be nice if we could allow SC plugins to do
x. This is one of those cases.

As part of the system that we're using SC with, we need the capability to
have a SIP client add custom headers to SIP INVITE messages. I've written
some primitive code in SC that allows plugins to register a header
(basically an object that stores Strings containing the name, value, and
associated protocol for the header) as an OSGi service, and then added some
code in OperationSetBasicTelephonySipImpl to search for any registered
plugin headers, and create and add Headers to the INVITE accordingly. Please
see the attached code.

Is this functionality something that would be useful to include in SC, or
is this a unique requirement? Emil and I discussed this concept briefly a
few weeks ago, and he recommended that I circulate the proposed interface to
get more feedback.

Thanks,

-Alan

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


#4

Hi Lubo,

Thanks for the response.

I actually did post a patch, including a (very simplistic and useless
implementation) back on 27 March, but I think it was overlooked among all
the GSoC emails. I guess the attachment didn't make it into my reply
message. Here it is again.

I might be able to come up with some use cases for this.

Thanks,

Alan

exthdr_interface.patch (9.5 KB)

···

On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov <lubomir.marinov@gmail.com>wrote:

Hi Alan,

I don't want to get in the way of Emil with respect to this case
because I don't personally have a use case for the functionality in
question. But since you have, why not post a patch in this thread? I
mean that we may not have the use case right now but if it happens to
be of need later on, we could merge the patch into the repository at
that later time.

Thank you for the contribution anyway,
Lubo

On Wed, May 13, 2009 at 10:43 PM, Alan Kelly <akoriolesfan@gmail.com> > wrote:
> Can I get some feedback on this please? Thanks.
>
> On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly <akoriolesfan@gmail.com> > wrote:
>>
>> Hi all,
>>
>> As a few of you know, I've been doing some work on a proprietary SC
plugin
>> for the company I'm interning with, and this means I've been taking a
close
>> look at the extensibility options that SC has. Every so often, I run
into a
>> wall and think, gee, wouldn't it be nice if we could allow SC plugins to
do
>> x. This is one of those cases.
>>
>> As part of the system that we're using SC with, we need the capability
to
>> have a SIP client add custom headers to SIP INVITE messages. I've
written
>> some primitive code in SC that allows plugins to register a header
>> (basically an object that stores Strings containing the name, value, and
>> associated protocol for the header) as an OSGi service, and then added
some
>> code in OperationSetBasicTelephonySipImpl to search for any registered
>> plugin headers, and create and add Headers to the INVITE accordingly.
Please
>> see the attached code.
>>
>> Is this functionality something that would be useful to include in SC,
or
>> is this a unique requirement? Emil and I discussed this concept briefly
a
>> few weeks ago, and he recommended that I circulate the proposed
interface to
>> get more feedback.
>>
>> Thanks,
>>
>> -Alan
>>
>
>

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


#5

Hey Alan,

I apologize for the lag.

As mentioned off-list I do think this is a great idea and we can start
working on it right after we branch. My only concern is making sure the
mechanism is generic enough and that it fits a reasonable number of use
cases.

I am thinking for example that external plugins may also need to
initiate requests and handle their responses. This would imply exposing
the transaction mechanism too, as well as the jain-sip providers and
factories. We would also have to give plugins the possibility to
"consume" SIP messages (i.e. prevent the SIP provider from processing
them) ... a bit like what we are going to be doing with the transform
layers in the messaging operation sets.

We could actually get there relatively easily. We'd simply need to make
sure that our sip provider package also exposts the javax.sip interfaces
from jain-sip and then also add the possibility to have SIP message
filter layers.

This way we'd be able to handle the use case you describe as well as
virtually any other SIP based feature as a plugin.

How does this sound?

Cheers
Emil

P.S. I've added a corresponding entry in our road map as I believe this
is going to be a popular feature.

Alan Kelly wrote:

···

Hi Lubo,

Thanks for the response.

I actually did post a patch, including a (very simplistic and useless
implementation) back on 27 March, but I think it was overlooked among
all the GSoC emails. I guess the attachment didn't make it into my reply
message. Here it is again.

I might be able to come up with some use cases for this.

Thanks,

Alan

On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov > <lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com>> wrote:

    Hi Alan,

    I don't want to get in the way of Emil with respect to this case
    because I don't personally have a use case for the functionality in
    question. But since you have, why not post a patch in this thread? I
    mean that we may not have the use case right now but if it happens to
    be of need later on, we could merge the patch into the repository at
    that later time.

    Thank you for the contribution anyway,
    Lubo

    On Wed, May 13, 2009 at 10:43 PM, Alan Kelly <akoriolesfan@gmail.com > <mailto:akoriolesfan@gmail.com>> wrote:
    > Can I get some feedback on this please? Thanks.
    >
    > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>> wrote:
    >>
    >> Hi all,
    >>
    >> As a few of you know, I've been doing some work on a proprietary
    SC plugin
    >> for the company I'm interning with, and this means I've been
    taking a close
    >> look at the extensibility options that SC has. Every so often, I
    run into a
    >> wall and think, gee, wouldn't it be nice if we could allow SC
    plugins to do
    >> x. This is one of those cases.
    >>
    >> As part of the system that we're using SC with, we need the
    capability to
    >> have a SIP client add custom headers to SIP INVITE messages. I've
    written
    >> some primitive code in SC that allows plugins to register a header
    >> (basically an object that stores Strings containing the name,
    value, and
    >> associated protocol for the header) as an OSGi service, and then
    added some
    >> code in OperationSetBasicTelephonySipImpl to search for any
    registered
    >> plugin headers, and create and add Headers to the INVITE
    accordingly. Please
    >> see the attached code.
    >>
    >> Is this functionality something that would be useful to include
    in SC, or
    >> is this a unique requirement? Emil and I discussed this concept
    briefly a
    >> few weeks ago, and he recommended that I circulate the proposed
    interface to
    >> get more feedback.
    >>
    >> Thanks,
    >>
    >> -Alan
    >>
    >
    >

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

--
Emil Ivov, Ph.D. 30a rue de la Patrie
Project Lead 67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

---------------------------------------------------------------------
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 Emil,

No worries, I haven't had time to work on it anyways, as illustrated by my 6
week absence from this list :slight_smile:

That sounds excellent to me, it's much more generic than the small set of
capabilities I was imagining, but it's a better solution and fits the cases
I have in mind very well. The patch I sent out is really only a workaround.

And I agree, with that kind of flexibility, it could be a very popular
feature. I know I can see further applications for it in my projects.

-Alan

···

On Fri, May 15, 2009 at 10:57 AM, Emil Ivov <emcho@sip-communicator.org>wrote:

Hey Alan,

I apologize for the lag.

As mentioned off-list I do think this is a great idea and we can start
working on it right after we branch. My only concern is making sure the
mechanism is generic enough and that it fits a reasonable number of use
cases.

I am thinking for example that external plugins may also need to
initiate requests and handle their responses. This would imply exposing
the transaction mechanism too, as well as the jain-sip providers and
factories. We would also have to give plugins the possibility to
"consume" SIP messages (i.e. prevent the SIP provider from processing
them) ... a bit like what we are going to be doing with the transform
layers in the messaging operation sets.

We could actually get there relatively easily. We'd simply need to make
sure that our sip provider package also exposts the javax.sip interfaces
from jain-sip and then also add the possibility to have SIP message
filter layers.

This way we'd be able to handle the use case you describe as well as
virtually any other SIP based feature as a plugin.

How does this sound?

Cheers
Emil

P.S. I've added a corresponding entry in our road map as I believe this
is going to be a popular feature.

Alan Kelly wrote:
> Hi Lubo,
>
> Thanks for the response.
>
> I actually did post a patch, including a (very simplistic and useless
> implementation) back on 27 March, but I think it was overlooked among
> all the GSoC emails. I guess the attachment didn't make it into my reply
> message. Here it is again.
>
> I might be able to come up with some use cases for this.
>
> Thanks,
>
> Alan
>
> On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov > > <lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com>> wrote:
>
> Hi Alan,
>
> I don't want to get in the way of Emil with respect to this case
> because I don't personally have a use case for the functionality in
> question. But since you have, why not post a patch in this thread? I
> mean that we may not have the use case right now but if it happens to
> be of need later on, we could merge the patch into the repository at
> that later time.
>
> Thank you for the contribution anyway,
> Lubo
>
> On Wed, May 13, 2009 at 10:43 PM, Alan Kelly <akoriolesfan@gmail.com > > <mailto:akoriolesfan@gmail.com>> wrote:
> > Can I get some feedback on this please? Thanks.
> >
> > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>> wrote:
> >>
> >> Hi all,
> >>
> >> As a few of you know, I've been doing some work on a proprietary
> SC plugin
> >> for the company I'm interning with, and this means I've been
> taking a close
> >> look at the extensibility options that SC has. Every so often, I
> run into a
> >> wall and think, gee, wouldn't it be nice if we could allow SC
> plugins to do
> >> x. This is one of those cases.
> >>
> >> As part of the system that we're using SC with, we need the
> capability to
> >> have a SIP client add custom headers to SIP INVITE messages. I've
> written
> >> some primitive code in SC that allows plugins to register a header
> >> (basically an object that stores Strings containing the name,
> value, and
> >> associated protocol for the header) as an OSGi service, and then
> added some
> >> code in OperationSetBasicTelephonySipImpl to search for any
> registered
> >> plugin headers, and create and add Headers to the INVITE
> accordingly. Please
> >> see the attached code.
> >>
> >> Is this functionality something that would be useful to include
> in SC, or
> >> is this a unique requirement? Emil and I discussed this concept
> briefly a
> >> few weeks ago, and he recommended that I circulate the proposed
> interface to
> >> get more feedback.
> >>
> >> Thanks,
> >>
> >> -Alan
> >>
> >
> >
>
> ---------------------------------------------------------------------
> 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

--
Emil Ivov, Ph.D. 30a rue de la Patrie
Project Lead 67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

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


#7

Alan,

Glad we are on the same page. Let's think about this some more and then
commit a draft after we branch.

Cheers
Emil

Alan Kelly wrote:

···

Hi Emil,

No worries, I haven't had time to work on it anyways, as illustrated by
my 6 week absence from this list :slight_smile:

That sounds excellent to me, it's much more generic than the small set
of capabilities I was imagining, but it's a better solution and fits the
cases I have in mind very well. The patch I sent out is really only a
workaround.

And I agree, with that kind of flexibility, it could be a very popular
feature. I know I can see further applications for it in my projects.

-Alan

On Fri, May 15, 2009 at 10:57 AM, Emil Ivov <emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>> wrote:

    Hey Alan,

    I apologize for the lag.

    As mentioned off-list I do think this is a great idea and we can start
    working on it right after we branch. My only concern is making sure the
    mechanism is generic enough and that it fits a reasonable number of use
    cases.

    I am thinking for example that external plugins may also need to
    initiate requests and handle their responses. This would imply exposing
    the transaction mechanism too, as well as the jain-sip providers and
    factories. We would also have to give plugins the possibility to
    "consume" SIP messages (i.e. prevent the SIP provider from processing
    them) ... a bit like what we are going to be doing with the transform
    layers in the messaging operation sets.

    We could actually get there relatively easily. We'd simply need to make
    sure that our sip provider package also exposts the javax.sip interfaces
    from jain-sip and then also add the possibility to have SIP message
    filter layers.

    This way we'd be able to handle the use case you describe as well as
    virtually any other SIP based feature as a plugin.

    How does this sound?

    Cheers
    Emil

    P.S. I've added a corresponding entry in our road map as I believe this
    is going to be a popular feature.

    Alan Kelly wrote:
    > Hi Lubo,
    >
    > Thanks for the response.
    >
    > I actually did post a patch, including a (very simplistic and useless
    > implementation) back on 27 March, but I think it was overlooked among
    > all the GSoC emails. I guess the attachment didn't make it into my
    reply
    > message. Here it is again.
    >
    > I might be able to come up with some use cases for this.
    >
    > Thanks,
    >
    > Alan
    >
    > On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov > > <lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com> > <mailto:lubomir.marinov@gmail.com > <mailto:lubomir.marinov@gmail.com>>> wrote:
    >
    > Hi Alan,
    >
    > I don't want to get in the way of Emil with respect to this case
    > because I don't personally have a use case for the
    functionality in
    > question. But since you have, why not post a patch in this
    thread? I
    > mean that we may not have the use case right now but if it
    happens to
    > be of need later on, we could merge the patch into the
    repository at
    > that later time.
    >
    > Thank you for the contribution anyway,
    > Lubo
    >
    > On Wed, May 13, 2009 at 10:43 PM, Alan Kelly > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com> > > <mailto:akoriolesfan@gmail.com > <mailto:akoriolesfan@gmail.com>>> wrote:
    > > Can I get some feedback on this please? Thanks.
    > >
    > > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com> > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>> wrote:
    > >>
    > >> Hi all,
    > >>
    > >> As a few of you know, I've been doing some work on a
    proprietary
    > SC plugin
    > >> for the company I'm interning with, and this means I've been
    > taking a close
    > >> look at the extensibility options that SC has. Every so
    often, I
    > run into a
    > >> wall and think, gee, wouldn't it be nice if we could allow SC
    > plugins to do
    > >> x. This is one of those cases.
    > >>
    > >> As part of the system that we're using SC with, we need the
    > capability to
    > >> have a SIP client add custom headers to SIP INVITE
    messages. I've
    > written
    > >> some primitive code in SC that allows plugins to register a
    header
    > >> (basically an object that stores Strings containing the name,
    > value, and
    > >> associated protocol for the header) as an OSGi service, and
    then
    > added some
    > >> code in OperationSetBasicTelephonySipImpl to search for any
    > registered
    > >> plugin headers, and create and add Headers to the INVITE
    > accordingly. Please
    > >> see the attached code.
    > >>
    > >> Is this functionality something that would be useful to include
    > in SC, or
    > >> is this a unique requirement? Emil and I discussed this concept
    > briefly a
    > >> few weeks ago, and he recommended that I circulate the proposed
    > interface to
    > >> get more feedback.
    > >>
    > >> Thanks,
    > >>
    > >> -Alan
    > >>
    > >
    > >
    >
    >
    ---------------------------------------------------------------------
    > 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>

    --
    Emil Ivov, Ph.D. 30a rue de la Patrie
    Project Lead 67300 Schiltigheim
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  FAX: +33.1.77.62.47.31
    http://sip-communicator.org PHONE: +33.1.77.62.43.30

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

--
Emil Ivov, Ph.D. 30a rue de la Patrie
Project Lead 67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

---------------------------------------------------------------------
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 Emil,

Speaking of branching, what's the status on that? I know it keeps getting
delayed but I was wondering what the current timeline is. Thanks.

-Alan

···

On Fri, May 15, 2009 at 1:01 PM, Emil Ivov <emcho@sip-communicator.org>wrote:

Alan,

Glad we are on the same page. Let's think about this some more and then
commit a draft after we branch.

Cheers
Emil

Alan Kelly wrote:
> Hi Emil,
>
> No worries, I haven't had time to work on it anyways, as illustrated by
> my 6 week absence from this list :slight_smile:
>
> That sounds excellent to me, it's much more generic than the small set
> of capabilities I was imagining, but it's a better solution and fits the
> cases I have in mind very well. The patch I sent out is really only a
> workaround.
>
> And I agree, with that kind of flexibility, it could be a very popular
> feature. I know I can see further applications for it in my projects.
>
> -Alan
>
>
> On Fri, May 15, 2009 at 10:57 AM, Emil Ivov <emcho@sip-communicator.org > > <mailto:emcho@sip-communicator.org>> wrote:
>
> Hey Alan,
>
> I apologize for the lag.
>
> As mentioned off-list I do think this is a great idea and we can
start
> working on it right after we branch. My only concern is making sure
the
> mechanism is generic enough and that it fits a reasonable number of
use
> cases.
>
> I am thinking for example that external plugins may also need to
> initiate requests and handle their responses. This would imply
exposing
> the transaction mechanism too, as well as the jain-sip providers and
> factories. We would also have to give plugins the possibility to
> "consume" SIP messages (i.e. prevent the SIP provider from processing
> them) ... a bit like what we are going to be doing with the transform
> layers in the messaging operation sets.
>
> We could actually get there relatively easily. We'd simply need to
make
> sure that our sip provider package also exposts the javax.sip
interfaces
> from jain-sip and then also add the possibility to have SIP message
> filter layers.
>
> This way we'd be able to handle the use case you describe as well as
> virtually any other SIP based feature as a plugin.
>
> How does this sound?
>
> Cheers
> Emil
>
> P.S. I've added a corresponding entry in our road map as I believe
this
> is going to be a popular feature.
>
>
>
> Alan Kelly wrote:
> > Hi Lubo,
> >
> > Thanks for the response.
> >
> > I actually did post a patch, including a (very simplistic and
useless
> > implementation) back on 27 March, but I think it was overlooked
among
> > all the GSoC emails. I guess the attachment didn't make it into my
> reply
> > message. Here it is again.
> >
> > I might be able to come up with some use cases for this.
> >
> > Thanks,
> >
> > Alan
> >
> > On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov > > > <lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com> > > <mailto:lubomir.marinov@gmail.com > > <mailto:lubomir.marinov@gmail.com>>> wrote:
> >
> > Hi Alan,
> >
> > I don't want to get in the way of Emil with respect to this
case
> > because I don't personally have a use case for the
> functionality in
> > question. But since you have, why not post a patch in this
> thread? I
> > mean that we may not have the use case right now but if it
> happens to
> > be of need later on, we could merge the patch into the
> repository at
> > that later time.
> >
> > Thank you for the contribution anyway,
> > Lubo
> >
> > On Wed, May 13, 2009 at 10:43 PM, Alan Kelly > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com> > > > <mailto:akoriolesfan@gmail.com > > <mailto:akoriolesfan@gmail.com>>> wrote:
> > > Can I get some feedback on this please? Thanks.
> > >
> > > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly > > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com> > > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>> > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> As a few of you know, I've been doing some work on a
> proprietary
> > SC plugin
> > >> for the company I'm interning with, and this means I've been
> > taking a close
> > >> look at the extensibility options that SC has. Every so
> often, I
> > run into a
> > >> wall and think, gee, wouldn't it be nice if we could allow
SC
> > plugins to do
> > >> x. This is one of those cases.
> > >>
> > >> As part of the system that we're using SC with, we need the
> > capability to
> > >> have a SIP client add custom headers to SIP INVITE
> messages. I've
> > written
> > >> some primitive code in SC that allows plugins to register a
> header
> > >> (basically an object that stores Strings containing the
name,
> > value, and
> > >> associated protocol for the header) as an OSGi service, and
> then
> > added some
> > >> code in OperationSetBasicTelephonySipImpl to search for any
> > registered
> > >> plugin headers, and create and add Headers to the INVITE
> > accordingly. Please
> > >> see the attached code.
> > >>
> > >> Is this functionality something that would be useful to
include
> > in SC, or
> > >> is this a unique requirement? Emil and I discussed this
concept
> > briefly a
> > >> few weeks ago, and he recommended that I circulate the
proposed
> > interface to
> > >> get more feedback.
> > >>
> > >> Thanks,
> > >>
> > >> -Alan
> > >>
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > 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>
>
> --
> Emil Ivov, Ph.D. 30a rue de la Patrie
> Project Lead 67300 Schiltigheim
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> FAX: +33.1.77.62.47.31
> http://sip-communicator.org PHONE:
+33.1.77.62.43.30
>
> ---------------------------------------------------------------------
> 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>
>
>

--
Emil Ivov, Ph.D. 30a rue de la Patrie
Project Lead 67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

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


#9

Hey Alan,

I believe they've postponed it for after JavaOne in order to avoid last
minute problems for projects that would be exposing there.

I'll try to see whether we can branch and have merge tracking without this.

Cheers
Emil

Alan Kelly wrote:

···

Hi Emil,

Speaking of branching, what's the status on that? I know it keeps
getting delayed but I was wondering what the current timeline is. Thanks.

-Alan

On Fri, May 15, 2009 at 1:01 PM, Emil Ivov <emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>> wrote:

    Alan,

    Glad we are on the same page. Let's think about this some more and then
    commit a draft after we branch.

    Cheers
    Emil

    Alan Kelly wrote:
    > Hi Emil,
    >
    > No worries, I haven't had time to work on it anyways, as
    illustrated by
    > my 6 week absence from this list :slight_smile:
    >
    > That sounds excellent to me, it's much more generic than the small set
    > of capabilities I was imagining, but it's a better solution and
    fits the
    > cases I have in mind very well. The patch I sent out is really only a
    > workaround.
    >
    > And I agree, with that kind of flexibility, it could be a very popular
    > feature. I know I can see further applications for it in my projects.
    >
    > -Alan
    >
    >
    > On Fri, May 15, 2009 at 10:57 AM, Emil Ivov > <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org> > > <mailto:emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>>> wrote:
    >
    > Hey Alan,
    >
    > I apologize for the lag.
    >
    > As mentioned off-list I do think this is a great idea and we
    can start
    > working on it right after we branch. My only concern is making
    sure the
    > mechanism is generic enough and that it fits a reasonable
    number of use
    > cases.
    >
    > I am thinking for example that external plugins may also need to
    > initiate requests and handle their responses. This would imply
    exposing
    > the transaction mechanism too, as well as the jain-sip
    providers and
    > factories. We would also have to give plugins the possibility to
    > "consume" SIP messages (i.e. prevent the SIP provider from
    processing
    > them) ... a bit like what we are going to be doing with the
    transform
    > layers in the messaging operation sets.
    >
    > We could actually get there relatively easily. We'd simply
    need to make
    > sure that our sip provider package also exposts the javax.sip
    interfaces
    > from jain-sip and then also add the possibility to have SIP
    message
    > filter layers.
    >
    > This way we'd be able to handle the use case you describe as
    well as
    > virtually any other SIP based feature as a plugin.
    >
    > How does this sound?
    >
    > Cheers
    > Emil
    >
    > P.S. I've added a corresponding entry in our road map as I
    believe this
    > is going to be a popular feature.
    >
    >
    >
    > Alan Kelly wrote:
    > > Hi Lubo,
    > >
    > > Thanks for the response.
    > >
    > > I actually did post a patch, including a (very simplistic
    and useless
    > > implementation) back on 27 March, but I think it was
    overlooked among
    > > all the GSoC emails. I guess the attachment didn't make it
    into my
    > reply
    > > message. Here it is again.
    > >
    > > I might be able to come up with some use cases for this.
    > >
    > > Thanks,
    > >
    > > Alan
    > >
    > > On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov
    > > <lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com> <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>>
    > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>
    > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>>>> wrote:
    > >
    > > Hi Alan,
    > >
    > > I don't want to get in the way of Emil with respect to
    this case
    > > because I don't personally have a use case for the
    > functionality in
    > > question. But since you have, why not post a patch in this
    > thread? I
    > > mean that we may not have the use case right now but if it
    > happens to
    > > be of need later on, we could merge the patch into the
    > repository at
    > > that later time.
    > >
    > > Thank you for the contribution anyway,
    > > Lubo
    > >
    > > On Wed, May 13, 2009 at 10:43 PM, Alan Kelly
    > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
    <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>
    > > <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>
    > <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>>>> wrote:
    > > > Can I get some feedback on this please? Thanks.
    > > >
    > > > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly > > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com> > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>> > > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com> > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>>> wrote:
    > > >>
    > > >> Hi all,
    > > >>
    > > >> As a few of you know, I've been doing some work on a
    > proprietary
    > > SC plugin
    > > >> for the company I'm interning with, and this means
    I've been
    > > taking a close
    > > >> look at the extensibility options that SC has. Every so
    > often, I
    > > run into a
    > > >> wall and think, gee, wouldn't it be nice if we could
    allow SC
    > > plugins to do
    > > >> x. This is one of those cases.
    > > >>
    > > >> As part of the system that we're using SC with, we
    need the
    > > capability to
    > > >> have a SIP client add custom headers to SIP INVITE
    > messages. I've
    > > written
    > > >> some primitive code in SC that allows plugins to
    register a
    > header
    > > >> (basically an object that stores Strings containing
    the name,
    > > value, and
    > > >> associated protocol for the header) as an OSGi
    service, and
    > then
    > > added some
    > > >> code in OperationSetBasicTelephonySipImpl to search
    for any
    > > registered
    > > >> plugin headers, and create and add Headers to the INVITE
    > > accordingly. Please
    > > >> see the attached code.
    > > >>
    > > >> Is this functionality something that would be useful
    to include
    > > in SC, or
    > > >> is this a unique requirement? Emil and I discussed
    this concept
    > > briefly a
    > > >> few weeks ago, and he recommended that I circulate
    the proposed
    > > interface to
    > > >> get more feedback.
    > > >>
    > > >> Thanks,
    > > >>
    > > >> -Alan
    > > >>
    > > >
    > > >
    > >
    > >
    >
    ---------------------------------------------------------------------
    > > 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>>
    > > <mailto: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>>
    > > <mailto: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>
    > <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>>
    >
    > --
    > Emil Ivov, Ph.D. 30a rue de la
    Patrie
    > Project Lead 67300 Schiltigheim
    > SIP Communicator
    > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > FAX: +33.1.77.62.47.31
    > http://sip-communicator.org PHONE:
    +33.1.77.62.43.30
    >
    >
    ---------------------------------------------------------------------
    > 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>>
    >
    >

    --
    Emil Ivov, Ph.D. 30a rue de la Patrie
    Project Lead 67300 Schiltigheim
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  FAX: +33.1.77.62.47.31
    http://sip-communicator.org PHONE: +33.1.77.62.43.30

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

--
Emil Ivov, Ph.D. 30a rue de la Patrie
Project Lead 67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

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


#10

Emil,

It seems to me that we have two tasks here.

1) Exposing the javax.sip interfaces so that they can be used by other
bundles.

I'm not an expert on OSGi so I'm probably not the one to figure that part
out.

2) Creating additional "API" functionalities in the SIP bundle to allow
plugins to interact with the SIP protocol to send SIP messages, insert
headers into messages, consume messages, etc.

I'm busy with some other projects right now, but I'll be working on a list
of the features I'd like to see included, and we can discuss the best ways
to implement them.

-Alan

···

On Thu, May 21, 2009 at 6:59 PM, Emil Ivov <emcho@sip-communicator.org>wrote:

Hey Alan,

I believe they've postponed it for after JavaOne in order to avoid last
minute problems for projects that would be exposing there.

I'll try to see whether we can branch and have merge tracking without this.

Cheers
Emil

Alan Kelly wrote:
> Hi Emil,
>
> Speaking of branching, what's the status on that? I know it keeps
> getting delayed but I was wondering what the current timeline is. Thanks.
>
> -Alan
>
>
> On Fri, May 15, 2009 at 1:01 PM, Emil Ivov <emcho@sip-communicator.org > > <mailto:emcho@sip-communicator.org>> wrote:
>
> Alan,
>
> Glad we are on the same page. Let's think about this some more and
then
> commit a draft after we branch.
>
> Cheers
> Emil
>
> Alan Kelly wrote:
> > Hi Emil,
> >
> > No worries, I haven't had time to work on it anyways, as
> illustrated by
> > my 6 week absence from this list :slight_smile:
> >
> > That sounds excellent to me, it's much more generic than the small
set
> > of capabilities I was imagining, but it's a better solution and
> fits the
> > cases I have in mind very well. The patch I sent out is really only
a
> > workaround.
> >
> > And I agree, with that kind of flexibility, it could be a very
popular
> > feature. I know I can see further applications for it in my
projects.
> >
> > -Alan
> >
> >
> > On Fri, May 15, 2009 at 10:57 AM, Emil Ivov > > <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org> > > > <mailto:emcho@sip-communicator.org > > <mailto:emcho@sip-communicator.org>>> wrote:
> >
> > Hey Alan,
> >
> > I apologize for the lag.
> >
> > As mentioned off-list I do think this is a great idea and we
> can start
> > working on it right after we branch. My only concern is making
> sure the
> > mechanism is generic enough and that it fits a reasonable
> number of use
> > cases.
> >
> > I am thinking for example that external plugins may also need
to
> > initiate requests and handle their responses. This would imply
> exposing
> > the transaction mechanism too, as well as the jain-sip
> providers and
> > factories. We would also have to give plugins the possibility
to
> > "consume" SIP messages (i.e. prevent the SIP provider from
> processing
> > them) ... a bit like what we are going to be doing with the
> transform
> > layers in the messaging operation sets.
> >
> > We could actually get there relatively easily. We'd simply
> need to make
> > sure that our sip provider package also exposts the javax.sip
> interfaces
> > from jain-sip and then also add the possibility to have SIP
> message
> > filter layers.
> >
> > This way we'd be able to handle the use case you describe as
> well as
> > virtually any other SIP based feature as a plugin.
> >
> > How does this sound?
> >
> > Cheers
> > Emil
> >
> > P.S. I've added a corresponding entry in our road map as I
> believe this
> > is going to be a popular feature.
> >
> >
> >
> > Alan Kelly wrote:
> > > Hi Lubo,
> > >
> > > Thanks for the response.
> > >
> > > I actually did post a patch, including a (very simplistic
> and useless
> > > implementation) back on 27 March, but I think it was
> overlooked among
> > > all the GSoC emails. I guess the attachment didn't make it
> into my
> > reply
> > > message. Here it is again.
> > >
> > > I might be able to come up with some use cases for this.
> > >
> > > Thanks,
> > >
> > > Alan
> > >
> > > On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov
> > > <lubomir.marinov@gmail.com
> <mailto:lubomir.marinov@gmail.com> <mailto:lubomir.marinov@gmail.com
> <mailto:lubomir.marinov@gmail.com>>
> > <mailto:lubomir.marinov@gmail.com
> <mailto:lubomir.marinov@gmail.com>
> > <mailto:lubomir.marinov@gmail.com
> <mailto:lubomir.marinov@gmail.com>>>> wrote:
> > >
> > > Hi Alan,
> > >
> > > I don't want to get in the way of Emil with respect to
> this case
> > > because I don't personally have a use case for the
> > functionality in
> > > question. But since you have, why not post a patch in
this
> > thread? I
> > > mean that we may not have the use case right now but if
it
> > happens to
> > > be of need later on, we could merge the patch into the
> > repository at
> > > that later time.
> > >
> > > Thank you for the contribution anyway,
> > > Lubo
> > >
> > > On Wed, May 13, 2009 at 10:43 PM, Alan Kelly
> > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
> <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>
> > > <mailto:akoriolesfan@gmail.com
> <mailto:akoriolesfan@gmail.com>
> > <mailto:akoriolesfan@gmail.com
> <mailto:akoriolesfan@gmail.com>>>> wrote:
> > > > Can I get some feedback on this please? Thanks.
> > > >
> > > > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly
> > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
> <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>
> > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
> <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>>>
wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> As a few of you know, I've been doing some work on a
> > proprietary
> > > SC plugin
> > > >> for the company I'm interning with, and this means
> I've been
> > > taking a close
> > > >> look at the extensibility options that SC has. Every
so
> > often, I
> > > run into a
> > > >> wall and think, gee, wouldn't it be nice if we could
> allow SC
> > > plugins to do
> > > >> x. This is one of those cases.
> > > >>
> > > >> As part of the system that we're using SC with, we
> need the
> > > capability to
> > > >> have a SIP client add custom headers to SIP INVITE
> > messages. I've
> > > written
> > > >> some primitive code in SC that allows plugins to
> register a
> > header
> > > >> (basically an object that stores Strings containing
> the name,
> > > value, and
> > > >> associated protocol for the header) as an OSGi
> service, and
> > then
> > > added some
> > > >> code in OperationSetBasicTelephonySipImpl to search
> for any
> > > registered
> > > >> plugin headers, and create and add Headers to the
INVITE
> > > accordingly. Please
> > > >> see the attached code.
> > > >>
> > > >> Is this functionality something that would be useful
> to include
> > > in SC, or
> > > >> is this a unique requirement? Emil and I discussed
> this concept
> > > briefly a
> > > >> few weeks ago, and he recommended that I circulate
> the proposed
> > > interface to
> > > >> get more feedback.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> -Alan
> > > >>
> > > >
> > > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > 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>>
> > > <mailto: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>>
> > > <mailto: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>
> > <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>>
> >
> > --
> > Emil Ivov, Ph.D. 30a rue de la
> Patrie
> > Project Lead 67300
Schiltigheim
> > SIP Communicator
> > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> <mailto:emcho@sip-communicator.org <mailto:
emcho@sip-communicator.org>>
> > FAX: +33.1.77.62.47.31
> > http://sip-communicator.org PHONE:
> +33.1.77.62.43.30
> >
> >
> ---------------------------------------------------------------------
> > 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>>
> >
> >
>
> --
> Emil Ivov, Ph.D. 30a rue de la Patrie
> Project Lead 67300 Schiltigheim
> SIP Communicator
> emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
> FAX: +33.1.77.62.47.31
> http://sip-communicator.org PHONE:
+33.1.77.62.43.30
>
> ---------------------------------------------------------------------
> 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>
>
>

--
Emil Ivov, Ph.D. 30a rue de la Patrie
Project Lead 67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

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


#11

Hey Alan,

Alan Kelly wrote:

Emil,

It seems to me that we have two tasks here.

1) Exposing the javax.sip interfaces so that they can be used by other
bundles.

I'm not an expert on OSGi so I'm probably not the one to figure that
part out.

2) Creating additional "API" functionalities in the SIP bundle to allow
plugins to interact with the SIP protocol to send SIP messages, insert
headers into messages, consume messages, etc.

I'm busy with some other projects right now, but I'll be working on a
list of the features I'd like to see included, and we can discuss the
best ways to implement them.

Good idea. It would be nice to have a list of requirements like these,
based on real world needs so that we better design the SIP API.

Right now I am thinking that it would be nice to be able to simply
register MessageProcessors from outside the SIP bundle. We may also need
to add the possibility to specify priority (in case we'd like to make
sure that a new message processor goes before one that already exists in
SC) and the possibility to register them for outgoing as well messages.

Cheers
Emil

···

-Alan

On Thu, May 21, 2009 at 6:59 PM, Emil Ivov <emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>> wrote:

    Hey Alan,

    I believe they've postponed it for after JavaOne in order to avoid last
    minute problems for projects that would be exposing there.

    I'll try to see whether we can branch and have merge tracking
    without this.

    Cheers
    Emil

    Alan Kelly wrote:
    > Hi Emil,
    >
    > Speaking of branching, what's the status on that? I know it keeps
    > getting delayed but I was wondering what the current timeline is.
    Thanks.
    >
    > -Alan
    >
    >
    > On Fri, May 15, 2009 at 1:01 PM, Emil Ivov > <emcho@sip-communicator.org <mailto:emcho@sip-communicator.org> > > <mailto:emcho@sip-communicator.org > <mailto:emcho@sip-communicator.org>>> wrote:
    >
    > Alan,
    >
    > Glad we are on the same page. Let's think about this some more
    and then
    > commit a draft after we branch.
    >
    > Cheers
    > Emil
    >
    > Alan Kelly wrote:
    > > Hi Emil,
    > >
    > > No worries, I haven't had time to work on it anyways, as
    > illustrated by
    > > my 6 week absence from this list :slight_smile:
    > >
    > > That sounds excellent to me, it's much more generic than the
    small set
    > > of capabilities I was imagining, but it's a better solution and
    > fits the
    > > cases I have in mind very well. The patch I sent out is
    really only a
    > > workaround.
    > >
    > > And I agree, with that kind of flexibility, it could be a
    very popular
    > > feature. I know I can see further applications for it in my
    projects.
    > >
    > > -Alan
    > >
    > >
    > > On Fri, May 15, 2009 at 10:57 AM, Emil Ivov
    > <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>>> wrote:
    > >
    > > Hey Alan,
    > >
    > > I apologize for the lag.
    > >
    > > As mentioned off-list I do think this is a great idea and we
    > can start
    > > working on it right after we branch. My only concern is
    making
    > sure the
    > > mechanism is generic enough and that it fits a reasonable
    > number of use
    > > cases.
    > >
    > > I am thinking for example that external plugins may also
    need to
    > > initiate requests and handle their responses. This would
    imply
    > exposing
    > > the transaction mechanism too, as well as the jain-sip
    > providers and
    > > factories. We would also have to give plugins the
    possibility to
    > > "consume" SIP messages (i.e. prevent the SIP provider from
    > processing
    > > them) ... a bit like what we are going to be doing with the
    > transform
    > > layers in the messaging operation sets.
    > >
    > > We could actually get there relatively easily. We'd simply
    > need to make
    > > sure that our sip provider package also exposts the
    javax.sip
    > interfaces
    > > from jain-sip and then also add the possibility to have SIP
    > message
    > > filter layers.
    > >
    > > This way we'd be able to handle the use case you describe as
    > well as
    > > virtually any other SIP based feature as a plugin.
    > >
    > > How does this sound?
    > >
    > > Cheers
    > > Emil
    > >
    > > P.S. I've added a corresponding entry in our road map as I
    > believe this
    > > is going to be a popular feature.
    > >
    > >
    > >
    > > Alan Kelly wrote:
    > > > Hi Lubo,
    > > >
    > > > Thanks for the response.
    > > >
    > > > I actually did post a patch, including a (very simplistic
    > and useless
    > > > implementation) back on 27 March, but I think it was
    > overlooked among
    > > > all the GSoC emails. I guess the attachment didn't make it
    > into my
    > > reply
    > > > message. Here it is again.
    > > >
    > > > I might be able to come up with some use cases for this.
    > > >
    > > > Thanks,
    > > >
    > > > Alan
    > > >
    > > > On Wed, May 13, 2009 at 5:15 PM, Lubomir Marinov
    > > > <lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>
    > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>>
    <mailto:lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com>
    > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>>>
    > > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>
    > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>>
    > > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>
    > <mailto:lubomir.marinov@gmail.com
    <mailto:lubomir.marinov@gmail.com>>>>> wrote:
    > > >
    > > > Hi Alan,
    > > >
    > > > I don't want to get in the way of Emil with respect to
    > this case
    > > > because I don't personally have a use case for the
    > > functionality in
    > > > question. But since you have, why not post a patch
    in this
    > > thread? I
    > > > mean that we may not have the use case right now
    but if it
    > > happens to
    > > > be of need later on, we could merge the patch into the
    > > repository at
    > > > that later time.
    > > >
    > > > Thank you for the contribution anyway,
    > > > Lubo
    > > >
    > > > On Wed, May 13, 2009 at 10:43 PM, Alan Kelly
    > > <akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
    <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>
    > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
    <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>>
    > > > <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>
    > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>
    > > <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>
    > <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>>>>> wrote:
    > > > > Can I get some feedback on this please? Thanks.
    > > > >
    > > > > On Fri, Mar 27, 2009 at 6:20 PM, Alan Kelly
    > > > <akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com> <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>>
    > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
    <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>>
    > > <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com> <mailto:akoriolesfan@gmail.com
    <mailto:akoriolesfan@gmail.com>>
    > <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>
    <mailto:akoriolesfan@gmail.com <mailto:akoriolesfan@gmail.com>>>>>
    wrote:
    > > > >>
    > > > >> Hi all,
    > > > >>
    > > > >> As a few of you know, I've been doing some work
    on a
    > > proprietary
    > > > SC plugin
    > > > >> for the company I'm interning with, and this means
    > I've been
    > > > taking a close
    > > > >> look at the extensibility options that SC has.
    Every so
    > > often, I
    > > > run into a
    > > > >> wall and think, gee, wouldn't it be nice if we
    could
    > allow SC
    > > > plugins to do
    > > > >> x. This is one of those cases.
    > > > >>
    > > > >> As part of the system that we're using SC with, we
    > need the
    > > > capability to
    > > > >> have a SIP client add custom headers to SIP INVITE
    > > messages. I've
    > > > written
    > > > >> some primitive code in SC that allows plugins to
    > register a
    > > header
    > > > >> (basically an object that stores Strings containing
    > the name,
    > > > value, and
    > > > >> associated protocol for the header) as an OSGi
    > service, and
    > > then
    > > > added some
    > > > >> code in OperationSetBasicTelephonySipImpl to search
    > for any
    > > > registered
    > > > >> plugin headers, and create and add Headers to
    the INVITE
    > > > accordingly. Please
    > > > >> see the attached code.
    > > > >>
    > > > >> Is this functionality something that would be
    useful
    > to include
    > > > in SC, or
    > > > >> is this a unique requirement? Emil and I discussed
    > this concept
    > > > briefly a
    > > > >> few weeks ago, and he recommended that I circulate
    > the proposed
    > > > interface to
    > > > >> get more feedback.
    > > > >>
    > > > >> Thanks,
    > > > >>
    > > > >> -Alan
    > > > >>
    > > > >
    > > > >
    > > >
    > > >
    > >
    >
    ---------------------------------------------------------------------
    > > > 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>>
    > > <mailto: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>>>
    > > >
    <mailto: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>>
    > > <mailto: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>>
    > > <mailto: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>>>
    > > > <mailto: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>>
    > > <mailto: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>
    > <mailto: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>
    > <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>>
    > > <mailto: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>>>
    > >
    > > --
    > > Emil Ivov, Ph.D. 30a rue de la
    > Patrie
    > > Project Lead 67300
    Schiltigheim
    > > SIP Communicator
    > > emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > <mailto:emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>>
    > > FAX: +33.1.77.62.47.31
    > > http://sip-communicator.org PHONE:
    > +33.1.77.62.43.30
    > >
    > >
    >
    ---------------------------------------------------------------------
    > > 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>>
    > > <mailto: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>>
    > > <mailto: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>>>
    > >
    > >
    >
    > --
    > Emil Ivov, Ph.D. 30a rue de la
    Patrie
    > Project Lead 67300 Schiltigheim
    > SIP Communicator
    > emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
    <mailto:emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>>
    > FAX: +33.1.77.62.47.31
    > http://sip-communicator.org PHONE:
    +33.1.77.62.43.30
    >
    >
    ---------------------------------------------------------------------
    > 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>>
    >
    >

    --
    Emil Ivov, Ph.D. 30a rue de la Patrie
    Project Lead 67300 Schiltigheim
    SIP Communicator
    emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                  FAX: +33.1.77.62.47.31
    http://sip-communicator.org PHONE: +33.1.77.62.43.30

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org FAX: +33.1.77.62.47.31
http://sip-communicator.org PHONE: +33.1.77.62.43.30

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