[asterisk-users] Transfer call from analog telephone

Daniel Bareiro daniel-listas at gmx.net
Thu Jun 4 22:33:31 CDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tilghman and Grygoriy.

Tilghman Lesher escribió:

>> I was testing both the recall key and uncomment the following lines
>> in the features.conf file:
>>
>> blindxfer => #1
>> atxfer => *2
>>
>> verifying previously that the extension uses the arguments "tT" with
>> the Dial application and to include the context "featuremap" in the
>> context in which I have defined the extensions (internal).
>>
>> The telephone of the end with which the conversation is staying
>> listens the tones to try doing the transfer, but Asterisk does not
>> give the dial tone after *2 / #1 or the recall key.

> Remember that the time between the two digits is VERY short.  You must
> press those two digits in quick succession or else the requested
> feature code will not activate.

I made sure to make it sufficiently fast, but still increasing
featuredigittimeout, it did not work.

I am not sure if it will have some relation, but also found another
difficulty when the dial from my analog telephone.

When doing a echo test from an SIP extension, I don't have problems,
but, sometimes, with an analog telephone when trying to dial the
extension to realise the echo test (*600), after to have dial *60, a
tone cut in three parts is listened to soon a continuous tone, doing
impossible to be able to dial the extension completely. Sometimes it
works well, but sometimes it happens, that is something that draws
attention to me and, as it mentioned, from a SIP extension I'm not
having this problem.

This is what I get in the Asterisk CLI after to dial *60:

- --------------------------------------------------------------------------
    -- Starting simple switch on 'DAHDI/2-1'
    -- Blacklisting number 201
- --------------------------------------------------------------------------


I do not believe that it is something own of the analogical telephone.
Yesterday, exactly, I was testing with another telephone (of my work) to
discard that it could be something of the house telephone, and it happens the
same exactly.

Making the changes in logger.conf to also see the dialing DTMF tones,
they seem to be correctly passed:

- --------------------------------------------------------------------------
    -- Starting simple switch on 'DAHDI/2-1'
[Jun  4 06:47:16] DTMF[8669]: channel.c:2229 __ast_read: DTMF end '*' received on DAHDI/2-1, duration 0 ms
[Jun  4 06:47:16] DTMF[8669]: channel.c:2271 __ast_read: DTMF end accepted without begin '*' on DAHDI/2-1
[Jun  4 06:47:16] DTMF[8669]: channel.c:2282 __ast_read: DTMF end passthrough '*' on DAHDI/2-1
[Jun  4 06:47:16] DTMF[8669]: channel.c:2229 __ast_read: DTMF end '6' received on DAHDI/2-1, duration 0 ms
[Jun  4 06:47:16] DTMF[8669]: channel.c:2271 __ast_read: DTMF end accepted without begin '6' on DAHDI/2-1
[Jun  4 06:47:16] DTMF[8669]: channel.c:2282 __ast_read: DTMF end passthrough '6' on DAHDI/2-1
[Jun  4 06:47:17] DTMF[8669]: channel.c:2229 __ast_read: DTMF end '0' received on DAHDI/2-1, duration 0 ms
[Jun  4 06:47:17] DTMF[8669]: channel.c:2271 __ast_read: DTMF end accepted without begin '0' on DAHDI/2-1
[Jun  4 06:47:17] DTMF[8669]: channel.c:2282 __ast_read: DTMF end passthrough '0' on DAHDI/2-1
    -- Blacklisting number <cell_number>
[Jun  4 06:47:21] DEBUG[8669]: chan_dahdi.c:6244 ss_thread: waitfordigit returned < 0...
    -- Hungup 'DAHDI/2-1'
    -- Starting simple switch on 'DAHDI/2-1'
[Jun  4 06:47:26] DEBUG[8670]: chan_dahdi.c:6244 ss_thread: waitfordigit returned < 0...
    -- Hungup 'DAHDI/2-1'
- --------------------------------------------------------------------------

As I've commented in a previous message, after dial *60 (of *600 to Echo
test), I obtain like a tone cut in three parts followed of a continuous tone,
causing that I'm incapable to dial the extension completely. The
"waitfordigit" appears after to hangup. The <cell_number> seems to be some
number that I has dial previously. Testing again with a SIP extension, this
problem does not happen.

Also it draws attention to me that the DTMF has a duration of 0ms.

It is peculiar... after to have a restart of Asterisk, I can dial without
problems to *600. This is Asterisk log corresponding to the successful
communication with the extension: 

