[on-asterisk] TAUG Meeting & Social, TONIGHT, Mar 25th; OpenSER from an Asterisk point of view + IT360 draw

[Simon P. Ditner]

UPDATE: IT360 has donated 3 full access passes for a draw at the meeting
tonight! The discount codes also still apply -- A101 for 25% off, HS60
for 60% off for independent asterisk users, and TS1 for the free
tradeshow pass and keynotes with Mark Spencer & Kevin Fleming.

Also, mark your calendars for the TAUG meeting on April 8th at 6pm onsite
at the conference. Steve Lecomte and Dru Lavigne will be presenting on
the open source BlindSide webcasting and conferencing system.

TONIGHT's Topic:

Ovidiu Sas will be speaking on OpenSER from an asterisk point of view --
what it is, how it works, how to configure it, and how to integrate it
with Asterisk.

Prerequisites: A good understanding of SIP protocol, and a good
understanding of asterisk sip.conf file.

When:

TONIGHT, Tuesday March 25th, 2008
6:30pm - 7:30pm

Where:

North York Civic Centre (in Mel Lastman Square)
Committee Room 1
5100 Yonge St.,
North York, ON
(Google map link: http://xrl.us/hqbw)

The entrance into the conference area is well back from the road, just
in front of the fountains.

Driving:

The North York Civic Centre (in Mel Lastman Square) is located on the
West side of Yonge Street, just North of Yonge and Sheppard. There is
plenty of (P)arking behind the building at 180 Beecroft Road, or
underneath Empress Walk (entrance is off of Yonge and Emwood Ave.)

TTC:

The North York Civic Centre (in Mel Lastman Square) is located at the
North York Centre subway stop, one stop North of Sheppard Station.

Afterwards, we will progress to our regular pub (across the street)
around 7:30 - 8:00pm:

Toby's Good Eats
416-225-2995
5095 Yonge Street,
North York, ON M2N 6Z4

--
| It ain't what you don't know that gets you into trouble. It's what
| you know for sure that just ain't so. -- Mark Twain
|
| The Toronto Asterisk Users Group
| Join the discussion group by visiting http://taug.ca

---------------------------------------------------------------------
To unsubscribe, e-mail: biz-uns...@taug.ca
For additional commands, e-mail: biz-...@taug.ca

---------------------------------------------------------------------
To unsubscribe, e-mail: asterisk-u...@uc.org
For additional commands, e-mail: asteri...@uc.org

[Reza M. Reza]

I have an issue with a carrier and hoping for some feedback. My carrier
has been amazing and responsive, but as in any business, there are minor
things that arise from time to time The issue I am facing is that
RFC2833 does not work on certain numbers, specially government IVRs.
This is on Asterisk 1.2.9.1

I then tested the exact same thing RFC2833 on the government numbers in
question from my Asterisk 1.4.18 It works perfectly.

HOWEVER!!!!!!!
1. When I use other CDN trunks from 1.2.9.1 Asterisk with RFC2833 it
works FINE.
2. When I use Unlimitel it is fine.
3. When I use a dozen other carriers (American), its ALL fine.
4. Regardless of 1.2.9.1 or 1.4.18 RFC2833 works from ALL other carriers.

SO.....
IF ALL other carriers are passing DTMF perfectly from my 1.2.9.1 except
for the one in question, then would it be fair to say the problem is the
specific carrier which is consistent in failure to transmit DTMF to those
government numbers? Or are there other possible scenarios that I may be
missing out?

The quick fix here is to divert outgoing calls from 1.2.9.1 to the trunks
that are 100% on DTMF via RFC2833.

Any suggestions is welcome!

Best,
Reza.

[Philip Mullis]

You may be just running into an issue where your carrier has multiple
providers and routes and is shuffling toll free and gov numbers over a
trunk with no or poor dtmf.

[Philip Mullis]

There is also another possible scenario, that is your provider may have
multiple asterisk boxs and may be running in a mixed environment of 1.2
and 1.4.

Adding on the 1.4 box > rfc2833compensate=yes (to the customer/user
profile), fixes many dtmf issues when talking to a 1.2 platform.

[Bill Sandiford]

Is the carrier capable of doing a packet capture on their end to make sure
they are getting the DTMF from you correctly?. It would be interesting to
find out where the DTMF is breaking?

Are you able to do one from your box (or a mirrored switchport if you don't
like running packet traces on a production box) to make sure you are
transmitting it correctly to that carrier?

[Reza M. Reza]

Thanks Phil for the valuable input! Hopefully others can also provide
some input as to their experience, after which I will decide my
alternatives.

Thanks!
Reza.

[John Lange]

In a normal troubleshooting scenario, when you have proved it works in
all situations except one, then it would be the "one" that is at fault.

That would be the "normal" case. However, we are talking about
Asterisk ;)

DTMF has been very problematic in Asterisk for a long time and there are
various interpretations and implementations of RFC2833. What I suspect
you have encountered is your carrier has a particular SIP switch which
is not compatible with the RFC2833 implementation as implemented in
Asterisk 1.2.x.

Actually, I'm surprised that it works with Unlimitel. Their switches
used to require a manual patch to Asterisk 1.2.X in order to work
properly but perhaps they have recently implemented a work around so
that Asterisk 1.2.X works?

And I suspect the other carriers have done the same which is why it
works with most of them.

So the short answer is, Asterisk 1.2.9.1 is probably at fault but since
so many people use Asterisk most carriers have implemented a
work-around.

BTW, if I remember correctly; the problem with Asterisk is that it
doesn't set the tone length (or it leaves it at zero or something). Some
systems consider this to be invalid so they ignore it but most systems
default to the bare minimum DTMF length. Either way this causes problems
since even the minimum length is very hard to detect reliably.

More recent versions of 1.4 have dramatically improved DTMF.

John

[Leif Madsen]

On Tue, Mar 25, 2008 at 1:13 PM, John Lange <john....@open-it.ca> wrote:
> BTW, if I remember correctly; the problem with Asterisk is that it
> doesn't set the tone length (or it leaves it at zero or something). Some
> systems consider this to be invalid so they ignore it but most systems
> default to the bare minimum DTMF length. Either way this causes problems
> since even the minimum length is very hard to detect reliably.

Ya, in Asterisk 1.2.x, there was no 'length' indicating how long the
DTMF was held for (hence the 'variable length' in VLDTMF). Instead it
would burst out 3 start DTMF frames, and 3 end DTMF frames (the reason
for 3 of them on each was in case one of the frames was dropped since
the frames are stateless, and thus do not get an ACK that they were
delivered). This was the cause for some people getting duplicate and
triplicate DTMF at the far end because each set of start/end DTMF
frames were interpreted as individual key presses. VLDTMF largely
eliminates this problem.

> More recent versions of 1.4 have dramatically improved DTMF.

Oh the struggles and joys I had debugging Asterisk DTMF until it
improved to a usable fashion!

--
Leif Madsen.
http://www.leifmadsen.com
http://www.oreilly.com/catalog/asterisk