[asterisk-r2] Sending DTMF 'f' ?

Amilcar Silvestre amilcar at vonix.com.br
Fri Apr 3 15:21:13 CDT 2009 

Hi Moises,

The problem with the 'f' DTMF received (an consequent block of audio)  
is a problem in the new release of the wanpipe drivers.

The version 3.3.16 of wanpipe introduces the follow feature:
  AFT HWEC
   Hardware DTMF detection now detects FAX tones as well,
   and passes then up to Zaptel/Asterisk

For some reason, if I enable the hw dtmf detection using 3.3.16, the  
messages "rtp.c: Don't know how to represent 'f'" starts to happen in  
the middle of the call, wrongly detecting a FAX tone.

3.3.15 works ok. And this happens with R2 or PRI systems as well.

Thanks for your help.

Regards,
Amilcar.


On Mar 18, 2009, at 9:07 PM, Moises Silva wrote:

> 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
>
> _______________________________________________
> --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

More information about the asterisk-r2 mailing list