- --------------------------------------------------------------------------
[Jun  4 23:03:30] DTMF[28905]: channel.c:2229 __ast_read: DTMF end '*' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:03:30] DTMF[28905]: channel.c:2271 __ast_read: DTMF end accepted without begin '*' on DAHDI/2-1
[Jun  4 23:03:30] DTMF[28905]: channel.c:2282 __ast_read: DTMF end passthrough '*' on DAHDI/2-1
[Jun  4 23:03:30] DTMF[28905]: channel.c:2229 __ast_read: DTMF end '6' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:03:30] DTMF[28905]: channel.c:2271 __ast_read: DTMF end accepted without begin '6' on DAHDI/2-1
[Jun  4 23:03:30] DTMF[28905]: channel.c:2282 __ast_read: DTMF end passthrough '6' on DAHDI/2-1
[Jun  4 23:03:31] DTMF[28905]: channel.c:2229 __ast_read: DTMF end '0' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:03:31] DTMF[28905]: channel.c:2271 __ast_read: DTMF end accepted without begin '0' on DAHDI/2-1
[Jun  4 23:03:31] DTMF[28905]: channel.c:2282 __ast_read: DTMF end passthrough '0' on DAHDI/2-1
[Jun  4 23:03:31] DTMF[28905]: channel.c:2229 __ast_read: DTMF end '0' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:03:31] DTMF[28905]: channel.c:2271 __ast_read: DTMF end accepted without begin '0' on DAHDI/2-1
[Jun  4 23:03:31] DTMF[28905]: channel.c:2282 __ast_read: DTMF end passthrough '0' on DAHDI/2-1
    -- Executing [*600 at phones:1] Answer("DAHDI/2-1", "") in new stack
[Jun  4 23:03:31] DEBUG[28905]: chan_dahdi.c:3174 dahdi_answer: Took DAHDI/2-1 off hook
    -- Executing [*600 at phones:2] Playback("DAHDI/2-1", "demo-echotest") in new stack
    -- <DAHDI/2-1Playing 'demo-echotest' (language 'es')
  == Spawn extension (phones, *600, 2) exited non-zero on 'DAHDI/2-1'
    -- Hungup 'DAHDI/2-1'
- --------------------------------------------------------------------------

As you will see, the duration is always of 0 ms (also when I dial to the cell
phone). After this I make several tests. To dial from cell phone to the analog
phone and I did not have problems in to call immediately to *600 after to have
dial to the cell phone in each opportunity. But if from my extension 201 I
dial the analog phone and after that from my analog phone I dial to *600, it
happens the same of problem of not to be able to dial beyond *60. Log of the
CLI for this situation is the following one:

- --------------------------------------------------------------------------
[Jun  4 23:08:45] DTMF[29017]: channel.c:2229 __ast_read: DTMF end '*' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:08:45] DTMF[29017]: channel.c:2271 __ast_read: DTMF end accepted without begin '*' on DAHDI/2-1
[Jun  4 23:08:45] DTMF[29017]: channel.c:2282 __ast_read: DTMF end passthrough '*' on DAHDI/2-1
[Jun  4 23:08:46] DTMF[29017]: channel.c:2229 __ast_read: DTMF end '6' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:08:46] DTMF[29017]: channel.c:2271 __ast_read: DTMF end accepted without begin '6' on DAHDI/2-1
[Jun  4 23:08:46] DTMF[29017]: channel.c:2282 __ast_read: DTMF end passthrough '6' on DAHDI/2-1
[Jun  4 23:08:46] DTMF[29017]: channel.c:2229 __ast_read: DTMF end '0' received on DAHDI/2-1, duration 0 ms
[Jun  4 23:08:46] DTMF[29017]: channel.c:2271 __ast_read: DTMF end accepted without begin '0' on DAHDI/2-1
[Jun  4 23:08:46] DTMF[29017]: channel.c:2282 __ast_read: DTMF end passthrough '0' on DAHDI/2-1
    -- Blacklisting number 201
[Jun  4 23:08:54] DEBUG[29017]: chan_dahdi.c:6244 ss_thread: waitfordigit returned < 0...
    -- Hungup 'DAHDI/2-1'
- --------------------------------------------------------------------------

Which can be the problem?

Thanks for your replies.

Regards,
Daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkooklkACgkQZpa/GxTmHTfUYwCdEGRJ8A6ISKu9xWft+woatQHw
/eEAmweMwHWKe7fH2sxxSHwNDLdOh/8F
=9ikN
-----END PGP SIGNATURE-----




More information about the asterisk-users mailing list