Topic: [Announce]... Er... Loads of Asterisk/SAIL stuff

[SARK devs]

yes that's the bug.

Thanks for your help in verifying it.  Looks like -475 will be along shortly -

 Re DTMF

DTMF from where to where?  Phone to asterisk?  Phone to third party IVR?  inbound to IVR?

If it's from your phones then we need to know what kind of phones you got.  

Best

S

[mark_s_tt]

Apologies,

It's inbound  to IVR.

With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:

* DTMF-relay event received: 2

Stating the tone received EVERY time, however sometimes asterisk will receive the tone like:

* DTMF-relay event received: *

<--- Transmitting (no NAT) to 217.10.79.23:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 217.10.79.23;branch=z9hG4bKe77c.22dc452.0;received=217.10.79.23
Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKe77c.428de504.0
Via: SIP/2.0/UDP 217.10.66.71:5060;branch=z9hG4bK662e94fb;rport=5060
Record-Route: <sip:217.10.79.23;lr=on>
Record-Route: <sip:217.10.79.8;ftag=as1186addc;lr=on>
From: "Unknown" <sip:Unknown@217.10.66.71>;tag=as1186addc
To: <sip:448458692823@217.10.79.8>;tag=as3e5907c1
Call-ID: 2f04fca74ea4edc036d6e635271a44a2@217.10.66.71
CSeq: 105 INFO
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:8692823@192.168.1.2>
Content-Length: 0

Then:

Sometimes asterisk will just continue reading the IVR, completely ignoring the tone
Sometimes asterisk will respond instantly
Sometimes several seconds will pass, then it will respond

If or when it does respond it carries on as normal reading the correct IVR option:

