TONEDURATION Doesn't work?

Asterisk Asterisk General
1

Hi, i have a OpenVox TDM400p installed in a Elastix 2.3 with Asterisk 1.8 and when i dial to the pstn network, 12 seconds before i get the ring tone of the PSTN.

I’ve been trying to minimize this using the TONEDURATION=100 in chan_dahdi.conf without any result…

I want to modify the default DMTF length when asterisk send a call to the PSTN network, there is a bug of asterisk identified at: issues.asterisk.org/view.php?id=15160 and issues.asterisk.org/view.php?id=15173, so I want to modify the DEFAULT_DTMF_LENGTH parameter but I can’t find it in this version of asterisk used by Elastix 2.3

2

A delay of 12 seconds sounds more like you haven’t reached the maximum number length somewhere. If you have SIP phones, it could even be within those.

Typically, on modern networks, calls aren’t actually forward routed until either the maximum length number is dialed (this may take account of initial digits) or there has been a timeout.

In some cases, using ! type Asterisk dial patterns may help, but you may also have to insert extra digits to pad numbers out.

Make sure the dialplans in any VoIP phones know the correct number lengths for your environment.

12 seconds sounds a bit long. I believe the UK PSTN used to use 4, but only once the minimum number length was reached.

3

Hello,

Thank you for your reply.

I understand what you might say, but when in my dial plan i use: NXXXXXXX, is this not enough for trigger the call? as I see in issues.asterisk.org/view.php?id=15160, this is a problem of the DEFAULT_DTMF_LENGTH parameter on DAHDI technology … what can i do now?

4

I must say that the call origination is from a soft phones, Asterisk receives the entire phone number in one go…

5

The times quoted in that issue are much less than 12 seconds!

The phone won’t send the digits all in one go until it thinks you have stopped dialing.

I’d need more context to see if extensions.conf was causing delays.

Having timestamped logs, with enough detail would help tie down the origin of the delay.

6

Hi,

