[asterisk-ss7] Asterisk 1.8.4.2 + LibSS7 1.0.2 : Early Media Problem

Tue Jun 28 14:25:06 CDT 2011

Hi Florian,

Thank you for the clarification on early media on chan_ss7.  And, also thank
you for the onward discussion on Asterisk as a whole in high E1 densities.
 This will be a rather long email, so I apologize beforehand.

While I agree with you, Florian, that asterisk does allow for low cost per
E1, the requirements are also different from project to project.  In this
case, the setup is very volatile, no permanence in the project.  It might
happen that tomorrow the project might simply not exist.  Then, spending on
expensive high-density boxes do not make economic sense.

Decision to go to Asterisk 1.8+ came after we tested it in production in a
SIP - SIP scenario, where some endpoints (Sysmaster 3000 in this case) did
not hold calls from our core switch VOS.  When we did a simple re-routing
through Asterisk 1.8, it worked well.  In that setup, Asterisk 1.8 seemed to
be quite stable, having handled millions of call attempts in the last 4
weeks that it has been running without a restart.

That is very good work on part of Digium, from our past experience.  Even in
our current SS7 implementations, 2 x 8 E1s per box, one box is working very
nicely, whereas the other is not so.  I found out later, the box performing
poorly was running i386 CentOS 5.6.  Probably 32-bit is not the best idea
anymore these days, as most software are tuned for 64-bit environment.  We
plan to change the OS sometime next week, and then we can say how that is
going.  Even if it does not work, I have confirmation from Digium, that they
can provide support for Asterisk 1.8 + LibSS7 and work on the stability
issues that we are facing.

As for CDR, we do not use Asterisk for CDRs at all.  We handle that from our
switch.  In most cases that suffices.  If we need to get the CDR from
Asterisk, then we put another instance of FreeSWITCH in front of Asterisk,
and compare between the two to mediate.

I am not an expert programmer, but from what I have read through the mailing
lists about different Asterisk + DAHDI problems, it appears the current
architecture of hardware interrupts in the DAHDI channel driver, makes it
very difficult to bring about stability in the software side.  But, as I
said, I'm not a programmer, and therefore, my assumptions could be very
wrong.

Sangoma & Yate has said that they have used FreeSWITCH in 32 x E1
configurations. Sangoma even said that, although they don't officially
recommend more then 16 x E1 in production, they frequently do 32 x E1
configurations in their lab, mostly for debugging.

If only Digium would release a version of libSS7 for FreeTDM, then I would
have given FreeSWITCH a test run, and see if FreeSWITCH can indeed offer the
stability that their team so proudly demonstrates.  IP <-> TDM is an
entirely different beast, where you have to work not only on software side
problems, but more so on the hardware side, even perhaps as far as the
Kernel.

In any case, we are also working on a stable project with 1 x STM1, for
which we already have an old Lucent APX8000 with 64 x E1s with matching
hardware DSP.  I read a few days back that Asterisk now supports MGCP, and
if that is indeed workable, then that would mean a huge jump for Asterisk
from open-source low cost telephony into the carrier grade world.

In the end, Asterisk is a great product, and we shall keep using it where
the use case requires it.

Regards
HASSAN

On Wed, Jun 29, 2011 at 00:07, <florian at gruendler.net> wrote:

