<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>I am using ISDN - net and cpe signalling (gateway functionality)</div><div><br></div>Adding the extra check for the "s" extension will not be very meaningful - because with immediate=yes there will always be an "s" extension - and it would then also affect normal "provide dialtone for isdn telephone to be able to dial out" operation - and limit this dialtone to 3 seconds. Or do i miss here something ?<div>
<br></div><div>So to make it configureable would be better - or make other defaults depending on the signalling - if it is bri_net - then let the timeout be as high as 8 seconds with no match - and 3 seconds with match. If it is bri_cpe - then let the timeout always be 3 seconds.</div>
<div><br></div><div><br></div><div>About the DNID issue - i have my fix now on a box and testing it currently - it does work like a charm. I have submitted a bug report with the patch attached</div><div><a href="https://issues.asterisk.org/view.php?id=17568" target="_blank">https://issues.asterisk.org/view.php?id=17568</a></div>
<div><br></div><div>best regards,</div><div>Wolfgang</div><br><div class="gmail_quote">2010/6/30 Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Am 30.06.2010 09:10, schrieb Wolfgang Pichler:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
i have a question / bug report about the chan_dahdi dnid handling...<br>
<br>
I am setting up a gateway system - for use in austria. In Austria we can<br>
get the dnid complete on a new call (we call it Blockwahl) - or we do<br>
get it as dtmf sequence (we call it Einzelwahl).<br>
<br>
Setting up chan_dahdi with immediate=no does work for this - but if the<br>
call is comming - and does not have the complete set - then asterisk<br>
will wait 8 seconds to send the call to the s extension - which is<br>
definitly to long.<br>
</blockquote>
<br></div>
Are you using analog or ISDN?<br>
<br>
Maybe you discovered another bug, but I think there is another problem when handling the received digits:<br>
<br>
channels/chan_dahdi.c:<br>
if (ast_exists_extension(chan, chan->context, exten, 1, p->cid_num))<br>
timeout = matchdigittimeout;<br>
else<br>
timeout = gendigittimeout;<br>
res = ast_waitfordigit(chan, timeout);<br>
<br>
If chan_dahdi does not find a matching extension, e.g. if there is no dnid provided, it sets the timeout to gendigittimeout=8 seconds, which is IMO really much to big. The usual overlap timeout of matchdigittimeout=3 seconds is more appropriate.<br>
<br>
You could make the gendigittimeout and matchdigittimeout configurable, or change the logic for exmaple to check for "s" extension in case of missing DNID:<br>
<br>
if (ast_exists_extension(chan, chan->context, exten, 1, p->cid_num))<br>
timeout = matchdigittimeout;<br>
else {<br>
if (ast_strlen_zero(exten) &&<br>
ast_exists_extension(chan, chan->context, "s", 1, p->cid_num)) {<br>
timeout = matchdigittimeout;<br>
} else {<br>
timeout = gendigittimeout;<br>
}<br>
}<br>
res = ast_waitfordigit(chan, timeout);<br>
<br>
regards<br><font color="#888888">
Klaus<br>
</font></blockquote></div><br>