[asterisk-r2] Sending DTMF 'f' ?

Wed Mar 18 20:07:15 CDT 2009

I understand, but I have met hundreds of people (myself included) that
are "pretty sure" that a system is behaving like they think, and ends
up being something else.

On Wed, Mar 18, 2009 at 6:56 PM, Amilcar Silvestre <amilcar at vonix.com.br> wrote:
> Moises,
>
> I understand what you are saying, but i'm pretty sure that the DTMF
> has came from DAHDI. Like i said, the problem has been solved
> completely disabling hardware dtmf detector on wanpipe, and now I
> don`t have any log entries that show "f" dtmf entries.
>
> I can't re-enable the hardware dtmf detector right now to reproduce
> the error now because the box is in production. Tomorrow I will try to
> re-enable it and will capture the log entries, as you requested.
>
> Anyway, thanks for the help.
>
> Amilcar.
>
>
> On Mar 18, 2009, at 8:44 PM, Moises Silva wrote:
>
>> As I said before, the Sangoma or Digium drivers cannot magically pass
>> the DTMF to the Asterisk core, it has to first be requested and read
>> by the chan_dahdi.c Asterisk driver, if you want to really find the
>> culprit you need to provide the log I asked for.
>>
>> Moy
>>
>> On Wed, Mar 18, 2009 at 4:06 PM, Amilcar Silvestre <amilcar at vonix.com.br
>> > wrote:
>>> Moises,
>>>
>>> 27 minutes working with no problems at all. No more "DTMF "f"
>>> received
>>> on DAHDI" at all. The problem is on wanpipe hardware dtmf detection.
>>>
>>> But this is very strange since, as i said, i use TDMV_HW_DTMF enabled
>>> on many, many clients without any problems.
>>>
>>> Since now you're working for Sangoma, do you have any clues why is
>>> this happening? ;-) I'm using wanpipe 3.3.16 (hmm, the other boxes
>>> are
>>> running 3.3.14, maybe the new version introduced some bug to the
>>> hardware dtmf detector?)
>>>
>>> Regards,
>>> Amilcar.
>>>
>>>
>>> On Mar 18, 2009, at 5:39 PM, Amilcar Silvestre wrote:
>>>
>>>> Moises,
>>>>
>>>> No actions from manager here.
>>>>
>>>> I'm suspecting that this comes from the hardware DTMF detection in
>>>> the
>>>> echo cancelation module in the board (Sangoma A104D), altough i've
>>>> never seem this happened, and I have at lest 60 others boxes with R2
>>>> and hardware dtmf detection using sangoma. Works like a charm. I've
>>>> turned it off. Let us see if the problem persists.
>>>>
>>>> Regards,
>>>> Amilcar.
>>>>
>>>> On Mar 18, 2009, at 5:33 PM, Moises Silva wrote:
>>>>
>>>>> No is not enough to see DAHDI/3-1, because that message is
>>>>> printed by
>>>>> the core, but the core may have dequeued this DTMF digit from other
>>>>> source than a read() in chan_dahdi.c, as I said, it may have come
>>>>> from
>>>>> the manager (which is capable of enqueueing DTMF in any channel),
>>>>> and
>>>>> there is other ways to fake incoming DTMF.
>>>>>
>>>>> Moy
>>>>>
>>>>> On Wed, Mar 18, 2009 at 5:29 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>>> wrote:
>>>>>> The "DTMF Down " message will only be seem if i turn DEBUG level
>>>>>> to
>>>>>> the logs. DMTF only is not sufficient. Doing it now.
>>>>>>
>>>>>> Amilcar.
>>>>>>
>>>>>> On Mar 18, 2009, at 5:23 PM, Amilcar Silvestre wrote:
>>>>>>
>>>>>>> Moises,
>>>>>>>
>>>>>>> DTMF begin 'f'received on DAHDI/3-1 doesn't mean that the DTMF is
>>>>>>> coming from DAHDI??
>>>>>>>
>>>>>>> No DTMF Down anywhere in the logs.
>>>>>>>
>>>>>>> Amilcar.
>>>>>>>
>>>>>>> On Mar 18, 2009, at 5:15 PM, Moises Silva wrote:
>>>>>>>
>>>>>>>> I still fail to see the log where this DTMF comes from
>>>>>>>> chan_dahdi.c
>>>>>>>>
>>>>>>>> Did you just miss it?
>>>>>>>>
>>>>>>>> Can you check your log and see if you can find a message like:
>>>>>>>>
>>>>>>>> DTMF Down 'f'
>>>>>>>>
>>>>>>>> in chan_dahdi?? otherwise somehow that DTMF is received from
>>>>>>>> somewhere
>>>>>>>> else, perhaps a manager application or something like that?
>>>>>>>>
>>>>>>>> On Wed, Mar 18, 2009 at 4:51 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>>>>>> wrote:
>>>>>>>>> Moises,
>>>>>>>>>
>>>>>>>>> The log from console, with dtmf debug enabled is:
>>>>>>>>>
>>>>>>>>> [Mar 18 17:49:59] DTMF[3411]: channel.c:2279 __ast_read: DTMF
>>>>>>>>> begin
>>>>>>>>> 'f' received on DAHDI/3-1
>>>>>>>>> [Mar 18 17:49:59] DTMF[3411]: channel.c:2289 __ast_read: DTMF
>>>>>>>>> begin
>>>>>>>>> passthrough 'f' on DAHDI/3-1
>>>>>>>>> [Mar 18 17:49:59] WARNING[3411]: rtp.c:2205
>>>>>>>>> ast_rtp_senddigit_begin:
>>>>>>>>> Don't know how to represent 'f'
>>>>>>>>>
>>>>>>>>> Amilcar.
>>>>>>>>>
>>>>>>>>> On Mar 18, 2009, at 4:47 PM, Amilcar Silvestre wrote:
>>>>>>>>>
>>>>>>>>>> Hi Moyses,
>>>>>>>>>>
>>>>>>>>>> Ok, I've enabled DTMF debugging, and here's what i've got:
>>>>>>>>>>
>>>>>>>>>> [Mar 18 17:34:12] NOTICE[2690] chan_dahdi.c: MFC/R2 call has
>>>>>>>>>> been
>>>>>>>>>> accepted on chan 10
>>>>>>>>>> [Mar 18 17:34:12] NOTICE[2690] chan_dahdi.c: Call accepted on
>>>>>>>>>> forward
>>>>>>>>>> channel 10
>>>>>>>>>> (...)
>>>>>>>>>> [Mar 18 17:39:51] DTMF[2705] channel.c: DTMF begin 'f'
>>>>>>>>>> received
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:39:51] DTMF[2705] channel.c: DTMF begin passthrough
>>>>>>>>>> 'f'
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:39:51] WARNING[2705] rtp.c: Don't know how to
>>>>>>>>>> represent
>>>>>>>>>> 'f'
>>>>>>>>>> (...)
>>>>>>>>>> [Mar 18 17:40:17] DTMF[2705] channel.c: DTMF begin 'f'
>>>>>>>>>> received
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:40:17] DTMF[2705] channel.c: DTMF begin passthrough
>>>>>>>>>> 'f'
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:40:17] WARNING[2705] rtp.c: Don't know how to
>>>>>>>>>> represent
>>>>>>>>>> 'f'
>>>>>>>>>> (...)
>>>>>>>>>> [Mar 18 17:40:24] DTMF[2705] channel.c: DTMF begin 'f'
>>>>>>>>>> received
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:40:24] DTMF[2705] channel.c: DTMF begin passthrough
>>>>>>>>>> 'f'
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:40:24] WARNING[2705] rtp.c: Don't know how to
>>>>>>>>>> represent
>>>>>>>>>> 'f'
>>>>>>>>>> (...)
>>>>>>>>>> [Mar 18 17:40:44] DTMF[2705] channel.c: DTMF begin 'f'
>>>>>>>>>> received
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:40:44] DTMF[2705] channel.c: DTMF begin passthrough
>>>>>>>>>> 'f'
>>>>>>>>>> on
>>>>>>>>>> DAHDI/10-1
>>>>>>>>>> [Mar 18 17:40:44] WARNING[2705] rtp.c: Don't know how to
>>>>>>>>>> represent
>>>>>>>>>> 'f'
>>>>>>>>>> [Mar 18 17:40:45] DTMF[2793] channel.c: DTMF begin 'f'
>>>>>>>>>> received
>>>>>>>>>> on
>>>>>>>>>> DAHDI/12-1
>>>>>>>>>> [Mar 18 17:40:45] DTMF[2793] channel.c: DTMF begin passthrough
>>>>>>>>>> 'f'
>>>>>>>>>> on
>>>>>>>>>> DAHDI/12-1
>>>>>>>>>> [Mar 18 17:40:45] WARNING[2793] rtp.c: Don't know how to
>>>>>>>>>> represent
>>>>>>>>>> 'f'
>>>>>>>>>> (...)
>>>>>>>>>> [Mar 18 17:43:05] NOTICE[2705] chan_dahdi.c: Chan 10 - Far end
>>>>>>>>>> disconnected. Reason: Forced Release
>>>>>>>>>> [Mar 18 17:43:05] NOTICE[2705] chan_dahdi.c: MFC/R2 call
>>>>>>>>>> disconnected
>>>>>>>>>> on chan 10
>>>>>>>>>> [Mar 18 17:43:05] NOTICE[4775] chan_dahdi.c: MFC/R2 call end
>>>>>>>>>> on
>>>>>>>>>> chan
>>>>>>>>>> 10
>>>>>>>>>>
>>>>>>>>>> And this is happening in two different telcos.
>>>>>>>>>>
>>>>>>>>>> Yes, I've patched asterisk. The patch is that from googlecode
>>>>>>>>>> for
>>>>>>>>>> 1.4.23, with a very tiny modification to make the channel
>>>>>>>>>> returns
>>>>>>>>>> the
>>>>>>>>>> hangupcause.
>>>>>>>>>>
>>>>>>>>>> Amilcar.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mar 18, 2009, at 4:32 PM, Moises Silva wrote:
>>>>>>>>>>
>>>>>>>>>>> Hum, I see what you mean. But, MFC and DTMF use different
>>>>>>>>>>> pair
>>>>>>>>>>> of
>>>>>>>>>>> frequencies and F does not even exist in DTMF. Please enable
>>>>>>>>>>> dtmf
>>>>>>>>>>> debugging in your logger.conf and try to reproduce, I'd
>>>>>>>>>>> expect
>>>>>>>>>>> to
>>>>>>>>>>> see
>>>>>>>>>>> clearly if chan_dahdi/chan_zap is the one detecting a MF
>>>>>>>>>>> digit
>>>>>>>>>>> and
>>>>>>>>>>> wrongly sending it down to the core as DTMF digit.
>>>>>>>>>>>
>>>>>>>>>>> Did you patched that asterisk yourself?
>>>>>>>>>>>
>>>>>>>>>>> From a quick look at the code, the 'f' frame subclass is also
>>>>>>>>>>> used
>>>>>>>>>>> for
>>>>>>>>>>> FAX, so that f does not necessarily refers to the MF F tone.
>>>>>>>>>>>
>>>>>>>>>>> Moy
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 18, 2009 at 4:20 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi Moises,
>>>>>>>>>>>>
>>>>>>>>>>>> I've already recorded the call using mixmonitor on the sip
>>>>>>>>>>>> side.
>>>>>>>>>>>> The
>>>>>>>>>>>> same on the recorded file. Mixmonitor only records the sip
>>>>>>>>>>>> side,
>>>>>>>>>>>> and
>>>>>>>>>>>> the far end is muted.
>>>>>>>>>>>>
>>>>>>>>>>>> And the problem only occurs on the R2 links. PRI works ok
>>>>>>>>>>>> (same
>>>>>>>>>>>> box).
>>>>>>>>>>>>
>>>>>>>>>>>> Seems that, after it enters on the function
>>>>>>>>>>>> ast_rtp_senddigit_begin
>>>>>>>>>>>> in
>>>>>>>>>>>> rtp.c, the function returns 0 (it doesn't have the "f" digit
>>>>>>>>>>>> for
>>>>>>>>>>>> DTMF,
>>>>>>>>>>>> the digit 'f' is related to MFC). After it returns 0, the
>>>>>>>>>>>> audio
>>>>>>>>>>>> from
>>>>>>>>>>>> DAHDI stops been redirected to the sip end point.
>>>>>>>>>>>>
>>>>>>>>>>>> Amilcar.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 18, 2009, at 4:08 PM, Moises Silva wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I think you should try to post this in asterisk-users, this
>>>>>>>>>>>>> is
>>>>>>>>>>>>> not
>>>>>>>>>>>>> an R2 issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having said that, it would be a good idea to reproduce, and
>>>>>>>>>>>>> then,
>>>>>>>>>>>>> when
>>>>>>>>>>>>> you have a call like that, use dahdi_monitor or ztmonitor
>>>>>>>>>>>>> to
>>>>>>>>>>>>> verify
>>>>>>>>>>>>> the audio is getting into the board correctly, then you can
>>>>>>>>>>>>> monitor
>>>>>>>>>>>>> the RTP traffic on the SIP side of the call and see if
>>>>>>>>>>>>> Asterisk
>>>>>>>>>>>>> is
>>>>>>>>>>>>> still sending the audio correctly, if it does, then the
>>>>>>>>>>>>> problem
>>>>>>>>>>>>> is
>>>>>>>>>>>>> definitely not even in Asterisk.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 18, 2009 at 3:54 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Douglas,
>>>>>>>>>>>>>> If you meant the CAS bits, is 1101.
>>>>>>>>>>>>>> If you mean the configuration of the link:
>>>>>>>>>>>>>> signalling=mfcr2
>>>>>>>>>>>>>> mfcr2_variant=br
>>>>>>>>>>>>>> mfcr2_get_ani_first=no
>>>>>>>>>>>>>> mfcr2_max_ani=10
>>>>>>>>>>>>>> mfcr2_max_dnis=4
>>>>>>>>>>>>>> mfcr2_category=national_subscriber
>>>>>>>>>>>>>> mfcr2_logdir=span1
>>>>>>>>>>>>>> mfcr2_logging=all
>>>>>>>>>>>>>> mfcr2_metering_pulse_timeout=500
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Amilcar.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mar 18, 2009, at 3:50 PM, Douglas Fischer wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you have in your start bits? (zapata.conf)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/3/18 Amilcar Silvestre <amilcar at vonix.com.br>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a box using asterisk 1.4.23.2, and OpenR2 1.1.0.
>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>> board
>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>> Sangoma A104D, From times to times, it shows this
>>>>>>>>>>>>>>> message:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WARNING[31548] rtp.c: Don't know how to represent 'f'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seems to be something related to sending a DTMF digit.
>>>>>>>>>>>>>>> After
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> message, the caller (an internal SIP endpoint) doens't
>>>>>>>>>>>>>>> hear
>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>> more from the called (far end, coming from a R2 link),
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>> end
>>>>>>>>>>>>>>> keeps receiving the audio from the SIP end point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The message comes with no intervention from the user on
>>>>>>>>>>>>>>> SIP
>>>>>>>>>>>>>>> end
>>>>>>>>>>>>>>> point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does anyone knows what is happening?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Amilcar.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>>>>>> digital.com--
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Douglas Fernando Fischer
>>>>>>>>>>>>>> Engº de Controle e Automação
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>>>>> digital.com--
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>>>>> digital.com--
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> "I do not agree with what you have to say, but I’ll
>>>>>>>>>>>>> defend to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> death your right to say it." Voltaire
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>>>> digital.com--
>>>>>>>>>>>>>
>>>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>>> digital.com--
>>>>>>>>>>>>
>>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> "I do not agree with what you have to say, but I’ll defend to
>>>>>>>>>>> the
>>>>>>>>>>> death your right to say it." Voltaire
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>> digital.com--
>>>>>>>>>>>
>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>> digital.com--
>>>>>>>>>>
>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>> digital.com--
>>>>>>>>>
>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> "I do not agree with what you have to say, but I’ll defend to
>>>>>>>> the
>>>>>>>> death your right to say it." Voltaire
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>> digital.com--
>>>>>>>>
>>>>>>>> asterisk-r2 mailing list
>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>> digital.com--
>>>>>>>
>>>>>>> asterisk-r2 mailing list
>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>  http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>> digital.com--
>>>>>>
>>>>>> asterisk-r2 mailing list
>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>  http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> "I do not agree with what you have to say, but I’ll defend to the
>>>>> death your right to say it." Voltaire
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-r2 mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>>  http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>
>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-r2 mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-r2 mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>
>>
>>
>>
>> --
>> "I do not agree with what you have to say, but I’ll defend to the
>> death your right to say it." Voltaire
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-r2 mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>

-- 
"I do not agree with what you have to say, but I’ll defend to the
death your right to say it." Voltaire