Dial Bug() asterisk-1.8.4.2

Asterisk Asterisk General
1

Hi. there!
I discover a BUG when using Dial()

Check this example. I’m going to write an example of a dialplan to make outbound call to florida (ZIP: 305). You can do your own.

Let’s write the dialplan:

exten=>_305XXXXXXX,1,Answer() exten=>_305XXXXXXX,n,Dial(Dahdi/2/w${EXTEN})

Where is the BUG :open_mouth: ?? Wait buddy… and keep reading 8)
A traditional phone number have 10 digits. You agree with me? Right! :wink:

Using the DialPlan I wrote you can place call in this way:
3055359999 You agree with me? Right! :wink:
Check the number have 10 digits. Count it. :smiley:

Ok. Lets continue. Now hangup the phone, and dial the same number and instead of 10 digits. Use 11 digits. Like this:
30553599998

Now what happened? Simple, you dialing to: 30553599998 <–The digit 8 insert a BUG in the Dahdi Channel and what you get? You will get the REAL DIAL TONE TO DIAL EVERYWHERE IN THE WORLD.

This BUG is EXTREMELY IMPORTANT to FIX!

I discover this bug using this softwares:

asterisk-1.8.4.2 dahdi-linux-2.4.1.2 asterisk-addons-1.6.2.3 dahdi-tools-2.4.1 libpri-1.4.11.5

Hope for you comments! I REPEAT! THIS BUG IS VERY VERY IMPORTANT TO FIX

2

This:

exten=>13,1,Answer()
exten=>_305XXXXXXX,n,Dial(Dahdi/2/w${EXTEN})

isn’t valid.

That’s two different extensions. The first is for “13” and all Asterisk does it Answer.
The second is for a pattern beginning with 305, followed by 7 digits (0-9), but there’s no first priority, just an n.

3

I edited the topic!!! Check this topic again! Go UP of this PAGE

4

Can you provide the complete logs. There is one thing isn’t matching. In your context You are using a 10 digits dialpattern so if you add an extra number the normal thing is a NOT FOUND dialpattern. So maybe you have another exten that match 11 digits.

5

Thanks for flagging my post, peace out.

6

You haven’t yet posted any evidence of a bug. I think it much more likely that you have a dialplan error. Without verbose console output, as indicated by navaismo, the channel driver configuration, and all the dialplan priorities referenced in the logs, it is difficult to say what is really happening.

See: catb.org/~esr/faqs/smart-que … idp5122192

Also note that phone numbers are not all 10 digits long, even within a country.

Your corrected dialplan fragment will be ignored for 11 digit numbers, so, if you are seizing an outgoing line, it must be the result of a Dial call elsewhere in the dialplan.

As usual, this is the wrong forum for support questions.

7

Psst I know this is a Dial() BUG.

Anyway i’m going to write my configs file:

SECTION 1.0
dadhi-channels.con[code]
; Span 1: WCTDM/4 “Wildcard TDM400P REV E/F Board 5” (MASTER)
;;; line="1 WCTDM/4/0 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=1
context=in-fxo
channel => 1

;;; line="2 WCTDM/4/1 FXSKS (In use)"
signalling=fxs_ks
callerid=asreceived
group=1
context=in-fxo
channel => 2
[/code]

SECTION 2.0
sip.conf

[2301] type=friend defaultuser=2301 secret=******** context=internal-phones callerid="Manuel Manuel" <2301> mailbox=2301 videosupport=yes callgroup=1 pickupgroup=1 language=en host=dynamic port=5060 dtmfmode=rfc2833 allow=all limitonpeers=yes call-limit=50 canreinvite=yes nat=yes subscribecontext=hints qualify=yes qualify=5000 qualifyfreq=10 sendrpid=yes

SECTION 3.0
extensions.conf

[internal-phones]
; Internal dial plan
exten=>_XXX,1,Answer()
exten=>_XXX,n,Dial(SIP/${EXTEN})

; Dial local numbers
exten=>_XXXXXXXXXX,1,Answer()
exten=>_XXXXXXXXXX,n,Dial(Dahdi/3/w${EXTEN})[/code]


SECTION 4.0
The LINKSYS PHONE SPA942 DIALPLAN IS:
[code](XXX|XXXXXXXXXX)

The asterisk CLI when dialing out is the next:

LOG#1
Normal call of 10 digits:

Linux*CLI> == Using SIP RTP CoS mark 5 -- Executing [3055359999@internal-phones:1] Answer("SIP/2301-00000006", "") in new stack -- Executing [3055359999@internal-phones:2] Dial("SIP/2301-00000006", "Dahdi/3/w3055359999") in new stack -- Called 3/w3055359999 -- DAHDI/3-1 answered SIP/2301-00000006 -- Hanging up on 'DAHDI/3-1' -- Hungup 'DAHDI/3-1' == Spawn extension (internal-phones, 1, 2) exited non-zero on 'SIP/2301-00000006' Linux*CLI>
NOTE:

This line doesn’t appear in the LOG#2[/b]

LOG#2
Calling using 11 digits:

