<div class="gmail_quote">On Wed, Nov 17, 2010 at 10:24 PM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir.cohen@xorcom.com">tzafrir.cohen@xorcom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
Before the change, the following configuration would be generated for a<br>
span (in this case: channel for span 1)<br>
<br>
cas=1-15,17-32,1101<br>
dchan=16<br>
<br>
That second line was added later on as I noticed that without it some<br>
things break (things to do with the 16-th time slot. I'll try to figure<br>
them out later).<br>
<br>
Could you please elaborate on the bug DAHDI-763 ?<br>
<br>
--<br>
Tzafrir Cohen</blockquote><div> </div></div>Tzafrir,<br>When configurations were generated for MFC/R2 links, the
dchan line would generate an error since (as of rev 9056) signaling is
not allowed to be set on channel 16 of E1 CAS lines because it is
reserved for robbed bit data. I added this restriction in the single,
dual, and quadspan drivers to ensure the channel can not be overwritten
accidentally, but I apparently neglected the xpp drivers. Would you
agree that channel 16 should never be directly written to when in E1 CAS
mode?<br>
<br>Kinsey