> Hassan,****
>
> ** **
>
> Don’t bother testing 1.6.2 with chan_ss7 and early media with Progress(), I
> can tell you it works since that is what I have in production! ****
>
> ** **
>
> I just wanted to make sure I hit the right spot in your setup which was not
> sending any early media tones from the TDM trunk to the SIP caller. The rest
> was just thinking loud on Asterisk architecture to probe whether anyone on
> the list had some real notion on how things are and wanted to comment on in
> public. ****
>
> ** **
>
> And to share another point someone asked about chan_ss7 2.0: Actually I
> have made the move to chan_ss7 2.0 but it is not really a major release from
> what I can see feature wise. I think it was more a release to reflect the
> change to a new development CVS. I don’t know support options offered by
> Digium on libss7 but I made it clear I guess that chan_ss7 folks really know
> what they do and offer paid support. ****
>
> ** **
>
> I haven’t been brave enough to go for Asterisk 1.8 as long as I don’t need
> new features or see problems with 1.6 with what I do with the setup. Last
> but not least, this isn’t really a chan_ss7, but actually a libss7 mail list
> sponsored by Digium. I guess everyone with a low budget will end up with one
> of the two products and each one may or may not work depending on so many
> factors and traffic patterns, however mostly wrong configuration or hardware
> related issues. I had some real headache with HW echo cancelling but finally
> won the battle on that, too and now I run a media gateway with a pretty low
> cost per E1 port in the server farm for some less important interconnects.
> At least chan_ss7 allows multiple OPCs/DPCs and STP (those were requests of
> mine which Anders developed with a lot of dedication made it GPL now for all
> of you) while licensing in commercial gateways squeezes your balls exactly
> at that point, normally charging per link/linkset. But did you get my point
> about mission critical and port density, both of which is not the domain of
> Asterisk? If you can only afford a downtime of seconds or minutes per year
> rather than hours and depend on support SLAs, Digium is not the right shop,
> nor do they claim to be. You simply shouldn’t want to run 32 E1 busy traffic
> on Asterisk, much less with a single signaling link. Unless you were just
> bluffing, that kind of traffic should allow your company to make the money
> to get some carrier grade equipment. Ever thought about Asterisk not being
> accurate at CDR writing? Ever thought about hot session failover to update a
> second node or gracefully recover from a crash (let’s say at least NOT LOOSE
> CDRs at an event of core dumping). Want an example: 32E1 traffic to Cuba and
> a sudden crash such as a power failure or OS kernel panic/coredump can wipe
> out a couple 1000$ in your pocket if the switch doesn’t keep evidence of the
> call in the file system or in a physically separate memory container it
> updates every second or so and recovers gracefully after such an unplanned
> shutdown)? ****
>
> ** **
>
> I don’t want to get this too long, but think of risks and judge yourself
> whether you want to pay at the beginning or eventually manifold at the end.
> ****
>
> ** **
>
> Regards, Florian****
>
> ** **
>
> ** **
>
> ** **
>
> *Von:* Nyamul Hassan [mailto:mnhassan at usa.net]
> *Gesendet:* Dienstag, 28. Juni 2011 18:11
> *An:* florian at gruendler.net
> *Cc:* asterisk-ss7 at lists.digium.com
>
> *Betreff:* Re: [asterisk-ss7] Asterisk 1.8.4.2 + LibSS7 1.0.2 : Early
> Media Problem****
>
> ** **
>
> Hi Florian,****
>
> ** **
>
> Sorry for the late reply.  Had a busy few days.****
>
> ** **
>
> On Tue, Jun 28, 2011 at 20:17, <florian at gruendler.net> wrote:****
>
> Hassan, how did the story go on? ****
>
>  ****
>
> Did the Progress() enable the early media transmission in chan_sip to the
> calling user agent as desired? ****
>
> ** **
>
> Your suggestion worked like a charm!  Thank you!****
>
> ** **
>
>  ****
>
> If not, what did you find regarding LibSS7 and its influence on early media
> bridging to chan_sip? I believe the control stack handling media (which
> could well be chan_dahdi) does send received media along to any other
> involved channel constantly and the receiver chan_sip just discards it
> (while busy sending media from internal tone generator = fake ringing,
> treatment tone or comfort noise) unless early media capability is explicitly
> requested instead of those alternatives, latest when the B-channel enters a
> connected state when the signaling stack updates the channel variable to
> twoway audio after receiving the SS7 ANM message from the far end. ****
>
> ** **
>
> We do not have a chan_ss7 in production right now.  Already moved to
> Asterisk 1.8.  Will load Asterisk 1.6 with chan_ss7 during low traffic
> hours, and test out the early-media.****
>
> ** **
>
> ** **
>
>  ****
>
> Kind regards, Florian****
>
> ** **
>
> Thank you once again Florian.  Will work on this in the next few days.****
>
> ** **
>
> Regards****
>
> HASSAN****
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110629/727d7d6e/attachment-0001.htm>