<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    This has been solved.&nbsp; BT Openreach identified an issue with the
    exchange configuration that was forcing the lead number to be used
    as the outgoing caller id irrespective of the number from our FS
    box.&nbsp; Many thanks to those who have offered helpful suggestions; it
    has allowed me to eliminate all alternatives and, ultimately, to
    articulate the fault in terms of non-compliance with Q951.3.<br>
    <br>
    Summary of solution:<br>
    <br>
    <blockquote>Outgoing NPI: ISDN<br>
      Outgoing TON: national<br>
      Outgoing number format: 10 digit (ie strip leading 0)<br>
    </blockquote>
    <br>
    Fault report that finally got results (real numbers have been
    substituted):<br>
    <br>
    <blockquote>For outgoing calls, SNDDI numbers (654321 or 654322)
      presented in the Calling Number Information Element of the Q931
      SETUP packet with the screening indicator set to 'user-provided,
      verified and passed' are being overwritten by the BT exchange to
      the default number (654320) with the screening indicator set to
      'network provided'.&nbsp; This is contrary to Q951.3 which requires
      properly constituted Calling Numbers to be passed [irrespective of
      the CLIP supplementary service being provided].&nbsp; The fault can be
      replicated by dialling 654320 or 654322 from 654321.&nbsp; The Caller
      ID passed should be 1234654321 but instead is 1234654320.<br>
    </blockquote>
    Helpful diagnosis tools/hints:<br>
    <ul>
      <li>Anecdotes from former BT engineers suggest that testing CLI
        with mobile phones is bad practice; mobile phone companies pick
        up some strange signalling.&nbsp; I am not sure that this isn't just
        folklore or due to number-matching algorithms in the handset,
        but I chose to use my home analogue landline for testing.</li>
      <li>Making calls back to the same set of lines means that you can
        see the full signalling for both outgoing and terminating legs,
        and the only thing in the way is the local exchange.</li>
      <li>wanpipemon allows Sangoma board users to capture the D-channel
        signalling and then view/process using wireshark/tshark.&nbsp; This
        is a game-changer.&nbsp; Syntax is:<br>
        <pre wrap="">wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -full <span class="moz-txt-citetags"></span>-systime -c<span class="moz-txt-citetags"> </span>trd
</pre>
        Replace w1g1 with the wanpipe device name, and the output will
        go to isdn.pcap.&nbsp; You will need to run one capture for each BRI
        line you have (eg w2g1, w3g1 etc and to isdn1.pcap, isdn2.pcap,
        etc).<br>
      </li>
    </ul>
    I hope to put something somewhere on the Wiki with this information
    when I get a spare moment (currently scheduled for Jan 2034).<br>
    <br>
    Thanks again to all those who have helped resolve this.<br>
    <br>
    John<br>
    <br>
    On 13/07/11 21:16, John wrote:
    <blockquote cite="mid:4E1DFD11.40805@earthspike.net" type="cite">
      <pre wrap="">Thanks, Gavin. That would be really useful.

John

On 08/07/11 19:51, Gavin Henry wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi John,

We set this up for a customer using a Sangoma card and FusionPBX not
long ago. I can dig out the config next week when back in the office.
It's for ISDN30e but should help.

Thanks.

On 7/7/11, John<a class="moz-txt-link-rfc2396E" href="mailto:freeswitch@earthspike.net">&lt;freeswitch@earthspike.net&gt;</a>  wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Jan,

I have tried every combination of unknown, national and international
with every combination of number length.  I have also confirmed that by
using wanpipemon to capture the D-channel messages.  When I went through
them with Wireshark and compared them with Q.931, everything was being
set correctly by the Sangoma card/drivers.  I am at the point now where
I need someone who has worked with BT ISDN switches to tell me what they
can accept.  It seems that this is a national secret over here, or
instead that they can accept almost anything and my lines have been
configured to override the outgoing calling number with the base
number.  Either way, the only way in which I think I am now going to get
a result is by booking a fault.  Your helpful comment about modern
switches being able to work this out also confirms that I am probably
not looking at a Q.931 formatting error on my part, but on a blockage in
the exchange.  I don't have a problem with the called number, for example.

John

On 07/07/11 23:09, Jan Berger wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">I must admit I don't remember what CLIP and CLOP is -- and my Q.931
experience is getting a bit rusty...

Can you get a snoop of L3 out and in so I can see what you send and
what the switch responds back?

I prefer to use Called and Calling -- The numbers contain a few bits
that tell what number this is. The most common are unknown, national
and international. These bits must match the actual number you send.
The 10 digit number is a unknown, the 11 digit is a national.
International start with 00 nn

On top of that you will face that modern switches are quite capable
and able to configure whatever behaviour they want per line with
regards to called/calling -- so you need to find out exactly what the
switch expect on both called and caller for outgoing to behave as you
want.

/Jan

</pre>
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">On our PRI systems we are sending 10 digits (2071231234), and on the
BRI system we are sending 11 digits (02071231234).

</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">

_______________________________________________
Join us at ClueCon 2011, Aug 9-11, Chicago
<a class="moz-txt-link-freetext" href="http://www.cluecon.com">http://www.cluecon.com</a> 877-7-4ACLUE

FreeSWITCH-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>


</pre>
    </blockquote>
    <br>
  </body>
</html>