<------------>
    -- AGI Script Executing Application: (Background) Options: (silence/1)
    -- <SIP/8692823-09aa74f0> Playing 'silence/1' (language 'en')
    -- AGI Script Executing Application: (Wait) Options: (1)
    -- Playing 'usergreeting0000' (escape_digits=129#) (sample_offset 0)

If it helps (I have no idea if it will however, so ignore as appropriate ), this is on AMD platform, and the running kernel is:
CentOS (2.6.9-42.0.10.EL)

Thanks a lot,
Mark.

[slords]

selintra fix your email server.  You are bouncing tons of emails every day with a message of:

Mail already has my delivered-to

Any mail sent from any smeserver to anything@selintra.com is bouncing.

[SARK devs]

Re mail,

Well, all I can say is we're receivng mail just fine from everyone else, we've had no complaints (other than yours) so we weren't aware of any problems.  It's just a vanilla mail server on a vanilla SME 7.1 system.

What e-mail address are you attempting to send to?

Best

S

[slords]

I've tried sending to admin@selintra.com from the admin account at my domain and from contribs.org and get email similar to the following.  This is the latest bounce that contribs.org admin group has received.  We receive quite a few of these every day.

Code: [Select]

Hi. This is the qmail-send program at selintra.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<admin@selintra.com>:
This message is looping: it already has my Delivered-To line. (#5.4.6)

--- Below this line is a copy of the message.

Return-Path: <admin@contribs.org>
Received: (qmail 8891 invoked by uid 101); 17 Jun 2007 08:15:07 -0000
Delivered-To: admin@switch.selintra.com
Received: (qmail 8887 invoked by alias); 17 Jun 2007 08:15:07 -0000
Delivered-To: alias-localdelivery-admin@selintra.com
Received: (qmail 8884 invoked by uid 453); 17 Jun 2007 08:15:07 -0000
X-Spam-Status: No, hits=0.5 required=5.0
tests=NO_REAL_NAME,SPF_PASS
X-Spam-Check-By: selintra.com
Received: from mail.contribs.org (HELO mail.contribs.org) (216.17.211.37)
    by selintra.com (qpsmtpd/0.32) with ESMTP; Sun, 17 Jun 2007 09:15:03 +0100
Received: from localhost (localhost [127.0.0.1])
by mail.contribs.org (Postfix) with ESMTP id 61CAD2801B
for <admin@selintra.com>; Sun, 17 Jun 2007 02:14:58 -0600 (MDT)
X-Virus-Scanned: amavisd-new at contribs.org
Received: from mail.contribs.org ([127.0.0.1])
by localhost (mail.contribs.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gxshEAQKRYi0 for <admin@selintra.com>;
Sun, 17 Jun 2007 02:14:57 -0600 (MDT)
Received: from contribs.org (unknown [192.168.250.37])
by mail.contribs.org (Postfix) with SMTP
for <admin@selintra.com>; Sun, 17 Jun 2007 02:14:57 -0600 (MDT)
Received: (qmail 32261 invoked by uid 100); 17 Jun 2007 08:14:56 -0000
To: Undisclosed-recipients: ;
Subject: Topic Reply Notification - SAIL - Using the hash key as the send key
Reply-to: admin@contribs.org
From: admin@contribs.org
Message-ID: <b98efb061b344ed45ef83917a8014c4d@forums.contribs.org>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
Date: Sun, 17 Jun 2007 01:14:56 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: PHP
X-MimeOLE: Produced By phpBB2


Hello,

You are receiving this email because you are watching the topic, "SAIL - Using the hash key as the send key" at Contribs.org. This topic has received a reply since your last visit. You can use the following link to view the replies made, no more notifications will be sent until you visit the topic.

http://forums.contribs.org/index.php?topic=37446.msg167963#msg167963

If you no longer wish to watch this topic you can either click the "Stop watching this topic link" found at the bottom of the topic above, or by clicking the following link:

http://forums.contribs.org/index.php?topic=37446.0

--
Thanks, Contribs.org Staff

[SARK devs]

Hi Slords,

We can only apologise.  Since we know even less about Qmail than we do about almost anything else, and since we are a POP3 shop, we've simply flattened and reinstalled the mail server.  

With luck this should have cured the problem.

Thanks for the heads up and, once again, sorry for any inconvenience caused.

Kind Regards

S

[llandry]

Well folks...  

Here's the update.... all good...

I've successfully implemented the X100P card in my home system. Single PIII.

I also successfully implemented a TDM400  with 1 FXO and 1 FXS on the dual CPU PIII running an SMP kernel..

Thanks all...  

I couldn't have done it without your excellent support.

Now... one more quick question.... My FXS port on the TDM400 will be connected to a Fax machine... I've setup autofax detection in Globals to extension 3999, but how do I define the extension? I do not see an FXS "device" when I define extensions.

Thanks

L2

[llandry]

My Bad.... Spoke to soon...

The TDM400 got recognized as a TDM01b, not the TDM11b that it should...

Once I plugged in the 12V Connector  Duh!!!  All is well and I now see the Analogue extension

Thanks

L2

[SARK devs]

Hi Llandry,

Glad you got there.  Don't worry, every newcomer to TDM boards quickly discovers that they work just fine without the 12V power, except the FXS ports don't come up!

It uses the power to generate the ring voltage for the phone.

As an aside, when you run purely with FXO ports we've had odd instances where plugging the power up is actually detrimental over long periods with the boards sometimes ending up in strange states.  As a result we tend not to plug 'em up when they are purely FXO.


Best

S

[SARK devs]

Apologies,

It's inbound to IVR.

With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:

Hi Mark,

Re your previous observation on 1.4 DTMF.  We have seen the same problem, particularly on voicemail.  It seems to be nothing to do with SARK/SAIL beacuse it is firmly in the voicemail app when it happens.  SARK/SAIL DTMF recognition (e.g. *56*) seems unaffected.  

We are just putting up 1.4.4 to see if the problem has gone away, but from what we can see, 1.4 DTMF processing is quite different to 1.2

Watch this space....

Best

S

[rcasado]

Hello Selintra,

A couple of quick questions on 2.1.15-483, 1.4.1-8 Asterisk & 1.4.0-5 MPP. (I set these up on a clean install w/ yum all updates.)

For some reason, I can't get the music on hold to operate properly. I did go into the musiconfold.conf and changed it to /var/lib/asterisk/moh then verified that MoH is selected on the trunks... but to no avail... I still get a ring even though the /var/lib/asterisk/moh subdirectory is populated with the default music files.

Also, I noticed a difference in the way Sail is managing email. When I set up an email address on an extension, emailing the voicemails works properly but when I don't, things go awry... In the past, I would set the supervisor email address in the globals section to admin@mydomain.com as a catch all. Sail would forward voicemail to the admin@mydomain.com account if the extension's email address was left blank. Since the update, emails are going to admin@localhost.mydomain.com... (even though I've set it up to go to admin@mydomain.com) therefore causing a qmail-send error. Has this configuration changed? Perhaps that wasn't its intended use but it was very handy to have a catch-all account.  

Thank you,
Richard

[mark_s_tt]

Apologies,

It's inbound to IVR.

With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:

Hi Mark,

Re your previous observation on 1.4 DTMF.  We have seen the same problem, particularly on voicemail.  It seems to be nothing to do with SARK/SAIL beacuse it is firmly in the voicemail app when it happens.  SARK/SAIL DTMF recognition (e.g. *56*) seems unaffected.  

We are just putting up 1.4.4 to see if the problem has gone away, but from what we can see, 1.4 DTMF processing is quite different to 1.2

Watch this space....

Best

S

Thanks for the response S.

I'm just in the process of rolling out new hardware anyway so I'll give asterisk 1.4.1 another go anyway.

When you release 1.4.4 I'll let you know if it made a difference.

Regards

Mark.

[mark_s_tt]

Apologies,

It's inbound to IVR.

With sip debug switched on, I can see the DTMF tones being received correctly as I get messages like:

Hi Mark,

Re your previous observation on 1.4 DTMF.  We have seen the same problem, particularly on voicemail.  It seems to be nothing to do with SARK/SAIL beacuse it is firmly in the voicemail app when it happens.  SARK/SAIL DTMF recognition (e.g. *56*) seems unaffected.  

We are just putting up 1.4.4 to see if the problem has gone away, but from what we can see, 1.4 DTMF processing is quite different to 1.2

Watch this space....

Best

S

Thanks for the response S.

I'm just in the process of rolling out new hardware anyway so I'll give asterisk 1.4.1 another go anyway.

When you release 1.4.4 I'll let you know if it made a difference.

Regards

Mark.

Hi Selintra,

Just tried this on brand new Intel Hardware, and the problem is exactly the same. The DTMF tones are being received by Asterisk, as you can see them in the debug, but the intermittent delayed or ignored responses are still there in the IVR.

I agree with your comments that this is an Asterisk thing, as it's Asterisk that's receiving the DTMF tones at the time they're ignored.

I might give 1.2 a go with Sail 2.1.14 but was wondering, is the Sail 2.1.15 "selintra-work" file compatiable with 2.1.14 if I do a restore?

Thanks a lot
Mark

[lightman]

Hi Selintra

I wanted to ask you how can I auto start the TDM02B support without the selintra package, since i wasn't able to do it, i couldn't find any script for that and my results where very odd.

I do:
modprobe zaptel
modprobe wcfxo (I got an error message here)
modprobe wctdm (I got an error message here too)
modprobe wcfxo (now it works (???? WTH???))
modprobe wctdm (now it works too (?? ZOMG!!))
/sbin/ztcfg -f
/sbin/ztcfg -vvvv

ok this works when I do it manually, but if I put this on a scritpt and run it (of course without the -vvvv) it doesn't work, and I don't get it why.

Also I don't get it why the second time I modprobe wctdm and fxo it works and the first one gives me error message.
I have a Digium TDM 400 with 2 fxo ports, on a I945GCCR mobo, pentium D 925, 1G DDR2, SME 7,1 fully updated, and I'm running asterisk 1.4.1-8 and zappri-MPP-1.4.0.4

I installed everything except the selintra package.

Now I decided to install on another box the selintra package which detected and configured the TDM nicely, however I'm very get used to configure asterisk by hand, is it a bad idea to use your package just for initial config and then configure every .conf by hand?.
(at least until i get used to the new interface, that seems very nice btw but needs hands on to figure it out )

thanks!.

Light.

[SARK devs]

Hi Light

First things first.  There's no reason why you shouldn't use our rpms to do the board config and then just hack away at the base files as long as you don't ever go back to our front-end (because there is no reverse engineering - we won't know what you've done and if you issue a commit in our package it will over-write all of your good work)..  

Alternatively, if you just want Vanilla asterisk rpms the Laimbock consulting ones are worth a look.

Or...  With Yum, you can very quickly install a devpack of your own and compile asterisk from source.  It takes about 40 minutes from start to finish and it isn't hard.  Just remember to yum remove the devpack when you've finished.

As to your strange modprobe results...  

In earlier asterisk releases, there was no wctdm driver (it was aliased to wcfxo), however it does exist in its own right in current releases.  So, the ONLY probe you need for a TDM board is...

Code: [Select]

modprobe wctdm

Probing wctdm will automatically load the module(s) it depends on (zaptel). You can see the relationship by doing "lsmod" after the probe.

Now, at first load you may get an error.  This is due to the time udev takes to build the /dev trees for the device.  It's no big deal and, as you've already discovered,  if you wait a second or two and probe it again, it works.  You can watch this happen by looking at /dev/zap/. It won't exist before you do the probe but it will magically appear afterwards.  That's udev doing its stuff, but it takes a few seconds.

Lastly you can simply start zaptel itself with "ztcfg".   By the way, it's not a good idea to call ztcfg more than once.  It's fine for TDM boards but some boards get extremely upset if you start zaptel repeatedly without first stopping it with zaptel -s.


Hope this helps