Linux*CLI> == Using SIP RTP CoS mark 5 -- Executing [3055359999@internal-phones:1] Answer("SIP/2301-00000007", "") in new stack -- Executing [3055359999@internal-phones:2] Dial("SIP/2301-00000007", "Dahdi/3/w3055359999") in new stack -- Called 3/w3055359999 -- Hanging up on 'DAHDI/3-1' -- Hungup 'DAHDI/3-1' == Spawn extension (internal-phones, 1, 2) exited non-zero on 'SIP/2301-00000007' Linux*CLI>

NOTE:

At this point, I hear the REAL DIAL TONE of FXO line.

This is why because I don’t dial anywhere, I just hangup the handset.

Additional note: The number I’m dialing in LOG#1 is: 305-535-9999
Additional note: The number I’m dialing in LOG#2 is: 305-535-99996
The: 6 doesn’t appear in the LOG#2.
It doesn’t appear Because My Linksysphone is configured to dial numbers with 3 digits and 10 digits.
Check SECTION 4.0 inmediatly my phone detect 10 digits It interprete as VALID and send the Digits to Asterisk PBX. The digit #11 I sent, now is not processed by the Linksys Phone. Is now begin Processed by Asterisk.

I really don’t know why this is happening.

Test yourself in your PBX.
Note: Just dial a number dialing out via Dadhi channel and add an extra digit at the end. Example
Dial 11111111119 and you will see that the asterisk do the same like me in LOG#2.

Note: You must have configured your phone to inmediatly dial when you enter 10 digits number.

Let me know your result.

8

Right, so your phone aren’t sending 11 digits! Only 10 digits thats why asterisk found a valid context and extension to dial out.

Also you can provide the sip debug and you can check in the INVITE the number sent by the Phone.

False at least with that logs, Asterisk never receive a 11 digit(number 6) based on your log Asterisk still processing 10 digits—>Executing [3055359999@internal-phones:1]

Add the sip debug to see the INVITE.

About the:

Maybe has to do with your disconnection supervision.

9

There are complex issues to do with early media here. I am pretty sure that using the r or m option on Dial will block this behaviour. I’m not sure whether is a security issue yet, as I don’t know whether dahdi will actually forward early media towards the callee before it has finished dialing.

Using Progress, rather than Answer, will prevent many SIP phones from encountering this. There is no obvious reason to use Answer here. Going directly into Dial should stop all SIP phones from doing anything, although the lack of call progress indications from an analogue line may be a usability problem.

One important point. This is not do do with 11 digit numbers. It actually do do with sending DTMF in the media stream after the dialing information has been sent, but before the call is fully dialed. Only a 10 digit number was present in the SIP INVITE.

It will concern very few people, as nearly everyone who would care about the issue will not be using analogue lines, and most people using analogue would not need to use w digits. In fact, quite a few of your problems seem to be due to trying to do on analogue lines what would normally be done on ISDN, either directly, or via an ITSP. Most people using analogue lines use them in a system high security environment, often home systems.

The fact that you are hearing dial tone isn’t actually particularly important, although there is an interesting question as to why you only start hearing the dial tone when you send a DTMF digit after dialing, as the dial tone will always be there because of the w digit. Some idea of timescales may be important, as it is just possible that the early media DTMF is disrupting the normal dialing sequence in chan_dahdi, or the dahdi analogue line driver.

If you don’t use musiconhold or ringing options on Dial, dial will forward voice and audio frames to all the outgoing channels. If you also only have one outgoing channel, it will forward incoming frames to the caller.

Incidentally, the fact that the dial tone doesn’t stop quickly, suggests that the excess digit has not been output by dahdi, so, even if it has aborted the main dial sequence, it sounds like it might not be allowing through dialing.

10

How to fix this?

11

Have you tried the suggestions I already made?

At the moment you are still not providing enough hard evidence to justify a bug report and your confused understanding of what is really happening is not going to help someone treat a bug report seriously, so I can’t really advocate raising a bug report yet.

Even if you do so, there is no guarantee of a quick fix, especially given the relatively few people for which it would be significant.

At the moment, I think it is probably 50:50 whether you have a real bug, but I’ve put a lot more effort into trying to draw out the facts than the person triaging the bug report will do. (You still didn’t answer some of my last set of questions.)

I don’t have dahdi hardware, and in particular, analogue dahdi hardware, so I can’t try and reproduce the problem myself. Because of that, I also haven’t done a lot of reading of the chan_dadhi and dahdi source code, so I can’t find my way around it quickly to see how it would handle AST_CONTROL_DTMF whilst still sequencing through the dialed digits. Moreover, it means I don’t know exactly what debugging would be needed to reveal the necessary level of detail.

You are always asking how to fix something, but some times fixing things can involve many man hours of skilled programmer time. Some amy even involve such fundamental changes that they require man years and ore economically feasible to do.

Anyway, I did tell you how to make it impossible for many SIP phones to send DTMF before dialing is complete, and I did tell you how to make it impossible for that to happen, if you were prepared to sacrifice in band progress indications.

Of course, asking on the right forum might increase your chances of finding someone who can reproduce the problem and write a good bug report.

12

Please provide the sip debug of the phone.

13

If there is a problem, and it is where I think it is, he’ll need to provide logs that show the DTMF tones actually output by the low level dahdi driver. A system call trace may also help.

I think what the SIP trace will show is:

INVITE with 10 digits
A possible 401 exchange
Trying
200 OK – note that he is answering the incoming side before he has even started to dial the outgoing one

and nothing more, as the 11th digit will be in the RTP stream not the SIP stream.