asterisk users - Oct 2005 - Re: feature usage/digit detection

Thanks for the answer.  Doesn't solve my problem, but that's only
because I didn't state my goal.  You have  corrected a misconseption on my
part, which ought to get me closer.  I'll explain...

Indeed, I do have the "tT" options in the dial command.  This is
because I thought this would enable the use of the '#' for transfers,
and it works satisfactorily.  I also have various '*N' definitions in
features.conf, but these don't work.  I suppose I do have to rethink my
strategy as you've suggested, but I don't know how to have my cake and
eat it.. (?)

By the way, I am using various SIP phones, with various DTMF detection
techniques (e.g. ZyXEL wifi:inband, Grandstream BT101 and ATA-488:INFO) with
apparent success because many features do work (such as transfer with #).





Message: 22
Date: Sun, 30 Oct 2005 10:57:57 -0400
From: Andrew Kohlsmith <akohlsmith-asterisk@benshaw.com>
Subject: Re: [Asterisk-Users] gotta be a dumb question...
To: asterisk-users@lists.digium.com
Message-ID: <200510300957.57769.akohlsmith-asterisk@benshaw.com>
Content-Type: text/plain;  charset="iso-8859-1"

On Sunday 30 October 2005 09:44, Bill Michaelson wrote:
>> -- Attempting native bridge of SIP/215-b09e and SIP/259412-5967
>>
>> Now, I've got canreinvite=no in every sip definition, but it
happens
>> anyway.
>  
>
That has nothing to do with reinvites.

In Asterisk terms, a native bridge between two channels is the lowest-latency 
connection between those channels without dropping out of the loop entirely.  
Essentially a native bridge just reads voice frames from one and transmits 
them to the other.  There is no codec translation or any other goodness going 
on.

When you hit a DTMF digit (you must be using inband DTMF here I think), the 
native bridge must be dropped because Asterisk needs to prepare to do 
something with the DTMF (transfer, etc.) -- when Asterisk has determined that 
it doesn't need to do anything special, it sets up the native bridge again
to
minimize the latency once again.

The fact that your * is getting "swallowed" tells me that you are
using * in
features.conf to denote special keypresses to Asterisk.  In Dial() you likely 
have the 't' or 'T' flags set, which causes Asterisk to
"think" that those
DTMF digits are for it, not for the other side.  Either edit features.conf, 
remove the 't' or 'T' flags from the Dial() command or rethink
your strategy.

I hope this is an acceptable answer, and I certainly hope it's accurate. 
It's
my understanding of the system anyway.    If you prefer not to have these 
types of messages, you need to turn DOWN the verbosity level.

-A.



-------------- next part --------------
Skipped content of type multipart/related

On Sunday 30 October 2005 11:13, Bill Michaelson wrote:
> Indeed, I do have the "tT" options in the dial command.  This is
because I
> thought this would enable the use of the '#' for transfers, and it
works
> satisfactorily.  I also have various '*N' definitions in
features.conf, but
> these don't work.  I suppose I do have to rethink my strategy as
you've
> suggested, but I don't know how to have my cake and eat it.. (?)
That's exactly what the 't' and 'T' options do, just make
sure you are using
the right one, I find it almost NEVER desireable to have both.  'T'
allows
the calling user to transfer with '#', 't' allows the called
user to do so.
if you're dialing between extensions in an office, you want both, but most 
other times you want one or the other.

If I'm not mistaken only 'pbx' threads can make use of the other
features in
features.conf.  tT is only for features in the [featuremap] section of 
features.conf.  I think.  (blind/attended transfers, call record, disconnect, 
etc.)

I think.  :-)

-A.