[Freeswitch-users] [SOLVED] Re: UK ISDN outgoing CLI
Giovanni Maruzzelli
gmaruzz at gmail.com
Thu Jul 14 16:36:37 MSD 2011
Thanks a lot for this detailed report.
Please, take a moment to at least cut and paste this mail in the wiki.
If deemed necessary, others will edit/reformat it.
-giovanni
On 7/14/11, John <freeswitch at earthspike.net> wrote:
> This has been solved. 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. 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.
>
> Summary of solution:
>
> Outgoing NPI: ISDN
> Outgoing TON: national
> Outgoing number format: 10 digit (ie strip leading 0)
>
>
> Fault report that finally got results (real numbers have been substituted):
>
> 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'.
> This is contrary to Q951.3 which requires properly constituted
> Calling Numbers to be passed [irrespective of the CLIP supplementary
> service being provided]. The fault can be replicated by dialling
> 654320 or 654322 from 654321. The Caller ID passed should be
> 1234654321 but instead is 1234654320.
>
> Helpful diagnosis tools/hints:
>
> * Anecdotes from former BT engineers suggest that testing CLI with
> mobile phones is bad practice; mobile phone companies pick up some
> strange signalling. 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.
> * 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.
> * wanpipemon allows Sangoma board users to capture the D-channel
> signalling and then view/process using wireshark/tshark. This is
> a game-changer. Syntax is:
>
> wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -full-systime
> -c trd
>
> Replace w1g1 with the wanpipe device name, and the output will go
> to isdn.pcap. You will need to run one capture for each BRI line
> you have (eg w2g1, w3g1 etc and to isdn1.pcap, isdn2.pcap, etc).
>
> I hope to put something somewhere on the Wiki with this information when
> I get a spare moment (currently scheduled for Jan 2034).
>
> Thanks again to all those who have helped resolve this.
>
> John
>
> On 13/07/11 21:16, John wrote:
>> Thanks, Gavin. That would be really useful.
>>
>> John
>>
>> On 08/07/11 19:51, Gavin Henry wrote:
>>> 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<freeswitch at earthspike.net> wrote:
>>>> 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:
>>>>> 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
>>>>>
>>>>>>> On our PRI systems we are sending 10 digits (2071231234), and on the
>>>>>>> BRI system we are sending 11 digits (02071231234).
>>>>>>>
>>
>> _______________________________________________
>> Join us at ClueCon 2011, Aug 9-11, Chicago
>> http://www.cluecon.com 877-7-4ACLUE
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
>
--
Sent from my mobile device
Sincerely,
Giovanni Maruzzelli
Cell : +39-347-2665618
More information about the FreeSWITCH-users
mailing list