<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I don't like all this cross-posting, so I have removed the other lists.
My comments will be from iptel.org perspective.<br>
Inline.<br>
<br>
Fredrik Lundmark wrote:
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
  <style></style>
  <div><font face="Arial" size="2">&nbsp;&nbsp;&nbsp; Hmm,</font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">I find the dialog I&nbsp;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".</font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">What my needs are:</font></div>
  <ol>
    <li><font face="Arial" size="2">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"?</font></li>
  </ol>
</blockquote>
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.<br>
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.<br>
I believe there's a calling card app in sems that you can use/adapt.<br>
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <ol>
    <li><font face="Arial" size="2">Filtering of Refer &amp; Replace
(RFCs 3515, 3891, 3892), replacing them with Re-Inivtes - to support
most UAs, at the same being compliant with SIP trunks supporting
SIPConnect</font></li>
  </ol>
</blockquote>
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.<br>
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.<br>
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <ol>
    <li><font face="Arial" size="2">IVR capability - i.e. "regular IVR"
(customized stuff) as well as standard applications (voicemail,
conference)</font></li>
  </ol>
</blockquote>
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.<br>
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <ol>
    <li><font face="Arial" size="2">Queuing of calls</font></li>
  </ol>
</blockquote>
Well, as in "please hold, we will pick up the call whenever we feel
like it" ?<br>
This is a pbx or a call center application.<br>
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <ol>
    <li><font face="Arial" size="2">3pcc - capability for handling
calls from a operator's application</font>&nbsp;</li>
  </ol>
</blockquote>
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.<br>
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <div><font face="Arial" size="2">Anyone wanting to advise?</font></div>
</blockquote>
I hope it helps.<br>
g-)<br>
<blockquote cite="mid:081c01c7e623$ba078f90$0a00000a@nc4200" type="cite">
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">BR///</font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">Fredrik</font></div>
  <div>&nbsp;</div>
  <div>&nbsp;</div>
  <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">-----
Original Message -----
  <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><b>From:</b>
  <a moz-do-not-send="true" title="greger@teigre.com"
 href="mailto:greger@teigre.com">Greger V. Teigre</a> </div>
  <div><b>To:</b> <a moz-do-not-send="true" title="sip@arcdiv.com"
 href="mailto:sip@arcdiv.com">SIP</a> </div>
  <div><b>Cc:</b> <a moz-do-not-send="true" title="fredrik@dimi.se"
 href="mailto:fredrik@dimi.se">Fredrik Lundmark</a> ; <a
 moz-do-not-send="true" title="serusers@lists.iptel.org"
 href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a> </div>
  <div><b>Sent:</b> Friday, August 24, 2007 9:27 AM</div>
  <div><b>Subject:</b> Re: [Serusers] why combine ser with asterisk</div>
  </div>
  <div><br>
  </div>
Hm, I don't agree with that comparison ;-)<br>
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.<br>
  <br>
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... :-)<br>
  <br>
Using Asterisk as only a conference bridge and playing announcements is
like using the pick-up truck to move your 12-piece china...<br>
g-)<br>
  <br>
SIP wrote:
  <blockquote cite="mid:46CD85F0.6090705@arcdiv.com" type="cite">
    <pre wrap="">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:
  </pre>
    <blockquote type="cite">
      <pre wrap="">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" <a moz-do-not-send="true"
 class="moz-txt-link-rfc2396E" href="mailto:sip@arcdiv.com">&lt;sip@arcdiv.com&gt;</a>
To: "Nhadie" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
 href="mailto:nhadie@tbgi.net.ph">&lt;nhadie@tbgi.net.ph&gt;</a>
Cc: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
 href="mailto:asterisk-users@lists.digium.com">&lt;asterisk-users@lists.digium.com&gt;</a>; <a
 moz-do-not-send="true" class="moz-txt-link-rfc2396E"
 href="mailto:serusers@lists.iptel.org">&lt;serusers@lists.iptel.org&gt;</a>
Sent: Thursday, August 23, 2007 1:38 PM
Subject: Re: [Serusers] why combine ser with asterisk


    </pre>
      <blockquote type="cite">
        <pre wrap="">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:
      </pre>
        <blockquote type="cite">
          <pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>

        </pre>
        </blockquote>
        <pre wrap="">_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>

      </pre>
      </blockquote>
    </blockquote>
    <pre wrap=""><!---->
_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>


  </pre>
  </blockquote>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Serusers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
  </pre>
</blockquote>
</body>
</html>