When I use: Dial(DAHDI/g0/${EXTEN}), the call has a delay of 12 seconds until ring.
When i use: Dial(DAHDI/g0/${EXTEN}#), the call has a delay of 8 second until ring.

There is a option "w "? How to use this option?

7

Four seconds are due to your PSTN operator timing out for the end of the number.

You need to establish where the delay is in relation the protocol with the local extension and the protocol with the PSTN, which means getting channel driver level tracing.

The Dial w option is completely unrelated. You need to configure automon (e.g. uncomment it) in features.conf.

8

Hi,

The autonom value is already uncommented:

automon=*1

Is not this parameter used for recording calls?

9

automon triggers the recording of calls. w and W enable its use. features.conf determines what, if any digit sequence enables it. It has nothing to do with call set up times.

10

Here is the log when I send the call:

[Jul 29 13:05:58] VERBOSE[3187] netsock2.c: == Using SIP RTP TOS bits 184
[Jul 29 13:05:58] VERBOSE[3187] netsock2.c: == Using SIP RTP CoS mark 5
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:1] Set(“SIP/12345-00000023”, “__FROM_DID=75850355”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:2] Gosub(“SIP/12345-00000023”, “app-blacklist-check,s,1”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [s@app-blacklist-check:1] GotoIf(“SIP/12345-00000023”, “0?blacklisted”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [s@app-blacklist-check:2] Set(“SIP/12345-00000023”, “CALLED_BLACKLIST=1”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [s@app-blacklist-check:3] Return(“SIP/12345-00000023”, “”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:3] ExecIf(“SIP/12345-00000023”, “0 ?Set(CALLERID(name)=12345)”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:4] SetMusicOnHold(“SIP/12345-00000023”, “none”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:5] Set(“SIP/12345-00000023”, “__MOHCLASS=none”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:6] Set(“SIP/12345-00000023”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:7] Set(“SIP/12345-00000023”, “CALLERPRES()=allowed_not_screened”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [75850355@from-pstn:8] Goto(“SIP/12345-00000023”, “ext-trunk,2,1”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Goto (ext-trunk,2,1)
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [2@ext-trunk:1] Set(“SIP/12345-00000023”, “TDIAL_STRING=DAHDI/g0”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [2@ext-trunk:2] Set(“SIP/12345-00000023”, “DIAL_TRUNK=2”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [2@ext-trunk:3] Goto(“SIP/12345-00000023”, “ext-trunk,tdial,1”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Goto (ext-trunk,tdial,1)
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:1] Set(“SIP/12345-00000023”, “OUTBOUND_GROUP=OUT_2”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:2] GotoIf(“SIP/12345-00000023”, “0?nomax”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:3] GotoIf(“SIP/12345-00000023”, “0?hangit”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:4] ExecIf(“SIP/12345-00000023”, “1?Set(CALLERPRES()=allowed_not_screened)”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:5] Set(“SIP/12345-00000023”, “DIAL_NUMBER=75850355”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:6] GosubIf(“SIP/12345-00000023”, “1?sub-flp-2,s,1”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [s@sub-flp-2:1] ExecIf(“SIP/12345-00000023”, “1?Return()”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:7] Set(“SIP/12345-00000023”, “OUTNUM=75850355”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] pbx.c: – Executing [tdial@ext-trunk:8] Dial(“SIP/12345-00000023”, “DAHDI/g0/75850355,300,”) in new stack
[Jul 29 13:05:58] VERBOSE[4400] app_dial.c: – Called DAHDI/g0/75850355
[Jul 29 13:06:19] VERBOSE[4400] app_dial.c: – DAHDI/2-1 answered SIP/12345-00000023
[Jul 29 13:06:25] VERBOSE[4400] sig_analog.c: – Hanging up on ‘DAHDI/2-1’
[Jul 29 13:06:25] VERBOSE[4400] chan_dahdi.c: – Hungup ‘DAHDI/2-1’
[Jul 29 13:06:25] VERBOSE[4400] pbx.c: == Spawn extension (ext-trunk, tdial, 8) exited non-zero on ‘SIP/12345-00000023’

Is the problem in the app_dial.c?

11

Can’t tell without the channel driver debugging, but the problem will not be in Dial, it will either be in the SIP phone or the DAHDI channel driver.

See wiki.asterisk.org/wiki/display/ … nformation for how to get the information.

12

Ok, Thank you very much.

Well, here is the log.

The missing seconds are in this line, this event is repeated for almost 15 seconds.

DEBUG[3386] res_rtp_asterisk.c: Setting the marker bit due to a source update

13

There is a: dahdi set debug on ?

14

If I use immediate=yes

[quote]; Specify whether the channel should be answered immediately or if the simple
; switch should provide dialtone, read digits, etc.
; Note: If immediate=yes the dialplan execution will always start at extension
; ‘s’ priority 1 regardless of the dialed number!
;
;immediate=yes[/quote]

My dialplan is very simple:

[to-pstn]
exten => _XXXXXXXX,1,Dial(DAHDI/g0/${EXTEN}#,0,r)
exten => _XXXXXXXX,2,Answer()
exten => _XXXXXXXX,3,Hangup()

How can i use the ‘s’ extension in my dialplan?

15

Make sure that all your calls originate from dahdi (not SIP) as it only applies to dahdi originated calls, make your dialplan start with:

exten => s,1,…

then use applications like waitexten to handle the number dialed. Basically I think you are trying to solve a SIP to DAHDI problem, for which it will be no help at all.

By the way, I don’t speak .rar., and generally won’t go to the trouble of running an uncompressor of any sort on attachments.

16

So, it’s not my case…

Sorry for the .rar attachment, but as I mentioned, this event is repeated for 15 seconds:

What’s this means? Is there any possiblity of reduce it’s time of execution?

17

It means that the SIP side has set a marker bit in the RTP stream, because the apparent source of the audio has changed, and therefore it would be an appropriate place for the downstream system to re-adjust its latency buffers. It is very much a secondary diagnostic. What I’m actually after is the relative timing of the sending of each DTMF digit, to when the Dial application was initiated. If this is earth start, also the timing of when line seize completed.

Unforunately, it is difficult to work out the time delay between when you made last keypress and when the SIP INVITE was sent.

18

If I use a softphone, when I press “call”, all the digits are sent in one go to the asterisk? right? , so , I think that the execution time is a problem of the dial command when it process one by one de received digits…

19

Hello, I don’t think that the problem is related with the dial application. Maybe the problem is in the timeout on your phone’s timeout or in the card contacting the pstn.

To check if is the phone timeout take the hour when you dial the last digit and send the call, then check the cli and check when the number is received. Check when appear the “Dahdi/X-XX is answered”. Usually if I see the card already answered and I can’t hear the ringing tone the problem is in the card or in my pstn.

And finally contact openvox for check issues or bugs in your card.