Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie
Hei Nhadie,
i think there are some classifications which has to be made: SER is a software for signalling which is not responsible for media processing. You can couple Asterisk with SER if you want to enhance your services with Voicemails, announcements and conferences. Hence asterisk is not the only open souce solution (see SEMS from iptel) for that.
Greetz,
On 23.08.2007, Thursday 07:23:42PM +0800, Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote:
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hmm,
I find the dialog I initiated both amusing and (for me) very informative. Being pretty new to these lists, I'm evaluating technology to use for an ITSP setup and I'll welcome more comments and views as the ones below - they help me understand "what to use for which purpose".
What my needs are: 1.. Prepaid support - maybe I don't need a b2bua, could the dialogue module be "call-aware" and be used to terminate calls upon "end-of-credits"? 2.. Filtering of Refer & Replace (RFCs 3515, 3891, 3892), replacing them with Re-Inivtes - to support most UAs, at the same being compliant with SIP trunks supporting SIPConnect 3.. IVR capability - i.e. "regular IVR" (customized stuff) as well as standard applications (voicemail, conference) 4.. Queuing of calls 5.. 3pcc - capability for handling calls from a operator's application
Anyone wanting to advise?
BR///
Fredrik
----- Original Message ----- From: Greger V. Teigre To: SIP Cc: Fredrik Lundmark ; serusers@lists.iptel.org Sent: Friday, August 24, 2007 9:27 AM Subject: Re: [Serusers] why combine ser with asterisk
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote: Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote: I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote: Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I don't like all this cross-posting, so I have removed the other lists. My comments will be from iptel.org perspective. Inline.
Fredrik Lundmark wrote:
Hmm,I find the dialog I initiated both amusing and (for me) very informative. Being pretty new to these lists, I'm evaluating technology to use for an ITSP setup and I'll welcome more comments and views as the ones below - they help me understand "what to use for which purpose".
What my needs are:
- Prepaid support - maybe I don't need a b2bua, could the dialogue module be "call-aware" and be used to terminate calls upon "end-of-credits"?
Either you need a b2bua where you also proxy the rtp stream or you need to accept that you get "hung" calls (i.e. BYEs never hitting your box) due to various reasons, for example UA power failure. OpenSER has dialog-statefulness like the one you are looking for. iptel.org users tend to lean towards: it's a telco-problem, fix it in the telco-world (using ex. Session-Timers or timing the PSTN calls in the gateways) or go the full line, use a b2bua. I believe there's a calling card app in sems that you can use/adapt.
- Filtering of Refer & Replace (RFCs 3515, 3891, 3892), replacing them with Re-Inivtes - to support most UAs, at the same being compliant with SIP trunks supporting SIPConnect
Now, for this you "need" a b2bua to be compliant in all scenarios. I know some people have successfully caught 302s from UAs, then instead of sending the reply back, append a branch with the ruri in the Diversion header. Doing more than that is generally considered "fixing broken UAs" and the general advice is "don't support it". You are quickly getting yourself into a situation where supporting 2% of your user base, takes 80% of your maintenance costs.
- IVR capability - i.e. "regular IVR" (customized stuff) as well as standard applications (voicemail, conference)
Here people split between asterisk, sems, and commercial. Sems can do some simple stuff right out of the box, but you will probably have to do some coding for what you need. Asterisk is more likely to give you more out of the box, but if you still need adaptation, you will find it more time-consuming adapting asterisk.
- Queuing of calls
Well, as in "please hold, we will pick up the call whenever we feel like it" ? This is a pbx or a call center application.
- 3pcc - capability for handling calls from a operator's application
Simple 3pcc can be done in SER, while many/most call flows require a b2bua. SEMS gives you quite a lot of power, but I have no experience in using sems in this area. You should probably look at what IETF BLISS working group is doing.
Anyone wanting to advise?
I hope it helps. g-)
BR///
Fredrik
----- Original Message ----- *From:* Greger V. Teigre mailto:greger@teigre.com *To:* SIP mailto:sip@arcdiv.com *Cc:* Fredrik Lundmark mailto:fredrik@dimi.se ; serusers@lists.iptel.org mailto:serusers@lists.iptel.org *Sent:* Friday, August 24, 2007 9:27 AM *Subject:* Re: [Serusers] why combine ser with asterisk
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote:
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hello Fredrik,
Fredrik Lundmark wrote:
Hmm,I find the dialog I initiated both amusing and (for me) very informative. Being pretty new to these lists, I'm evaluating technology to use for an ITSP setup and I'll welcome more comments and views as the ones below - they help me understand "what to use for which purpose".
What my needs are:
- Prepaid support - maybe I don't need a b2bua, could the dialogue module be "call-aware" and be used to terminate calls upon "end-of-credits"?
- Filtering of Refer & Replace (RFCs 3515, 3891, 3892), replacing them with Re-Inivtes - to support most UAs, at the same being compliant with SIP trunks supporting SIPConnect
- IVR capability - i.e. "regular IVR" (customized stuff) as well as standard applications (voicemail, conference)
- Queuing of calls
- 3pcc - capability for handling calls from a operator's application
Anyone wanting to advise?
adding my general two cents to what already has been mentioned, I would want to note that it also depends quite a lot on how big the setup is you are doing, how deep you are in the technology, and how much you are willing/able to implement and customize yourself.
If you only want to use SEMS as *user* without going at times into the code, I can recommend it only for the basic applications (announcements, pre-call announcements, voicemail, simple conference bridge) that come with it. SEMS has been deployed as components serving these in large setups at carriers, ITSPs and other sites alike for years showing quite good stability and performance. For those applications I guess that you are in total better off with SEMS than with asterisk.
While you have the core capabilities, there are no PBX-like applications with SEMS to work as is out of the box. For those, and/or if you need other channel types than SIP, you have asterisk (or freeswitch, for that matter) with all its universe of applications and customizations.
As has been mentioned, if you want to use SEMS for more complex applications and call-flows involving media, you will need to be able to read the code and the examples along with the available docs, and I think doing this, reading the tutorial and the standard modules' and examples' source, gives you a quite good impression about the capabilities and the style of implementing applications in SEMS. And then, some people also reported that its not too hard or time-consuming to get to the point where you are able to implement your custom application (see e.g. http://lists.iptel.org/pipermail/semsdev/2007-May/001456.html).
Regards Stefan
BR///
Fredrik
That's actially a good analogy, Greger... The pickup truck is powerful, able to be used for many applications, and once you own one, everyone suddenly wants you around when they need some work done, whereas the Porsche is built for speed, is cramped, can't carry much, and is too expensive for any practical people to ever really purchase. ;)
Mind you, that being said, we do all our conferences in SEMS. It's actually a metric ton easier to set up for conferencing than Asterisk (WHY is it you need a Zaptel timing interface for audio mixing, again?), can support massively more users (especially if some are in listen-only mode), and 'Just works.'
N.
Greger V. Teigre wrote:
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote:
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
:-) so, we agree then... As a side-note: iptel.org projects have a tendency to be directed towards professionals. This has among other things, the implications that conforming to standards is very important and that flexibility in what you can do is more important than how simple it is to set up. g-)
SIP wrote:
That's actially a good analogy, Greger... The pickup truck is powerful, able to be used for many applications, and once you own one, everyone suddenly wants you around when they need some work done, whereas the Porsche is built for speed, is cramped, can't carry much, and is too expensive for any practical people to ever really purchase. ;)
Mind you, that being said, we do all our conferences in SEMS. It's actually a metric ton easier to set up for conferencing than Asterisk (WHY is it you need a Zaptel timing interface for audio mixing, again?), can support massively more users (especially if some are in listen-only mode), and 'Just works.'
N.
Greger V. Teigre wrote:
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote:
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
No offense, but that's a pretty short-sighted way of looking at things. Having worked in the computer business for almost two decades, I can assure you, businesses don't use/buy products, no matter HOW stable they are, if the total cost of ownership or production is too high -- this includes buildout costs, development, maintenance, AND deployment.
If you build a product that's super-stable and super-fast, but difficult, time consuming, or expensive to deploy, people will opt for a different solution. That's just the way business works.
Take Cray Supercomputers as a prime example. Seymour Cray built this fantastic supercomputer architecture, but didn't build any peripherals for it or even an operating system, assuming that, if people had the raw speed and power available, they'd be eager to use it even if they had to build their own hardware/software. Eventually, after three tries at three different companies, all with this same goal (he kept being forced out of his own companies for his short-sighted and poor business ideas), Seymour Cray's own company went bankrupt because people refused to buy computers that were difficult to deploy, even if they were extremely fast.
Conforming to standards is good. Flexibility is also very good. But ignoring things like ease of deployment (or *cough* documentation) is basically just thumbing your nose at the people who actually use the software. ;)
That being said, I do love the SER project, and I think SEMS has incredible potential, but none of that will matter in the long run if it's not made easy for people to use. One of the reasons so many people go with things like Asterisk and then try and make it work like a SIP proxy (which causes headaches galore) is because Asterisk is incredibly easy to deploy, exceptionally well-documented, and has third-party modules galore integrated into it to allow people to do all sorts of things. SER and SEMS combined, on the other hand, while fast, powerful, and a fully-featured SIP proxy/Media server combination, has sparse documentation, is absolutely painful to deploy, and has only the very basic few modules along with it, requiring that, for many features, you write the module yourself.
While I would FAR prefer the core SER coders to continue their work on making SER the stable, fast product it is, and in piecing together all the SIP RFC weirdness into an actual product, SER/SEMS could not go wrong by recruiting some more people to write modules, by making the install create basic configs that work out of the box, and by having detailed and clean documentation. I'd offer my services, but my C/C++ coding is laughable at best (it's been 15 years since I've done any real C coding), and I honestly understand so little of the SER 2.0 stuff that my writing documentation for it would be very BAD Idea (TM). If someone (i.e. a coder who knows what's actually going on) were to write framework documentation (much like the very sparse framework docs that exist in the modules), however, I'd be happy to take a crack at making it human-readable.
N.
Greger V. Teigre wrote:
:-) so, we agree then... As a side-note: iptel.org projects have a tendency to be directed towards professionals. This has among other things, the implications that conforming to standards is very important and that flexibility in what you can do is more important than how simple it is to set up. g-)
SIP wrote:
That's actially a good analogy, Greger... The pickup truck is powerful, able to be used for many applications, and once you own one, everyone suddenly wants you around when they need some work done, whereas the Porsche is built for speed, is cramped, can't carry much, and is too expensive for any practical people to ever really purchase. ;)
Mind you, that being said, we do all our conferences in SEMS. It's actually a metric ton easier to set up for conferencing than Asterisk (WHY is it you need a Zaptel timing interface for audio mixing, again?), can support massively more users (especially if some are in listen-only mode), and 'Just works.'
N.
Greger V. Teigre wrote:
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote:
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
> Hi All, > > What's the advantage of combining ser with asterisk? I always see > comments like using ser with asterisk is a very good solution etc. etc. > the thing i liked with ser is that it does not do codec translation, > which saves me cpu usage and also bandwidth. if i combine it with > asterisk, would it not use codec translation? > > i also read that there is also a problem when ser and asterisk is > run on > the same machine, why is it so? > if use prepaid billing solution for asterisk like astcc, would i > then be > able to provide prepaid service? > > soryy for asking too much, i'd just like to really understand it. Thank > You in advanced. > > Regards, > Nhadie > _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
SIP wrote:
<snip>
Take Cray Supercomputers as a prime example. Seymour Cray built this fantastic supercomputer architecture, but didn't build any peripherals for it or even an operating system, assuming that, if people had the raw speed and power available, they'd be eager to use it even if they had to build their own hardware/software.
Yes, Seymour liked to code in machine language right from the console and the O/Ses for his machines developed 'organically' from the bottom up in general, but wouldn't you consider SCOPE, KRONOS, NOS etc. operating systems? And as for hardware, the CDC peripherals and Hyperchannel offerings seemed to be the best in the industry on Cray CPUs...
Regards,
Michael
SIP wrote:
things. SER and SEMS combined, on the other hand, while fast, powerful, and a fully-featured SIP proxy/Media server combination, has sparse documentation, is absolutely painful to deploy, and has only the very basic few modules along with it, requiring that, for many features, you write the module yourself.
While I would FAR prefer the core SER coders to continue their work on making SER the stable, fast product it is, and in piecing together all the SIP RFC weirdness into an actual product, SER/SEMS could not go wrong by recruiting some more people to write modules, by making the install create basic configs that work out of the box, and by having detailed and clean documentation. I'd offer my services, but my C/C++
I fully agree. so far though we have received no single application module contribution for SEMS apart from juha's announcement from DB, and with one other exception practically not any line of documentation contributed. obviously not good management from our/my side, as from some discussions on semsdev you can see that people are implementing their apps with SEMS (with, I'd like to add, not the worst support). so, any good advice on how to make that better?
S.
Heheh, I really got you going, there, didn't I?! ;-) I'm afraid you read too much into my comment there, and I think you know that I agree with you by looking at what I have focused on. My comment was really aimed at type of features, i.e. priorities in what to add. Regardless of who is using SER, the reality is that SER's development is driven by users and developers who do SIP for a living and mostly within large-scale setups, not SMB, not small setup, not SIP service provider-DIY-in-a-box people. Thus, robust TLS support is prioritized, not UAC digest authentication. And no, making it easy to change From headers is not prioritized.
That being said on the feature side, now the "make it simple for the user side", Alfred Heggestad and I are working on SER Getting Started for SER 2.0 with a whole lot of features and where features can be selected from a list, and by using the m4 buildsystem, a ready-to-go config is generated. We plan to create a web front-end as well.
Watch cvs -r rel_2_0_0 for updates and we appreciate any testing and feedback we can get. g-)
SIP wrote:
No offense, but that's a pretty short-sighted way of looking at things. Having worked in the computer business for almost two decades, I can assure you, businesses don't use/buy products, no matter HOW stable they are, if the total cost of ownership or production is too high -- this includes buildout costs, development, maintenance, AND deployment.
If you build a product that's super-stable and super-fast, but difficult, time consuming, or expensive to deploy, people will opt for a different solution. That's just the way business works.
Take Cray Supercomputers as a prime example. Seymour Cray built this fantastic supercomputer architecture, but didn't build any peripherals for it or even an operating system, assuming that, if people had the raw speed and power available, they'd be eager to use it even if they had to build their own hardware/software. Eventually, after three tries at three different companies, all with this same goal (he kept being forced out of his own companies for his short-sighted and poor business ideas), Seymour Cray's own company went bankrupt because people refused to buy computers that were difficult to deploy, even if they were extremely fast.
Conforming to standards is good. Flexibility is also very good. But ignoring things like ease of deployment (or *cough* documentation) is basically just thumbing your nose at the people who actually use the software. ;)
That being said, I do love the SER project, and I think SEMS has incredible potential, but none of that will matter in the long run if it's not made easy for people to use. One of the reasons so many people go with things like Asterisk and then try and make it work like a SIP proxy (which causes headaches galore) is because Asterisk is incredibly easy to deploy, exceptionally well-documented, and has third-party modules galore integrated into it to allow people to do all sorts of things. SER and SEMS combined, on the other hand, while fast, powerful, and a fully-featured SIP proxy/Media server combination, has sparse documentation, is absolutely painful to deploy, and has only the very basic few modules along with it, requiring that, for many features, you write the module yourself.
While I would FAR prefer the core SER coders to continue their work on making SER the stable, fast product it is, and in piecing together all the SIP RFC weirdness into an actual product, SER/SEMS could not go wrong by recruiting some more people to write modules, by making the install create basic configs that work out of the box, and by having detailed and clean documentation. I'd offer my services, but my C/C++ coding is laughable at best (it's been 15 years since I've done any real C coding), and I honestly understand so little of the SER 2.0 stuff that my writing documentation for it would be very BAD Idea (TM). If someone (i.e. a coder who knows what's actually going on) were to write framework documentation (much like the very sparse framework docs that exist in the modules), however, I'd be happy to take a crack at making it human-readable.
N.
Greger V. Teigre wrote:
:-) so, we agree then... As a side-note: iptel.org projects have a tendency to be directed towards professionals. This has among other things, the implications that conforming to standards is very important and that flexibility in what you can do is more important than how simple it is to set up. g-)
SIP wrote:
That's actially a good analogy, Greger... The pickup truck is powerful, able to be used for many applications, and once you own one, everyone suddenly wants you around when they need some work done, whereas the Porsche is built for speed, is cramped, can't carry much, and is too expensive for any practical people to ever really purchase. ;)
Mind you, that being said, we do all our conferences in SEMS. It's actually a metric ton easier to set up for conferencing than Asterisk (WHY is it you need a Zaptel timing interface for audio mixing, again?), can support massively more users (especially if some are in listen-only mode), and 'Just works.'
N.
Greger V. Teigre wrote:
Hm, I don't agree with that comparison ;-) Asterisk is a PBX, SEMS is a platform for specific applications. There are some common pre-developed applications that easily can be set up (like a conference bridge, play announcements etc). However, if you need a PBX with lots of features, you don't start with SEMS.
I would rather compare Asterisk to a pick-up truck and SEMS to the Porsche. Use the truck for pretty much any work, but the Porsche is made for speed... :-)
Using Asterisk as only a conference bridge and playing announcements is like using the pick-up truck to move your 12-piece china... g-)
SIP wrote:
Offers them? Yes. Offers them in a clean, friendly, usable package? Not so much yet.
SEMS has raw capability, but if you want it to do many of the things Asterisk can do, you need to know how to code that yourself, or you're going to be digging about the code for documentation on features (since the current docs are not the world's greatest).
Don't get me wrong, SEMS has its place, and is a constantly evolving work of art (we use SEMS for several things in our environment), but comparing SEMS to Asterisk is a bit like comparing a bunch of car parts to a Porsche.
N.
Fredrik Lundmark wrote:
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
> Asterisk is an excellent PBX system, and makes a very good endpoint in > the SIP chain for all sorts of things -- IVR systems, voicemail > applications, automated messages, etc. > > It has an extremely well-written CDR engine, so many people mesh it with > billing applications to produce accurate accounting information. It also > is fully aware of the media stream, which means it's capable of cutting > off a call mid-stream, injecting audio into the call, etc, etc. > > Programming for Asterisk addons can be easily done in just about any > language, and it meshes well with the overall structure. Programming for > SER is... not so simple. > > As for running them both on the same box, the biggest problem would be > resources. Unlike SER, Asterisk is not designed to be a carrier-grade > SIP proxy. If you're actually proxying the media stream, you'd be > hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk > on even the beefiest of hardware. Add SER to the same box, and you will > quickly run into resource problems in medium-sized environments. It also > doesn't have a lot of the SIP proxy functionality that SER has. > > If you're careful, you can configure Asterisk NOT to handle the media > stream and still use it for prepaid solutions (using astcc or > asterisk-b2bua), and this will save you bandwidth (but you'll still > likely run into NAT issues that need to be dealt with somehow) and still > let you use Asterisk as an in-between point. > > Together, Asterisk and SER make a very powerful combination for > providing a full suite of services to clientele, and each plays well off > the other's strengths. > > N. > > > > Nhadie wrote: > > > >> Hi All, >> >> What's the advantage of combining ser with asterisk? I always see >> comments like using ser with asterisk is a very good solution etc. etc. >> the thing i liked with ser is that it does not do codec translation, >> which saves me cpu usage and also bandwidth. if i combine it with >> asterisk, would it not use codec translation? >> >> i also read that there is also a problem when ser and asterisk is >> run on >> the same machine, why is it so? >> if use prepaid billing solution for asterisk like astcc, would i >> then be >> able to provide prepaid service? >> >> soryy for asking too much, i'd just like to really understand it. Thank >> You in advanced. >> >> Regards, >> Nhadie >> _______________________________________________ >> Serusers mailing list >> Serusers@lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> >> > _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > >
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
PS
...and is designed to provide high capacity (missed that in my earlier post).
Has anyone any input on SEMS capacity, except the http://ftp.iptel.org/pub/sems/sayer_sems_19.3.07.pdf?
DS
/Fredrik
----- Original Message ----- From: "Fredrik Lundmark" fredrik@dimi.se To: "SIP" sip@arcdiv.com; "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 2:56 PM Subject: Re: [Serusers] why combine ser with asterisk
I'm still learning myself, but SEMS (iptel.org/sems) seems to offer many of the media- and/or b2bua-functions that Asterisk do.
///Fredrik
----- Original Message ----- From: "SIP" sip@arcdiv.com To: "Nhadie" nhadie@tbgi.net.ph Cc: asterisk-users@lists.digium.com; serusers@lists.iptel.org Sent: Thursday, August 23, 2007 1:38 PM Subject: Re: [Serusers] why combine ser with asterisk
Asterisk is an excellent PBX system, and makes a very good endpoint in the SIP chain for all sorts of things -- IVR systems, voicemail applications, automated messages, etc.
It has an extremely well-written CDR engine, so many people mesh it with billing applications to produce accurate accounting information. It also is fully aware of the media stream, which means it's capable of cutting off a call mid-stream, injecting audio into the call, etc, etc.
Programming for Asterisk addons can be easily done in just about any language, and it meshes well with the overall structure. Programming for SER is... not so simple.
As for running them both on the same box, the biggest problem would be resources. Unlike SER, Asterisk is not designed to be a carrier-grade SIP proxy. If you're actually proxying the media stream, you'd be hard-pressed to squeeze more than 150 simultaneous calls out of Asterisk on even the beefiest of hardware. Add SER to the same box, and you will quickly run into resource problems in medium-sized environments. It also doesn't have a lot of the SIP proxy functionality that SER has.
If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point.
Together, Asterisk and SER make a very powerful combination for providing a full suite of services to clientele, and each plays well off the other's strengths.
N.
Nhadie wrote:
Hi All,
What's the advantage of combining ser with asterisk? I always see comments like using ser with asterisk is a very good solution etc. etc. the thing i liked with ser is that it does not do codec translation, which saves me cpu usage and also bandwidth. if i combine it with asterisk, would it not use codec translation?
i also read that there is also a problem when ser and asterisk is run on the same machine, why is it so? if use prepaid billing solution for asterisk like astcc, would i then be able to provide prepaid service?
soryy for asking too much, i'd just like to really understand it. Thank You in advanced.
Regards, Nhadie _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
Thank You for your reply. I now get the part where Asterisk has features that can be used by ser. Just some questions on this one:
"If you're careful, you can configure Asterisk NOT to handle the media stream and still use it for prepaid solutions (using astcc or asterisk-b2bua), and this will save you bandwidth (but you'll still likely run into NAT issues that need to be dealt with somehow) and still let you use Asterisk as an in-between point. "
Does that mean only SIP messages will be passed thru the asterisk not the voice? How can I do that in ser? If i do a rewritehostport on ser to asterisk, will that also send the voice to asterisk? Thanks again in advanced.
Regards, Nhadie
-
Fredrik Lundmark -
Greger V. Teigre -
Michael Grigoni -
Nhadie -
SIP -
Stefan Sayer -
Umut Emin