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

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

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

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.

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

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.