JAIN SLEE, openness, and owning your own applications and services - Linux

This is a discussion on JAIN SLEE, openness, and owning your own applications and services - Linux ; JAIN SLEE offers enormous advantages to anyone planning to run a telecoms network over more traditional NEP supplied equipment. The traditional NEP business model was very similar to that of other proprietary software and hardware vendors, like Microsoft and Cisco ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: JAIN SLEE, openness, and owning your own applications and services

  1. JAIN SLEE, openness, and owning your own applications and services

    JAIN SLEE offers enormous advantages to anyone planning to run a
    telecoms network over more traditional NEP supplied equipment. The
    traditional NEP business model was very similar to that of other
    proprietary software and hardware vendors, like Microsoft and Cisco and
    others, which centered on supplying vertically integrated devices, from
    hardware to east, west, north & southbound interfaces, and then ideally
    using "extended" protocols on the north, south, east and westbound
    interfaces in order to further lock-in to other devices.

    This approach, securing the interfaces when based on standards
    protocols, has been tagged "embrace and extend" by Microsoft, but there
    are plenty of other companies which do the same thing. A quick peek at
    Q.931 would suggest that signalling in C7 land should be simple, but in
    reality each major NEP had their own variation of C7/Q.931 INAP, just as
    manufacturers all have their own variation of SIP, so that eg., Cisco
    SIP is not very compatible with Siemens SIP, and so on.

    The upshot of all this is that, for example, if you buy a Switch from a
    particular vendor, let's call them EricsAlcatelMens, or EAS for short,
    so that we don't pick on any particular vendor, as and when we want to
    offer a particular kind of voice application, let's say it's a voice
    VPN, or an IVR system (press 1 for this, 2 for that, and so on), then we
    have to go to EAS for our SCP, *because* the only company which supports
    the particular /variant/ of INAP used by the EAS switch, is, guess who?
    EAS for the SCP.

    The result? you're completely locked to that particular vendor, you
    *have* to buy their SCP because it's the only one which will work for
    you because you have an EAS switch. The upshot? Well, the only
    platform on which applications can be developed is, wait for it...
    proprietary to EAS, so any applications use EAS proprietary functions,
    which means that, well, guess who owns the applications? You, the
    customer? Nah, don't be daft! They're owned by the vendor. You only
    get to rent them.

    The solution to the problem of owning your own applications, here, is
    JAIN SLEE. Why? Because even the /proprietary/ versions of JAIN SLEE
    (mobicents is an open-source version) have Resource Adaptors, RAs, which
    are customisable by anyone, including the customer. Their function is
    protocol adaption, and their impact is to ensure that at least one-end
    of a given protocol is on an open platform, so that no amount of
    "embrace and extend" can stop you, the customer, from owning your own
    applications rather than renting them from the vendor.

    It's very very important to be aware that the new generation of
    SIP-based vendors have not, in any way, solved this issue, if anything,
    it's worse than it ever was, because SIP is far less well specified than
    INAP, rather than more so. JAIN SLEE is your friend here, because it
    *also* supports SIP as well as C7/INAP, so applications which you
    develop will not only be compatible with any SSP (switch) you purchase
    from any vendor, they will also be compatible with any SIP-based session
    controller, too.

    Furthermore, by the careful definition of SDKs, it's possible to give
    access to network control capabilities from the JAIN SLEE to third
    parties from eg., internet-based access points. So, not only will you
    own your own applications, unlike in the traditional NEP world where you
    rented them from the vendor, you also have the opportunity to make
    access to *your* applications available to others, too.

    So, as I say in my .sig, "Open platforms prevent vendor lock-in. Own
    your own services!

    --
    | mark at ellandroad dot demon dot co dot uk |
    | Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
    | Cola trolls: http://colatrolls.blogspot.com/ |
    | Open platforms prevent vendor lock-in. Own your Own services! |


  2. Re: JAIN SLEE, openness, and owning your own applications and services

    Mark Kent espoused:
    > JAIN SLEE offers enormous advantages to anyone planning to run a
    > telecoms network over more traditional NEP supplied equipment. The
    > traditional NEP business model was very similar to that of other
    > proprietary software and hardware vendors, like Microsoft and Cisco and
    > others, which centered on supplying vertically integrated devices, from
    > hardware to east, west, north & southbound interfaces, and then ideally
    > using "extended" protocols on the north, south, east and westbound
    > interfaces in order to further lock-in to other devices.
    >
    > This approach, securing the interfaces when based on standards
    > protocols, has been tagged "embrace and extend" by Microsoft, but there
    > are plenty of other companies which do the same thing. A quick peek at
    > Q.931 would suggest that signalling in C7 land should be simple, but in
    > reality each major NEP had their own variation of C7/Q.931 INAP, just as
    > manufacturers all have their own variation of SIP, so that eg., Cisco
    > SIP is not very compatible with Siemens SIP, and so on.
    >
    > The upshot of all this is that, for example, if you buy a Switch from a
    > particular vendor, let's call them EricsAlcatelMens, or EAS for short,
    > so that we don't pick on any particular vendor, as and when we want to
    > offer a particular kind of voice application, let's say it's a voice
    > VPN, or an IVR system (press 1 for this, 2 for that, and so on), then we
    > have to go to EAS for our SCP, *because* the only company which supports
    > the particular /variant/ of INAP used by the EAS switch, is, guess who?
    > EAS for the SCP.
    >
    > The result? you're completely locked to that particular vendor, you
    > *have* to buy their SCP because it's the only one which will work for
    > you because you have an EAS switch. The upshot? Well, the only
    > platform on which applications can be developed is, wait for it...
    > proprietary to EAS, so any applications use EAS proprietary functions,
    > which means that, well, guess who owns the applications? You, the
    > customer? Nah, don't be daft! They're owned by the vendor. You only
    > get to rent them.
    >
    > The solution to the problem of owning your own applications, here, is
    > JAIN SLEE. Why? Because even the /proprietary/ versions of JAIN SLEE
    > (mobicents is an open-source version) have Resource Adaptors, RAs, which
    > are customisable by anyone, including the customer. Their function is
    > protocol adaption, and their impact is to ensure that at least one-end
    > of a given protocol is on an open platform, so that no amount of
    > "embrace and extend" can stop you, the customer, from owning your own
    > applications rather than renting them from the vendor.
    >
    > It's very very important to be aware that the new generation of
    > SIP-based vendors have not, in any way, solved this issue, if anything,
    > it's worse than it ever was, because SIP is far less well specified than
    > INAP, rather than more so. JAIN SLEE is your friend here, because it
    > *also* supports SIP as well as C7/INAP, so applications which you
    > develop will not only be compatible with any SSP (switch) you purchase
    > from any vendor, they will also be compatible with any SIP-based session
    > controller, too.
    >
    > Furthermore, by the careful definition of SDKs, it's possible to give
    > access to network control capabilities from the JAIN SLEE to third
    > parties from eg., internet-based access points. So, not only will you
    > own your own applications, unlike in the traditional NEP world where you
    > rented them from the vendor, you also have the opportunity to make
    > access to *your* applications available to others, too.
    >
    > So, as I say in my .sig, "Open platforms prevent vendor lock-in. Own
    > your own services!
    >


    Amazing. All that criticism for pointing out that JAIN SLEE permits
    openness and moves away from 3rd parties owning your applications, so I
    post about it, and guess what, not a single response.

    I wonder why?

    Anyone wanting to know more about JAIN SLEE will find several vendors on
    the web, both proprietary and open source-based. It'll also become
    clear that a linkage to JBOSS makes quite a lot of sense, too.

    Remember - open platforms reduce vendor lock-in!

    --
    | mark at ellandroad dot demon dot co dot uk |
    | Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
    | Cola trolls: http://colatrolls.blogspot.com/ |
    | Open platforms prevent vendor lock-in. Own your Own services! |


  3. Re: JAIN SLEE, openness, and owning your own applications and services

    Mark Kent espoused:
    > Mark Kent espoused:
    >> JAIN SLEE offers enormous advantages to anyone planning to run a
    >> telecoms network over more traditional NEP supplied equipment. The
    >> traditional NEP business model was very similar to that of other
    >> proprietary software and hardware vendors, like Microsoft and Cisco and
    >> others, which centered on supplying vertically integrated devices, from
    >> hardware to east, west, north & southbound interfaces, and then ideally
    >> using "extended" protocols on the north, south, east and westbound
    >> interfaces in order to further lock-in to other devices.
    >>
    >> This approach, securing the interfaces when based on standards
    >> protocols, has been tagged "embrace and extend" by Microsoft, but there
    >> are plenty of other companies which do the same thing. A quick peek at
    >> Q.931 would suggest that signalling in C7 land should be simple, but in
    >> reality each major NEP had their own variation of C7/Q.931 INAP, just as
    >> manufacturers all have their own variation of SIP, so that eg., Cisco
    >> SIP is not very compatible with Siemens SIP, and so on.
    >>
    >> The upshot of all this is that, for example, if you buy a Switch from a
    >> particular vendor, let's call them EricsAlcatelMens, or EAS for short,
    >> so that we don't pick on any particular vendor, as and when we want to
    >> offer a particular kind of voice application, let's say it's a voice
    >> VPN, or an IVR system (press 1 for this, 2 for that, and so on), then we
    >> have to go to EAS for our SCP, *because* the only company which supports
    >> the particular /variant/ of INAP used by the EAS switch, is, guess who?
    >> EAS for the SCP.
    >>
    >> The result? you're completely locked to that particular vendor, you
    >> *have* to buy their SCP because it's the only one which will work for
    >> you because you have an EAS switch. The upshot? Well, the only
    >> platform on which applications can be developed is, wait for it...
    >> proprietary to EAS, so any applications use EAS proprietary functions,
    >> which means that, well, guess who owns the applications? You, the
    >> customer? Nah, don't be daft! They're owned by the vendor. You only
    >> get to rent them.
    >>
    >> The solution to the problem of owning your own applications, here, is
    >> JAIN SLEE. Why? Because even the /proprietary/ versions of JAIN SLEE
    >> (mobicents is an open-source version) have Resource Adaptors, RAs, which
    >> are customisable by anyone, including the customer. Their function is
    >> protocol adaption, and their impact is to ensure that at least one-end
    >> of a given protocol is on an open platform, so that no amount of
    >> "embrace and extend" can stop you, the customer, from owning your own
    >> applications rather than renting them from the vendor.
    >>
    >> It's very very important to be aware that the new generation of
    >> SIP-based vendors have not, in any way, solved this issue, if anything,
    >> it's worse than it ever was, because SIP is far less well specified than
    >> INAP, rather than more so. JAIN SLEE is your friend here, because it
    >> *also* supports SIP as well as C7/INAP, so applications which you
    >> develop will not only be compatible with any SSP (switch) you purchase
    >> from any vendor, they will also be compatible with any SIP-based session
    >> controller, too.
    >>
    >> Furthermore, by the careful definition of SDKs, it's possible to give
    >> access to network control capabilities from the JAIN SLEE to third
    >> parties from eg., internet-based access points. So, not only will you
    >> own your own applications, unlike in the traditional NEP world where you
    >> rented them from the vendor, you also have the opportunity to make
    >> access to *your* applications available to others, too.
    >>
    >> So, as I say in my .sig, "Open platforms prevent vendor lock-in. Own
    >> your own services!
    >>

    >
    > Amazing. All that criticism for pointing out that JAIN SLEE permits
    > openness and moves away from 3rd parties owning your applications, so I
    > post about it, and guess what, not a single response.
    >
    > I wonder why?
    >
    > Anyone wanting to know more about JAIN SLEE will find several vendors on
    > the web, both proprietary and open source-based. It'll also become
    > clear that a linkage to JBOSS makes quite a lot of sense, too.
    >
    > Remember - open platforms reduce vendor lock-in!
    >


    Hmm, still nobody wishes to "expose" this, then?

    --
    | mark at ellandroad dot demon dot co dot uk |
    | Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
    | Cola trolls: http://colatrolls.blogspot.com/ |
    | Open platforms prevent vendor lock-in. Own your Own services! |


  4. Re: JAIN SLEE, openness, and owning your own applications and services

    On Thu, 7 Aug 2008 08:47:35 +0100, Mark Kent wrote:

    > Mark Kent espoused:
    >> Mark Kent espoused:
    >>> JAIN SLEE offers enormous advantages to anyone planning to run a
    >>> telecoms network over more traditional NEP supplied equipment. The
    >>> traditional NEP business model was very similar to that of other
    >>> proprietary software and hardware vendors, like Microsoft and Cisco and
    >>> others, which centered on supplying vertically integrated devices, from
    >>> hardware to east, west, north & southbound interfaces, and then ideally
    >>> using "extended" protocols on the north, south, east and westbound
    >>> interfaces in order to further lock-in to other devices.
    >>>
    >>> This approach, securing the interfaces when based on standards
    >>> protocols, has been tagged "embrace and extend" by Microsoft, but there
    >>> are plenty of other companies which do the same thing. A quick peek at
    >>> Q.931 would suggest that signalling in C7 land should be simple, but in
    >>> reality each major NEP had their own variation of C7/Q.931 INAP, just as
    >>> manufacturers all have their own variation of SIP, so that eg., Cisco
    >>> SIP is not very compatible with Siemens SIP, and so on.
    >>>
    >>> The upshot of all this is that, for example, if you buy a Switch from a
    >>> particular vendor, let's call them EricsAlcatelMens, or EAS for short,
    >>> so that we don't pick on any particular vendor, as and when we want to
    >>> offer a particular kind of voice application, let's say it's a voice
    >>> VPN, or an IVR system (press 1 for this, 2 for that, and so on), then we
    >>> have to go to EAS for our SCP, *because* the only company which supports
    >>> the particular /variant/ of INAP used by the EAS switch, is, guess who?
    >>> EAS for the SCP.
    >>>
    >>> The result? you're completely locked to that particular vendor, you
    >>> *have* to buy their SCP because it's the only one which will work for
    >>> you because you have an EAS switch. The upshot? Well, the only
    >>> platform on which applications can be developed is, wait for it...
    >>> proprietary to EAS, so any applications use EAS proprietary functions,
    >>> which means that, well, guess who owns the applications? You, the
    >>> customer? Nah, don't be daft! They're owned by the vendor. You only
    >>> get to rent them.
    >>>
    >>> The solution to the problem of owning your own applications, here, is
    >>> JAIN SLEE. Why? Because even the /proprietary/ versions of JAIN SLEE
    >>> (mobicents is an open-source version) have Resource Adaptors, RAs, which
    >>> are customisable by anyone, including the customer. Their function is
    >>> protocol adaption, and their impact is to ensure that at least one-end
    >>> of a given protocol is on an open platform, so that no amount of
    >>> "embrace and extend" can stop you, the customer, from owning your own
    >>> applications rather than renting them from the vendor.
    >>>
    >>> It's very very important to be aware that the new generation of
    >>> SIP-based vendors have not, in any way, solved this issue, if anything,
    >>> it's worse than it ever was, because SIP is far less well specified than
    >>> INAP, rather than more so. JAIN SLEE is your friend here, because it
    >>> *also* supports SIP as well as C7/INAP, so applications which you
    >>> develop will not only be compatible with any SSP (switch) you purchase
    >>> from any vendor, they will also be compatible with any SIP-based session
    >>> controller, too.
    >>>
    >>> Furthermore, by the careful definition of SDKs, it's possible to give
    >>> access to network control capabilities from the JAIN SLEE to third
    >>> parties from eg., internet-based access points. So, not only will you
    >>> own your own applications, unlike in the traditional NEP world where you
    >>> rented them from the vendor, you also have the opportunity to make
    >>> access to *your* applications available to others, too.
    >>>
    >>> So, as I say in my .sig, "Open platforms prevent vendor lock-in. Own
    >>> your own services!
    >>>

    >>
    >> Amazing. All that criticism for pointing out that JAIN SLEE permits
    >> openness and moves away from 3rd parties owning your applications, so I
    >> post about it, and guess what, not a single response.
    >>
    >> I wonder why?
    >>
    >> Anyone wanting to know more about JAIN SLEE will find several vendors on
    >> the web, both proprietary and open source-based. It'll also become
    >> clear that a linkage to JBOSS makes quite a lot of sense, too.
    >>
    >> Remember - open platforms reduce vendor lock-in!
    >>

    >
    > Hmm, still nobody wishes to "expose" this, then?


    The reason you got no replies is because you are boring us to death.......
    Mark Kent.

    --
    Moshe Goldfarb
    Collector of soaps from around the globe.
    Please visit The Hall of Linux Idiots:
    http://linuxidiots.blogspot.com/

  5. Re: JAIN SLEE, openness, and owning your own applications andservices

    On Aug 7, 11:11*am, "Moshe Goldfarb." wrote:
    > On Thu, 7 Aug 2008 08:47:35 +0100, Mark Kent wrote:
    > > Mark Kent espoused:
    > >> Mark Kent espoused:
    > >>> JAIN SLEE offers enormous advantages to anyone planning to run a
    > >>> telecoms network over more traditional NEP supplied equipment. *The
    > >>> traditional NEP business model was very similar to that of other
    > >>> proprietary software and hardware vendors, like Microsoft and Cisco and
    > >>> others, which centered on supplying vertically integrated devices, from
    > >>> hardware to east, west, north & southbound interfaces, and then ideally
    > >>> using "extended" protocols on the north, south, east and westbound
    > >>> interfaces in order to further lock-in to other devices.

    >
    > >>> This approach, securing the interfaces when based on standards
    > >>> protocols, has been tagged "embrace and extend" by Microsoft, but there
    > >>> are plenty of other companies which do the same thing. *A quick peek at
    > >>> Q.931 would suggest that signalling in C7 land should be simple, but in
    > >>> reality each major NEP had their own variation of C7/Q.931 INAP, justas
    > >>> manufacturers all have their own variation of SIP, so that eg., Cisco
    > >>> SIP is not very compatible with Siemens SIP, and so on.

    >
    > >>> The upshot of all this is that, for example, if you buy a Switch froma
    > >>> particular vendor, let's call them EricsAlcatelMens, or EAS for short,
    > >>> so that we don't pick on any particular vendor, as and when we want to
    > >>> offer a particular kind of voice application, let's say it's a voice
    > >>> VPN, or an IVR system (press 1 for this, 2 for that, and so on), thenwe
    > >>> have to go to EAS for our SCP, *because* the only company which supports
    > >>> the particular /variant/ of INAP used by the EAS switch, is, guess who?
    > >>> EAS for the SCP.

    >
    > >>> The result? *you're completely locked to that particular vendor, you
    > >>> *have* to buy their SCP because it's the only one which will work for
    > >>> you because you have an EAS switch. *The upshot? *Well, the only
    > >>> platform on which applications can be developed is, wait for it...
    > >>> proprietary to EAS, so any applications use EAS proprietary functions,
    > >>> which means that, well, guess who owns the applications? *You, the
    > >>> customer? *Nah, don't be daft! *They're owned by the vendor. *You only
    > >>> get to rent them.

    >
    > >>> The solution to the problem of owning your own applications, here, is
    > >>> JAIN SLEE. *Why? *Because even the /proprietary/ versions of JAINSLEE
    > >>> (mobicents is an open-source version) have Resource Adaptors, RAs, which
    > >>> are customisable by anyone, including the customer. *Their functionis
    > >>> protocol adaption, and their impact is to ensure that at least one-end
    > >>> of a given protocol is on an open platform, so that no amount of
    > >>> "embrace and extend" can stop you, the customer, from owning your own
    > >>> applications rather than renting them from the vendor.

    >
    > >>> It's very very important to be aware that the new generation of
    > >>> SIP-based vendors have not, in any way, solved this issue, if anything,
    > >>> it's worse than it ever was, because SIP is far less well specified than
    > >>> INAP, rather than more so. *JAIN SLEE is your friend here, because it
    > >>> *also* supports SIP as well as C7/INAP, so applications which you
    > >>> develop will not only be compatible with any SSP (switch) you purchase
    > >>> from any vendor, they will also be compatible with any SIP-based session
    > >>> controller, too.

    >
    > >>> Furthermore, by the careful definition of SDKs, it's possible to give
    > >>> access to network control capabilities from the JAIN SLEE to third
    > >>> parties from eg., internet-based access points. *So, not only will you
    > >>> own your own applications, unlike in the traditional NEP world where you
    > >>> rented them from the vendor, you also have the opportunity to make
    > >>> access to *your* applications available to others, too.

    >
    > >>> So, as I say in my .sig, "Open platforms prevent vendor lock-in. *Own
    > >>> your own services!

    >
    > >> Amazing. *All that criticism for pointing out that JAIN SLEE permits
    > >> openness and moves away from 3rd parties owning your applications, so I
    > >> post about it, and guess what, not a single response.

    >
    > >> I wonder why?

    >
    > >> Anyone wanting to know more about JAIN SLEE will find several vendors on
    > >> the web, both proprietary and open source-based. *It'll also become
    > >> clear that a linkage to JBOSS makes quite a lot of sense, too.

    >
    > >> Remember - open platforms reduce vendor lock-in!

    >
    > > Hmm, still nobody wishes to "expose" this, then?

    >
    > The reason you got no replies is because you are boring us to death........
    > Mark Kent.
    >


    :: JAIN SLEE offers enormous advantages to anyone planning to run a
    :: telecoms network over more traditional NEP supplied equipment.

    Is this the same as that open source mobile phone software, that
    can't
    reliable make one call?

  6. Re: JAIN SLEE, openness, and owning your own applications and services

    On Thu, 7 Aug 2008 10:59:26 -0700 (PDT), Psyc Geek (TAB) wrote:

    > On Aug 7, 11:11*am, "Moshe Goldfarb." wrote:
    >> On Thu, 7 Aug 2008 08:47:35 +0100, Mark Kent wrote:
    >>> Mark Kent espoused:
    >>>> Mark Kent espoused:
    >>>>> JAIN SLEE offers enormous advantages to anyone planning to run a
    >>>>> telecoms network over more traditional NEP supplied equipment. *The
    >>>>> traditional NEP business model was very similar to that of other
    >>>>> proprietary software and hardware vendors, like Microsoft and Cisco and
    >>>>> others, which centered on supplying vertically integrated devices, from
    >>>>> hardware to east, west, north & southbound interfaces, and then ideally
    >>>>> using "extended" protocols on the north, south, east and westbound
    >>>>> interfaces in order to further lock-in to other devices.

    >>
    >>>>> This approach, securing the interfaces when based on standards
    >>>>> protocols, has been tagged "embrace and extend" by Microsoft, but there
    >>>>> are plenty of other companies which do the same thing. *A quick peek at
    >>>>> Q.931 would suggest that signalling in C7 land should be simple, but in
    >>>>> reality each major NEP had their own variation of C7/Q.931 INAP, just as
    >>>>> manufacturers all have their own variation of SIP, so that eg., Cisco
    >>>>> SIP is not very compatible with Siemens SIP, and so on.

    >>
    >>>>> The upshot of all this is that, for example, if you buy a Switch from a
    >>>>> particular vendor, let's call them EricsAlcatelMens, or EAS for short,
    >>>>> so that we don't pick on any particular vendor, as and when we want to
    >>>>> offer a particular kind of voice application, let's say it's a voice
    >>>>> VPN, or an IVR system (press 1 for this, 2 for that, and so on), then we
    >>>>> have to go to EAS for our SCP, *because* the only company which supports
    >>>>> the particular /variant/ of INAP used by the EAS switch, is, guess who?
    >>>>> EAS for the SCP.

    >>
    >>>>> The result? *you're completely locked to that particular vendor, you
    >>>>> *have* to buy their SCP because it's the only one which will work for
    >>>>> you because you have an EAS switch. *The upshot? *Well, the only
    >>>>> platform on which applications can be developed is, wait for it...
    >>>>> proprietary to EAS, so any applications use EAS proprietary functions,
    >>>>> which means that, well, guess who owns the applications? *You, the
    >>>>> customer? *Nah, don't be daft! *They're owned by the vendor. *You only
    >>>>> get to rent them.

    >>
    >>>>> The solution to the problem of owning your own applications, here, is
    >>>>> JAIN SLEE. *Why? *Because even the /proprietary/ versions of JAIN SLEE
    >>>>> (mobicents is an open-source version) have Resource Adaptors, RAs, which
    >>>>> are customisable by anyone, including the customer. *Their function is
    >>>>> protocol adaption, and their impact is to ensure that at least one-end
    >>>>> of a given protocol is on an open platform, so that no amount of
    >>>>> "embrace and extend" can stop you, the customer, from owning your own
    >>>>> applications rather than renting them from the vendor.

    >>
    >>>>> It's very very important to be aware that the new generation of
    >>>>> SIP-based vendors have not, in any way, solved this issue, if anything,
    >>>>> it's worse than it ever was, because SIP is far less well specified than
    >>>>> INAP, rather than more so. *JAIN SLEE is your friend here, because it
    >>>>> *also* supports SIP as well as C7/INAP, so applications which you
    >>>>> develop will not only be compatible with any SSP (switch) you purchase
    >>>>> from any vendor, they will also be compatible with any SIP-based session
    >>>>> controller, too.

    >>
    >>>>> Furthermore, by the careful definition of SDKs, it's possible to give
    >>>>> access to network control capabilities from the JAIN SLEE to third
    >>>>> parties from eg., internet-based access points. *So, not only will you
    >>>>> own your own applications, unlike in the traditional NEP world where you
    >>>>> rented them from the vendor, you also have the opportunity to make
    >>>>> access to *your* applications available to others, too.

    >>
    >>>>> So, as I say in my .sig, "Open platforms prevent vendor lock-in. *Own
    >>>>> your own services!

    >>
    >>>> Amazing. *All that criticism for pointing out that JAIN SLEE permits
    >>>> openness and moves away from 3rd parties owning your applications, so I
    >>>> post about it, and guess what, not a single response.

    >>
    >>>> I wonder why?

    >>
    >>>> Anyone wanting to know more about JAIN SLEE will find several vendors on
    >>>> the web, both proprietary and open source-based. *It'll also become
    >>>> clear that a linkage to JBOSS makes quite a lot of sense, too.

    >>
    >>>> Remember - open platforms reduce vendor lock-in!

    >>
    >>> Hmm, still nobody wishes to "expose" this, then?

    >>
    >> The reason you got no replies is because you are boring us to death.......
    >> Mark Kent.
    >>

    >
    >:: JAIN SLEE offers enormous advantages to anyone planning to run a
    >:: telecoms network over more traditional NEP supplied equipment.
    >
    > Is this the same as that open source mobile phone software, that
    > can't
    > reliable make one call?


    Can't say...
    I started to read Mark Kent's original post and fell asleep.

    --
    Moshe Goldfarb
    Collector of soaps from around the globe.
    Please visit The Hall of Linux Idiots:
    http://linuxidiots.blogspot.com/

+ Reply to Thread