Hi all,<div><br></div><div>i have a question / bug report about the chan_dahdi dnid handling...</div><div><br></div><div>I am setting up a gateway system - for use in austria. In Austria we can get the dnid complete on a new call (we call it Blockwahl) - or we do get it as dtmf sequence (we call it Einzelwahl).</div>

<div><br></div><div>Setting up chan_dahdi with immediate=no does work for this - but if the call is comming - and does not have the complete set - then asterisk will wait 8 seconds to send the call to the s extension - which is definitly to long.</div>

<div><br></div><div>So i tried to use immediate=yes - and do provide my own logic - so far so good - but i have encountered a problem with the calls which are coming in using Blockwahl.</div><div><br></div><div>On a blockwahl call i will get the dialed extension in the dnid variable - thats ok.</div>

<div>But if you get a new call - without dnid after a call with dnid - then the dnid field won&#39;t get reset. So you have the dnid of the last call available.</div><div>So jumping based on dnid is not possible - would cause unexpected behaviour.</div>

<div><br></div><div>I have taken a look at the source - and found in chan_dahdi around line 12980 the following</div><div><br></div><div>---------------------------------------------------------------------------------------------------------------------------------------------</div>

<div><div>/* Set DNID on all incoming calls -- even immediate */</div><div>if (!ast_strlen_zero(e-&gt;ring.callednum))</div>
<div><span style="white-space:pre-wrap">        </span>ast_copy_string(pri-&gt;pvts[chanpos]-&gt;dnid, e-&gt;ring.callednum, sizeof(pri-&gt;pvts[chanpos]-&gt;dnid));</div><div>---------------------------------------------------------------------------------------------------------------------------------------------</div>

<div><br></div></div><div>As far as i can interpret this right - on immediate it does check if it got a callednum - if so - then copy it - if not - then.... nothing....</div><div>the pri-&gt;pvts[chanpos] seems not to be a structure which does get allocated on new calls - so the value of the old call will be in there.</div>

<div><br></div><div>I would suggest to change it to</div><div><br></div><div><div>---------------------------------------------------------------------------------------------------------------------------------------------</div>

<div><div>/* Set DNID on all incoming calls -- even immediate */</div><div>if (!ast_strlen_zero(e-&gt;ring.callednum))</div><div><span style="white-space:pre-wrap">        </span>ast_copy_string(pri-&gt;pvts[chanpos]-&gt;dnid, e-&gt;ring.callednum, sizeof(pri-&gt;pvts[chanpos]-&gt;dnid));</div>

<div>else</div><div><span style="white-space:pre-wrap">        </span>pri-&gt;pvts[chanpos]-&gt;dnid[0] = &#39;\0&#39;;</div><div>---------------------------------------------------------------------------------------------------------------------------------------------</div>

</div></div><div><br></div><div>so it should always contain the valid dnid...</div><div><br></div><div>To get it better working with immediate=no - i would suggest the following</div><div><br></div><div>Lets add some new config options - which are channel specific - to control the generic digit timeout and the match digit timeout. So it would be possible to set the generic and match digit timeout on bri_net channels to a higher value then on bri_cpe channels.</div>
<div><br></div><div>I think the change wouldn&#39;t be that hard - or i am wrong with this ?</div><div><br></div><div>What do you think about this ?</div><div><br></div><div>best regards,</div><div>Wolfgang</div>