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:mnhas...@usa.net] Gesendet: Dienstag, 28. Juni 2011 18:11 An: flor...@gruendler.net Cc: asterisk-ss7@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, <flor...@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
