Sidharth, You are right. I'm new to the list and have since found pastebin. Thank you. John On 09/06/11 04:21, Sidharth Kshatriya wrote:

Dear John,

Appreciate the long time you took in putting down your queries. I'd like to help but unfortunately don't have domain expertise in the areas you're having problems.

Your mail is more likely to be read if it was shorter. May I suggest you use http://pastebin.freeswitch.org/ to paste all your debug messages and configurations.

Please ignore this message if you don't agree with the strategy.

Thanks,

Sidharth

On Tue, Jun 7, 2011 at 3:06 AM, John <freeswitch@earthspike.net <mailto:freeswitch@earthspike.net>> wrote:

Hello,

[ ... ]

[I've forked this thread as it really should have been 3 separate threads to start with.] Thanks, I have tried every combination I can think of, except 10 digits which I will give a go. That makes sense as in the general case it would permit non-geographical numbers to be presented. The lines are provided as 2 x ISDN2e with a lead number covering all 4 channels. The NTE8s are labelled 1-2 and 3-4, so not separate individual lines, I thnk. We currently have a Single Number DDI in addition, and hope to increase that to 2 very soon; the 3 numbers between them will serve 3 separate business units, so we want to be able to present the correct outbound CLI from each business unit. We also have a remote call forward from another number to the lead number, but presenting that really would be CLI spoofing, so I am not expecting that to be permissible. But I would expect those that are directly allocated to the 2 lines/4 channels to be allowed to be presented. John On 09/06/11 08:27, shouldbe q931 wrote:

On Mon, Jun 6, 2011 at 10:36 PM, John<freeswitch@earthspike.net> wrote:

...

Hello,

<snipped for brevity>

...

2. We have 2 Single Number DDI numbers configured over the 4 channels. I want to set up outgoing calls so that they can appear to come from either of the two numbers, but at present the outgoing CLI appears to be overridden by the telco (BT) to only use one of the numbers. Has anyone got this working in UK, and what is the format for the outbound_caller_id_number: last 6 digits or full 11 digits? I note that the inbound called number is only the last 6 digits.

<snipped for brevity>

...

Thanks for all the great support I have already got just from editing my Wiki User page; this is a friendly group!

John

I can only comment on the BT part.

If they are two individual lines, you're out of luck with BT, as they do not allow CLI spoofing, which this would be.

I would suggest sending BT the same number of digits that they send you, if that doesn't work try 10 digits. If you are not sending the "correct" number of digits for a valid DDI on the trunk, then they will send the lead number for the trunk.

Cheers

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Shouldbe, You won't be burned at the stake for heresy and are probably right that this is the problem, as we have had delays in getting CLIP implemented. From your comment I assume that COLP is not automatically enabled (even though I am paying for additional SNDDIs) but has to be ordered specifically. Our service provider is on to it, and I am waiting till CLIP/COLP is applied before doing any more testing. I'll post here with the results. John On 10/06/11 10:08, shouldbe q931 wrote:

On Thu, Jun 9, 2011 at 7:10 PM, John<freeswitch@earthspike.net> wrote:

...

[I've forked this thread as it really should have been 3 separate threads to start with.]

Thanks,

I have tried every combination I can think of, except 10 digits which I will give a go. That makes sense as in the general case it would permit non-geographical numbers to be presented.

The lines are provided as 2 x ISDN2e with a lead number covering all 4 channels. The NTE8s are labelled 1-2 and 3-4, so not separate individual lines, I thnk.

We currently have a Single Number DDI in addition, and hope to increase that to 2 very soon; the 3 numbers between them will serve 3 separate business units, so we want to be able to present the correct outbound CLI from each business unit. We also have a remote call forward from another number to the lead number, but presenting that really would be CLI spoofing, so I am not expecting that to be permissible. But I would expect those that are directly allocated to the 2 lines/4 channels to be allowed to be presented.

John

On 09/06/11 08:27, shouldbe q931 wrote:

...

On Mon, Jun 6, 2011 at 10:36 PM, John<freeswitch@earthspike.net> wrote:

...

Hello,

<snipped for brevity>

...

2. We have 2 Single Number DDI numbers configured over the 4 channels. I want to set up outgoing calls so that they can appear to come from either of the two numbers, but at present the outgoing CLI appears to be overridden by the telco (BT) to only use one of the numbers. Has anyone got this working in UK, and what is the format for the outbound_caller_id_number: last 6 digits or full 11 digits? I note that the inbound called number is only the last 6 digits.

<snipped for brevity>

...

Thanks for all the great support I have already got just from editing my Wiki User page; this is a friendly group!

John

I can only comment on the BT part.

If they are two individual lines, you're out of luck with BT, as they do not allow CLI spoofing, which this would be.

I would suggest sending BT the same number of digits that they send you, if that doesn't work try 10 digits. If you are not sending the "correct" number of digits for a valid DDI on the trunk, then they will send the lead number for the trunk.

Cheers

_______________________________________________ I know that this might sound like heresy :-) but have you checked spoken to BT and asked them if CLIP and CLOP on the lines ?

I think CLOP is outbound and CLIP is inbound, but I might have it the wrong way round...

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

On Mon, Jun 13, 2011 at 7:55 AM, Mike Raistrick <michael.raistrick@googlemail.com> wrote:

I've no direct experience with BT BRA ISDN (plenty with other providers) - but I don't think that CLIP / COLP will be the issue. CLIP is an inbound service - and determines whether your equipment is presented with the number of the person calling you (and if they allow it). Although COLP is an outbound service, it is used to display the number of the line that you are connected through to (which might not be the same as the number you dialled - e.g. 0800 numbers). Whilst we're on supplementary services, CLIR is also an outbound service and allows you to specify whether the CLI that you send (or the one that BT uses) can be shown to the person you call. Some terminogy: ISDN Basic Rate differentiates Direct Dial In (DDI's) and Multiple Subscriber Numbers (MSNs) for incoming services. DDIs are designed for PBXs and are associated with a range of numbers in a block. The service provider sends you a called party number that can range either from the last 'X' digits through to the whole number - this is normally specified when the service is ordered and then all calls are delivered the same way. With DDIs - when you send an outgoing call you should be able to send the extension or the whole number - in either case you should mark the Type Of Number field accordingly (and if in national format - not include the '0' for the number itself). In case that you send the extension digits - the service provider adds this to the DDI 'stem' to get the full number. With the full number (either derived from the extension, or as you sent it) - the provider should then check that the number is in the allocated DDI range - if it is it will allow it through, if not it will usually send the root DDI number. MSNs are unique to BRA - they are completely separate telephone numbers and were originally designed to allow multiple BRA phones to be off the same ISDN bus and have their own phone numbers. This means that the full number will always be sent to you, and be expected from you for called and calling numbers (still with the right Type Of Number set..). Summary - with either DDI or MSNs - you should be OK to send the whole number to BT as the calling party - minus the '0' and with TON set to 'national'. Finally - if you do have the CLIR supplementary service, make sure that you set the presentation indicator to 'allowed' - default should normally be to assume allowed unless set differently - but to be on the safe side. Mike

From my experience with BT, unless you have COLP, you will only send the lead number of the trunk, you only need CLIR if you want to be able to restrict

On Fri, Jun 17, 2011 at 7:08 PM, John <freeswitch@earthspike.net> wrote:

Mike, Shouldbe,

We now have CLIP on the line for sure, and I ordered COLP at the same time and am assured that that has been turned on as well, but I still cannot get outgoing CLI to work properly.  Mike, you mention setting the TON to 'national'; where is that setting?

At the moment, my dialplan looks like http://pastebin.freeswitch.org/16548 with .  An outgoing call gives the log 7 at http://pastebin.freeswitch.org/16549 (numbers have been changed to protect the innocent!) but the number that 01234 567890 sees on their Caller ID is not 876543 but the main number of the line (876540, say).  I have tried setting the outgoing_caller_id_number to 6, 10 and 11 digits, restarting FS after each change, but with no success.

The service provider has only one clue to offer: "With regards to the configuration at the exchange, the line is set to 6 digits to switch." which makes eminent sense, and suggests that I should be presenting 6 digits. Incoming calls have a 6 digit called number and 10 digit calling number.

Thanks for the help so far.  Any other ideas?

John

I don't have any experience with FS connecting over ISDN so can't help you much further on the FS configuration:-( However on the lines, I would be very tempted to see if you can borrow a BRI tester, or what I've frequently used in the past is an Eicon/Dialogic card as the test functions (under windows) are nearly as good, that might help you see if it _is_ a BT problem, or a FS configuration issue. It would need a 2k/XP machine, but something like http://cgi.ebay.co.uk/EICON-DIVA-2-01-PCI-GRAPHICS-CARD-/270761571564 is what I have used in the past. I think I might have one of the PCMCIA ones somewhere, but I'd need to test it still works I'm fairly sure that the "6 digits to switch" is what they are sending to you, not what they are expecting from you. I can't access out remaining BRI (Avaya) PBX from here, but on our PRI (again Avaya) switches, we are sending 10 digits. Cheers

On 06/07/11 13:53, shouldbe q931 wrote:

On Fri, Jun 17, 2011 at 7:43 PM, shouldbe q931<shouldbeq931@gmail.com> wrote:

...

On Fri, Jun 17, 2011 at 7:08 PM, John<freeswitch@earthspike.net> wrote:

...

Mike, Shouldbe,

We now have CLIP on the line for sure, and I ordered COLP at the same time and am assured that that has been turned on as well, but I still cannot get outgoing CLI to work properly. Mike, you mention setting the TON to 'national'; where is that setting?

At the moment, my dialplan looks like http://pastebin.freeswitch.org/16548 with . An outgoing call gives the log 7 at http://pastebin.freeswitch.org/16549 (numbers have been changed to protect the innocent!) but the number that 01234 567890 sees on their Caller ID is not 876543 but the main number of the line (876540, say). I have tried setting the outgoing_caller_id_number to 6, 10 and 11 digits, restarting FS after each change, but with no success.

The service provider has only one clue to offer: "With regards to the configuration at the exchange, the line is set to 6 digits to switch." which makes eminent sense, and suggests that I should be presenting 6 digits. Incoming calls have a 6 digit called number and 10 digit calling number.

Thanks for the help so far. Any other ideas?

John

I don't have any experience with FS connecting over ISDN so can't help you much further on the FS configuration:-(

However on the lines, I would be very tempted to see if you can borrow a BRI tester, or what I've frequently used in the past is an Eicon/Dialogic card as the test functions (under windows) are nearly as good, that might help you see if it _is_ a BT problem, or a FS configuration issue. It would need a 2k/XP machine, but something like http://cgi.ebay.co.uk/EICON-DIVA-2-01-PCI-GRAPHICS-CARD-/270761571564 is what I have used in the past. I think I might have one of the PCMCIA ones somewhere, but I'd need to test it still works

I'm fairly sure that the "6 digits to switch" is what they are sending to you, not what they are expecting from you. I can't access out remaining BRI (Avaya) PBX from here, but on our PRI (again Avaya) switches, we are sending 10 digits.

Cheers

Apologies for the very long delay...

On our PRI systems we are sending 10 digits (2071231234), and on the BRI system we are sending 11 digits (02071231234).

Cheers Thanks. I have tried all of these digit options, along with setting the TON and NPI, so I am now working through every possible option and tweak with the supplier (including including codes to remove/reapply CPS). I am trying to avoid booking this as a fault, until I am sure I won't be charged for a 'no fault found' but it is beginning to look unavoidable. I am certainly building enough information for a good wiki page on this when I finally get it cracked! Incidentally, the Sangoma 'wanpipemon' provides a useful PCAP mode which delivers the entire D-channel as a wireshark PCAP file, so I am able to debug the Q.931 signalling down to bit level.

John

Might be able to help with a Trend, depending on where you are in UK On 7 July 2011 12:21, shouldbe q931 <shouldbeq931@gmail.com> wrote:

On Thu, Jul 7, 2011 at 8:37 AM, John <freeswitch@earthspike.net> wrote:

...

On 06/07/11 13:53, shouldbe q931 wrote:

...

On Fri, Jun 17, 2011 at 7:43 PM, shouldbe q931<shouldbeq931@gmail.com> wrote:

...

On Fri, Jun 17, 2011 at 7:08 PM, John<freeswitch@earthspike.net> wrote:

...

Mike, Shouldbe,

We now have CLIP on the line for sure, and I ordered COLP at the same time and am assured that that has been turned on as well, but I still cannot get outgoing CLI to work properly. Mike, you mention setting the TON to 'national'; where is that setting?

At the moment, my dialplan looks like http://pastebin.freeswitch.org/16548 with . An outgoing call gives the log 7 at http://pastebin.freeswitch.org/16549 (numbers have been changed to protect the innocent!) but the number that 01234 567890 sees on their Caller ID is not 876543 but the main number of the line (876540, say). I have tried setting the outgoing_caller_id_number to 6, 10 and 11 digits, restarting FS after each change, but with no success.

The service provider has only one clue to offer: "With regards to the configuration at the exchange, the line is set to 6 digits to switch." which makes eminent sense, and suggests that I should be presenting 6 digits. Incoming calls have a 6 digit called number and 10 digit calling number.

Thanks for the help so far. Any other ideas?

John

I don't have any experience with FS connecting over ISDN so can't help you much further on the FS configuration:-(

However on the lines, I would be very tempted to see if you can borrow a BRI tester, or what I've frequently used in the past is an Eicon/Dialogic card as the test functions (under windows) are nearly as good, that might help you see if it _is_ a BT problem, or a FS configuration issue. It would need a 2k/XP machine, but something like http://cgi.ebay.co.uk/EICON-DIVA-2-01-PCI-GRAPHICS-CARD-/270761571564 is what I have used in the past. I think I might have one of the PCMCIA ones somewhere, but I'd need to test it still works

I'm fairly sure that the "6 digits to switch" is what they are sending to you, not what they are expecting from you. I can't access out remaining BRI (Avaya) PBX from here, but on our PRI (again Avaya) switches, we are sending 10 digits.

Cheers

Apologies for the very long delay...

On our PRI systems we are sending 10 digits (2071231234), and on the BRI system we are sending 11 digits (02071231234).

Cheers Thanks. I have tried all of these digit options, along with setting the TON and NPI, so I am now working through every possible option and tweak with the supplier (including including codes to remove/reapply CPS). I am trying to avoid booking this as a fault, until I am sure I won't be charged for a 'no fault found' but it is beginning to look unavoidable. I am certainly building enough information for a good wiki page on this when I finally get it cracked! Incidentally, the Sangoma 'wanpipemon' provides a useful PCAP mode which delivers the entire D-channel as a wireshark PCAP file, so I am able to debug the Q.931 signalling down to bit level.

John

If you can see in the capture that you are sending the digits, and the CLI is not being set, then open a fault with BT.

Alternatively, find a friendly "legacy" PBX maintainer that has a trend/harrier, or take your FS box to somewhere that has some BRI lines that are known to work with CLIP and COLP and try your FS box on them...

_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

With some providers I have to set the "screening indicator" of calling party number to "network provided" ... you can add this try... (freetdm_screening_ind = network-provided) Stephen On Fri, Jul 8, 2011 at 12:32 AM, John <freeswitch@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 listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...

_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

John, I am in Oxford. A little way, but I do get over to the west now and again. On 8 July 2011 00:37, Jan Berger <jan.berger@video24.no> wrote:

** **

You should read Q.951 and make sure SETUP is correct it’s a few words, but it’s very straight forward – if your convinced it is correct are call BT.* ***

** **

Q.951 defines how to set up the numbers, so unless BT have given you a specific procedure you go by the spec and claim a fault. Send me the wireshark trace if you want me to look at it – but this should be rather straight forward.****

** **

Jan****

** ** ------------------------------

*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Stephen Wilde *Sent:* 8. juli 2011 01:01

*To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] UK ISDN outgoing CLI (was Re: FreeTDM - Sangoma B700 - ISDN connection questions - ****UK****) ****

** **

With some providers I have to set the "screening indicator" of calling party number to "network provided" ... you can add this try...****

** **

(freetdm_screening_ind = network-provided)****

** **

Stephen****

** **

On Fri, Jul 8, 2011 at 12:32 AM, John <freeswitch@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@lists.freeswitch.org****

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users****

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users****

http://www.freeswitch.org****

** **

_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org****

** **

_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

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@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).

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@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@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@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

And I'd just dug out that config! Well done though. Glad it was their fault!

Nazim, Late last night this got resolved; sorry I didn't post then. We have had problems with the second line, and when these were fixed last night, the problem disappeared. So now I have a nice stable FreeSWITCH with the only outputs on /log 7 being SIP re-registrations. So, you are probably correct, and it was a line quality issue. I've also resolved the device permissions issue with help from Sangoma support, and will post on that/update the Ubuntu Wiki page when I get a moment, probably after the weekend. Thanks, John On 10/06/11 08:41, Nazim Aghabayov wrote:

Hello John,

I'm not an ISDN expert, but have some experience with PRI. Have you checked the line? Sometimes bad physical interconnects makes line noisy. Channels going up and down may indicate a physical line problem or inadequate grounding (or mixed signal / common grounds). I would disable hardware echo-canellation and hw. dtmf during the troubleshooting. On PRI it's possible to trace the D channel with "wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -full -systime -c trd". It should be supported on BRI too, look through wanpipemon manual.

Best Regards, Nazim

On 06/07/2011 02:36 AM, John wrote:

...

Hello,

I have just set up a FreeSWITCH box with a Sangoma B700 connected to 2 x ISDN2e lines (each 2B+D, so 4 voice channels) in UK, so supplied by BT Openreach. There are a number of anomalies that I am trying to solve. [One of these is that 1 line is dead, but that is for BT Openreach to resolve rather than anyone on this list.]

I have a few questions, but as they are all related, I hope you don't mind them in one post. Some basics first. The box is an Atom dual-core with 2GB of memory and a Sangoma B700 card. It's built with Ubuntu 10.04.2 LTS server 64-bit, patched and up to date, and also runs dhcpd, lighttpd and sshd. I built the Sangoma ISDN libraries and FreeSWITCH using the latest git versions I could ('make current' about 2 weeks ago). We have incoming and outgoing calls working, but some incoming calls ring in the caller's ear, but nothing appears on the FreeSWITCH console, and others fail. Rebooting the server cures this. We have had problems with lines being disconnected and then reconnected, and it seems that FreeTDM/wanrouter/whatever doesn't recognise previously disconnected lines coming back into use, because a reboot finds lines that were previously reported disconnected ('wanrouter status' or 'ftdm list'). We have ongoing problems with one line that is 'disconnected' (wanpipe2/wp2) but the queries I am describing below apply equally when both lines are connected and working.

1. There seems to be a lot of ISDN 'chatter' with channels going up and down all the time even when the switch is completely idle. Is this normal? Here is my /log 7 showing two of the cycles (which appear to be about 50s apart):

2011-06-06 22:01:54.992467 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection DN(4): Disconnect initiated(263) 2011-06-06 22:02:29.952464 [WARNING] ftmod_sangoma_isdn_stack_rcv.c:748 [SNGISDN Q931] s1: Interface: Down(261): Dchan(285) 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c1][1:1] Signalling link status changed to DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c2][1:2] Signalling link status changed to DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c3][1:3] Signalling link status changed to DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c1][1:1] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c1][1:1] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c2][1:2] Setting availability rate to:5 2011-06-06 22:02:29.952464 [INFO] mod_freetdm.c:2345 1:1 signalling changed to :DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c2][1:2] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c3][1:3] Setting availability rate to:5 2011-06-06 22:02:29.952464 [INFO] mod_freetdm.c:2345 1:2 signalling changed to :DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c3][1:3] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.952464 [INFO] mod_freetdm.c:2345 1:3 signalling changed to :DOWN 2011-06-06 22:02:29.952464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:631 Received RESTART CFM (dChan:1 ces:0 type:1) 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:1179 Receved RESTART, but Restart Indicator IE not present 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection UP(3): UA frame with F-bit = 1(258) 2011-06-06 22:02:29.972464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:631 Received RESTART CFM (dChan:1 ces:0 type:0) 2011-06-06 22:02:29.972464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:729 [SNGISDN Q931] s1: Interface: UP(260): Dchan(285) 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c1][1:1] Signalling link status changed to UP 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c2][1:2] Signalling link status changed to UP 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c3][1:3] Signalling link status changed to UP 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:1179 Receved RESTART, but Restart Indicator IE not present 2011-06-06 22:02:29.972464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.972464 [INFO] mod_freetdm.c:2345 1:1 signalling changed to :UP 2011-06-06 22:02:29.972464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.972464 [INFO] mod_freetdm.c:2345 1:2 signalling changed to :UP 2011-06-06 22:02:29.972464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.972464 [INFO] mod_freetdm.c:2345 1:3 signalling changed to :UP 2011-06-06 22:03:19.912462 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection DN(4): Disconnect initiated(263) 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection UP(3): UA frame with F-bit = 1(258) 2011-06-06 22:03:19.932483 [INFO] ftmod_sangoma_isdn_stack_rcv.c:631 Received RESTART CFM (dChan:1 ces:0 type:0) 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:1179 Receved RESTART, but Restart Indicator IE not present 2011-06-06 22:03:19.932483 [INFO] ftmod_sangoma_isdn_stack_rcv.c:729 [SNGISDN Q931] s1: Interface: UP(260): Dchan(285) 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c1][1:1] Signalling link status changed to UP 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c2][1:2] Signalling link status changed to UP 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c3][1:3] Signalling link status changed to UP 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:03:19.932483 [INFO] mod_freetdm.c:2345 1:1 signalling changed to :UP 2011-06-06 22:03:19.932483 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:03:19.932483 [INFO] mod_freetdm.c:2345 1:2 signalling changed to :UP 2011-06-06 22:03:19.932483 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:03:19.932483 [INFO] mod_freetdm.c:2345 1:3 signalling changed to :UP freeswitch@internal> ftdm list +OK span: 1 (wp1) type: Sangoma (ISDN) physical_status: ok signaling_status: UP chan_count: 3 dialplan: XML context: public dial_regex: fail_dial_regex: hold_music: analog_options: none +OK span: 2 (wp2) type: Sangoma (ISDN) physical_status: alarmed signaling_status: DOWN chan_count: 3 dialplan: XML context: public dial_regex: fail_dial_regex: hold_music: analog_options: none +OK span: 3 (FXS) type: analog physical_status: ok signaling_status: UP chan_count: 2 dialplan: XML context: default dial_regex: fail_dial_regex: hold_music: analog_options: none

# wanrouter status

Devices currently active: wanpipe1 wanpipe2 wanpipe3

Wanpipe Config:

Device name | Protocol Map | Adapter | IRQ | Slot/IO | If's | CLK | Baud rate | wanpipe1 | N/A | A500/B700| 20 | 0 | 1 | N/A | 0 | wanpipe2 | N/A | A500/B700| 20 | 0 | 1 | N/A | 0 | wanpipe3 | N/A | A200/A400/B600/B700/B800| 20 | 0 | 1 | N/A | 0 |

Wanrouter Status:

Device name | Protocol | Station | Status | wanpipe1 | AFT ISDN | N/A | Connected | wanpipe2 | AFT ISDN | N/A | Disconnected | wanpipe3 | A-ANALOG | N/A | Connected |

# cat /etc/wanpipe/wanrouter.rc #!/bin/sh # .. comments snipped ... ROUTER_BOOT=YES WAN_CONF_DIR=/etc/wanpipe WAN_INTR_DIR=/etc/wanpipe/interfaces WAN_BIN_DIR=/usr/sbin WAN_LOG=/var/log/wanrouter WAN_LOCK=/var/lock/wanrouter WAN_LOCK_DIR=/var/lock WAN_IP_FORWARD=NO NEW_IF_TYPE=NO WAN_LIB_DIR=/etc/wanpipe/lib WAN_ADSL_LIST=/etc/wanpipe/wan_adsl.list WAN_ANNEXG_LOAD=NO WAN_SCTP_LOAD=NO WAN_LIP_LOAD=NO WAN_DYN_WANCONFIG=NO WAN_SCRIPTS_DIR=/etc/wanpipe/scripts WAN_FIRMWARE_DIR=/etc/wanpipe/firmware WAN_DEVICES_REV_STOP_ORDER=YES WAN_DEVICES="wanpipe1 wanpipe2 wanpipe3 "

# cat /etc/wanpipe/wanpipe1.conf #================================================ # WANPIPE1 Configuration File #================================================ # # Note: This file was generated automatically # by /usr/local/sbin/setup-sangoma program. # # If you want to edit this file, it is # recommended that you use wancfg program # to do so. #================================================ # Sangoma Technologies Inc. #================================================

[devices] wanpipe1 = WAN_AFT_ISDN_BRI, Comment

[interfaces] w1g1 = wanpipe1, , TDM_VOICE_API, Comment

[wanpipe1] CARD_TYPE = AFT S514CPU = A CommPort = PRI AUTO_PCISLOT = NO PCISLOT = 0 PCIBUS = 5 FE_MEDIA = BRI FE_LINE = 1 TDMV_LAW = ALAW RM_BRI_CLOCK_MASTER = NO MTU = 1500 UDPPORT = 9000 TTL = 255 IGNORE_FRONT_END = NO TDMV_SPAN = 1 TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS Blue Alarm and keep line down #wanpipemon -i w1g1 -c Ttx_ais_off to disable AIS maintenance mode #wanpipemon -i w1g1 -c Ttx_ais_on to enable AIS maintenance mode TDMV_HW_DTMF = YES # YES: receive dtmf events from hardware TDMV_HW_FAX_DETECT = YES # YES: receive fax 1100hz events from hardware HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation enabled with nlp (default) # OCT_SPEECH: improves software tone detection by disabling NLP (echo possible) # OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of incoming media (must have hwdtmf enabled) HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on the line - could break fax HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic echo cancelation HWEC_NLP_DISABLE = NO # NO: default YES: guarantees software tone detection (possible echo) HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal

[w1g1] ACTIVE_CH = ALL TDMV_HWEC = YES MTU = 80

... and wanpipe2 was also automatically generated so just has '2' for FE_LINE and TDMV_SPAN instead of '1'.

# cat /usr/local/freeswitch/conf/freetdm.conf [span wanpipe wp1] trunk_type => bri group=1 b-channel => 1:1-2 d-channel => 1:3

[span wanpipe wp2] trunk_type => bri group=1 b-channel => 2:1-2 d-channel => 2:3

[span wanpipe FXS] name => freetdm trunk_type => fxs group => grp2 fxs-channel => 3:1

trunk_type => fxs group => grp2 fxs-channel => 3:2

# cat /usr/local/freeswitch/conf/autoload_configs/freetdm.conf.xml <configuration name="freetdm.conf" description="Freetdm Configuration"> <settings> <param name="debug" value="0"/> <!--<param name="hold-music" value="$${moh_uri}"/>--> <!--<param name="enable-analog-option" value="call-swap"/>--> <!--<param name="enable-analog-option" value="3-way"/>--> </settings>

<config_profiles>

<profile name="my_bri_te_1"> <param name="switchtype" value="euroisdn" /> <param name="interface" value="cpe"/> <param name="facility" value="no" /> </profile>

</config_profiles>

<sangoma_bri_spans>

<span name="wp1" cfgprofile="my_bri_te_1"> <param name="dialplan" value="XML"/> <param name="context" value="public"/> </span>

<span name="wp2" cfgprofile="my_bri_te_1"> <param name="dialplan" value="XML"/> <param name="context" value="public"/> </span>

</sangoma_bri_spans>

<analog_spans>

<span name="FXS"> <!--<param name="hold-music" value="$${moh_uri}"/>--> <param name="dialplan" value="XML"/> <param name="context" value="default"/> <!-- regex to stop dialing when it matches --> <!--<param name="dial-regex" value="5555"/>--> <!-- regex to stop dialing when it does not match --> <!--<param name="fail-dial-regex" value="^5"/>--> </span>

</analog_spans>

</configuration>

What other config files do I need to supply? I don't want to deluge the list any more in my first post!

2. We have 2 Single Number DDI numbers configured over the 4 channels. I want to set up outgoing calls so that they can appear to come from either of the two numbers, but at present the outgoing CLI appears to be overridden by the telco (BT) to only use one of the numbers. Has anyone got this working in UK, and what is the format for the outbound_caller_id_number: last 6 digits or full 11 digits? I note that the inbound called number is only the last 6 digits.

3. I have built FreeSWITCH from git and installed at /usr/local/... and then followed the steps on the Ubuntu page in the Wiki to set up the run control scripts, etc, and run FS non-root as freeswitch:daemon. With FreeTDM, I have discovered that the /dev/wan* devices are owned by root:root, and so are inaccessible to FS running as non-root. So for now I have added a line in /etc/init.d/freeswitch to 'chgrp freeswitch /dev/wan*'. This is not the most elegant solution, because 'wanrouter restart' (which seems to be my best friend at the moment) resets the ownership to root:root. I have tried grepping to see where the mknods are for these devices, but have been unsuccessful. Is there a better place to 'permanently' change the device ownership?

Thanks for all the great support I have already got just from editing my Wiki User page; this is a friendly group!

John

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Hi John Would be interesting to hear whether you did something along these lines - creating /etc/udev/rules.d/80-wanpipe.rules containing SUBSYSTEM=="wanpipe", OWNER="freeswitch", GROUP="daemon" SUBSYSTEM=="wp_ec", OWNER="freeswitch", GROUP="daemon" That's what we're doing on Ubuntu 10.04.2, and it seems to work. I assume the solution currently described in the wiki[0] doesn't survive a reboot? Thanks Stephen [0] http://wiki.freeswitch.org/wiki/Ubuntu_Quick_Start#Using_FreeTDM_with_the_.2... On 10 June 2011 09:01, John <freeswitch@earthspike.net> wrote:

Nazim,

Late last night this got resolved; sorry I didn't post then.  We have had problems with the second line, and when these were fixed last night, the problem disappeared.  So now I have a nice stable FreeSWITCH with the only outputs on /log 7 being SIP re-registrations.  So, you are probably correct, and it was a line quality issue.

I've also resolved the device permissions issue with help from Sangoma support, and will post on that/update the Ubuntu Wiki page when I get a moment, probably after the weekend.

Thanks,

John

On 10/06/11 08:41, Nazim Aghabayov wrote:

...

Hello John,

I'm not an ISDN expert, but have some experience with PRI. Have you checked the line? Sometimes bad physical interconnects makes line noisy. Channels going up and down may indicate a physical line problem or inadequate grounding (or mixed signal / common grounds). I would disable hardware echo-canellation and hw. dtmf during the troubleshooting. On PRI it's possible to trace the D channel with "wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -full -systime -c trd". It should be supported on BRI too, look through wanpipemon manual.

Best Regards, Nazim

On 06/07/2011 02:36 AM, John wrote:

...

Hello,

I have just set up a FreeSWITCH box with a Sangoma B700 connected to 2 x ISDN2e lines (each 2B+D, so 4 voice channels) in UK, so supplied by BT Openreach.  There are a number of anomalies that I am trying to solve. [One of these is that 1 line is dead, but that is for BT Openreach to resolve rather than anyone on this list.]

I have a few questions, but as they are all related, I hope you don't mind them in one post.  Some basics first.  The box is an Atom dual-core with 2GB of memory and a Sangoma B700 card.  It's built with Ubuntu 10.04.2 LTS server 64-bit, patched and up to date, and also runs dhcpd, lighttpd and sshd.  I built the Sangoma ISDN libraries and FreeSWITCH using the latest git versions I could ('make current' about 2 weeks ago).  We have incoming and outgoing calls working, but some incoming calls ring in the caller's ear, but nothing appears on the FreeSWITCH console, and others fail.  Rebooting the server cures this.  We have had problems with lines being disconnected and then reconnected, and it seems that FreeTDM/wanrouter/whatever doesn't recognise previously disconnected lines coming back into use, because a reboot finds lines that were previously reported disconnected ('wanrouter status' or 'ftdm list').  We have ongoing problems with one line that is 'disconnected' (wanpipe2/wp2) but the queries I am describing below apply equally when both lines are connected and working.

1. There seems to be a lot of ISDN 'chatter' with channels going up and down all the time even when the switch is completely idle.  Is this normal?  Here is my /log 7 showing two of the cycles (which appear to be about 50s apart):

2011-06-06 22:01:54.992467 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection DN(4): Disconnect initiated(263) 2011-06-06 22:02:29.952464 [WARNING] ftmod_sangoma_isdn_stack_rcv.c:748 [SNGISDN Q931] s1: Interface: Down(261): Dchan(285) 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c1][1:1] Signalling link status changed to DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c2][1:2] Signalling link status changed to DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c3][1:3] Signalling link status changed to DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c1][1:1] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c1][1:1] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c2][1:2] Setting availability rate to:5 2011-06-06 22:02:29.952464 [INFO] mod_freetdm.c:2345 1:1 signalling changed to :DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c2][1:2] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c3][1:3] Setting availability rate to:5 2011-06-06 22:02:29.952464 [INFO] mod_freetdm.c:2345 1:2 signalling changed to :DOWN 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c3][1:3] Setting availability rate to:5 2011-06-06 22:02:29.952464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.952464 [INFO] mod_freetdm.c:2345 1:3 signalling changed to :DOWN 2011-06-06 22:02:29.952464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:631 Received RESTART CFM (dChan:1 ces:0 type:1) 2011-06-06 22:02:29.952464 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:1179 Receved RESTART, but Restart Indicator IE not present 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection UP(3): UA frame with F-bit = 1(258) 2011-06-06 22:02:29.972464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:631 Received RESTART CFM (dChan:1 ces:0 type:0) 2011-06-06 22:02:29.972464 [INFO] ftmod_sangoma_isdn_stack_rcv.c:729 [SNGISDN Q931] s1: Interface: UP(260): Dchan(285) 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c1][1:1] Signalling link status changed to UP 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c2][1:2] Signalling link status changed to UP 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c3][1:3] Signalling link status changed to UP 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:02:29.972464 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:1179 Receved RESTART, but Restart Indicator IE not present 2011-06-06 22:02:29.972464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.972464 [INFO] mod_freetdm.c:2345 1:1 signalling changed to :UP 2011-06-06 22:02:29.972464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.972464 [INFO] mod_freetdm.c:2345 1:2 signalling changed to :UP 2011-06-06 22:02:29.972464 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:02:29.972464 [INFO] mod_freetdm.c:2345 1:3 signalling changed to :UP 2011-06-06 22:03:19.912462 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection DN(4): Disconnect initiated(263) 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_stack_rcv.c:681 [SNGISDN Q921] wp1: Protocol: Data Link connection UP(3): UA frame with F-bit = 1(258) 2011-06-06 22:03:19.932483 [INFO] ftmod_sangoma_isdn_stack_rcv.c:631 Received RESTART CFM (dChan:1 ces:0 type:0) 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:1179 Receved RESTART, but Restart Indicator IE not present 2011-06-06 22:03:19.932483 [INFO] ftmod_sangoma_isdn_stack_rcv.c:729 [SNGISDN Q931] s1: Interface: UP(260): Dchan(285) 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c1][1:1] Signalling link status changed to UP 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c2][1:2] Signalling link status changed to UP 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_cntrl.c:43 [s1c3][1:3] Signalling link status changed to UP 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c1][1:1] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c2][1:2] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:200 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] ftmod_sangoma_isdn_support.c:186 [s1c3][1:3] Setting availability rate to:10 2011-06-06 22:03:19.932483 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:03:19.932483 [INFO] mod_freetdm.c:2345 1:1 signalling changed to :UP 2011-06-06 22:03:19.932483 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:03:19.932483 [INFO] mod_freetdm.c:2345 1:2 signalling changed to :UP 2011-06-06 22:03:19.932483 [DEBUG] mod_freetdm.c:2268 got clear channel sig [SIGSTATUS_CHANGED] 2011-06-06 22:03:19.932483 [INFO] mod_freetdm.c:2345 1:3 signalling changed to :UP freeswitch@internal>   ftdm list +OK span: 1 (wp1) type: Sangoma (ISDN) physical_status: ok signaling_status: UP chan_count: 3 dialplan: XML context: public dial_regex: fail_dial_regex: hold_music: analog_options: none +OK span: 2 (wp2) type: Sangoma (ISDN) physical_status: alarmed signaling_status: DOWN chan_count: 3 dialplan: XML context: public dial_regex: fail_dial_regex: hold_music: analog_options: none +OK span: 3 (FXS) type: analog physical_status: ok signaling_status: UP chan_count: 2 dialplan: XML context: default dial_regex: fail_dial_regex: hold_music: analog_options: none

# wanrouter status

Devices currently active:        wanpipe1 wanpipe2 wanpipe3

Wanpipe Config:

Device name | Protocol Map | Adapter  | IRQ | Slot/IO | If's | CLK | Baud rate | wanpipe1    | N/A          | A500/B700| 20  | 0       | 1    | N/A | 0         | wanpipe2    | N/A          | A500/B700| 20  | 0       | 1    | N/A | 0         | wanpipe3    | N/A          | A200/A400/B600/B700/B800| 20  | 0       | 1    | N/A | 0         |

Wanrouter Status:

Device name | Protocol | Station | Status        | wanpipe1    | AFT ISDN | N/A     | Connected     | wanpipe2    | AFT ISDN | N/A     | Disconnected  | wanpipe3    | A-ANALOG | N/A     | Connected     |

# cat /etc/wanpipe/wanrouter.rc #!/bin/sh # .. comments snipped ... ROUTER_BOOT=YES WAN_CONF_DIR=/etc/wanpipe WAN_INTR_DIR=/etc/wanpipe/interfaces WAN_BIN_DIR=/usr/sbin WAN_LOG=/var/log/wanrouter WAN_LOCK=/var/lock/wanrouter WAN_LOCK_DIR=/var/lock WAN_IP_FORWARD=NO NEW_IF_TYPE=NO WAN_LIB_DIR=/etc/wanpipe/lib WAN_ADSL_LIST=/etc/wanpipe/wan_adsl.list WAN_ANNEXG_LOAD=NO WAN_SCTP_LOAD=NO WAN_LIP_LOAD=NO WAN_DYN_WANCONFIG=NO WAN_SCRIPTS_DIR=/etc/wanpipe/scripts WAN_FIRMWARE_DIR=/etc/wanpipe/firmware WAN_DEVICES_REV_STOP_ORDER=YES WAN_DEVICES="wanpipe1 wanpipe2 wanpipe3 "

# cat /etc/wanpipe/wanpipe1.conf #================================================ # WANPIPE1 Configuration File #================================================ # # Note: This file was generated automatically #       by /usr/local/sbin/setup-sangoma program. # #       If you want to edit this file, it is #       recommended that you use wancfg program #       to do so. #================================================ # Sangoma Technologies Inc. #================================================

[devices] wanpipe1 = WAN_AFT_ISDN_BRI, Comment

[interfaces] w1g1 = wanpipe1, , TDM_VOICE_API, Comment

[wanpipe1] CARD_TYPE     = AFT S514CPU     = A CommPort     = PRI AUTO_PCISLOT     = NO PCISLOT     = 0 PCIBUS      = 5 FE_MEDIA    = BRI FE_LINE        = 1 TDMV_LAW    = ALAW RM_BRI_CLOCK_MASTER    = NO MTU         = 1500 UDPPORT     = 9000 TTL        = 255 IGNORE_FRONT_END = NO TDMV_SPAN    = 1 TE_AIS_MAINTENANCE = NO            #NO: defualt  YES: Start port in AIS Blue Alarm and keep line down                                    #wanpipemon -i w1g1 -c Ttx_ais_off to disable AIS maintenance mode                                    #wanpipemon -i w1g1 -c Ttx_ais_on to enable AIS maintenance mode TDMV_HW_DTMF        = YES        # YES: receive dtmf events from hardware TDMV_HW_FAX_DETECT      = YES     # YES: receive fax 1100hz events from hardware HWEC_OPERATION_MODE     = OCT_NORMAL    # OCT_NORMAL: echo cancelation enabled with nlp (default)                                            # OCT_SPEECH: improves software tone detection by disabling NLP (echo possible)                                            # OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. HWEC_DTMF_REMOVAL       = NO    # NO: default  YES: remove dtmf out of incoming media (must have hwdtmf enabled) HWEC_NOISE_REDUCTION    = NO    # NO: default  YES: reduces noise on the line - could break fax HWEC_ACUSTIC_ECHO       = NO    # NO: default  YES: enables acustic echo cancelation HWEC_NLP_DISABLE        = NO    # NO: default  YES: guarantees software tone detection (possible echo) HWEC_TX_AUTO_GAIN       = 0     # 0: disable   -40-0: default tx audio level to be maintained (-20 default) HWEC_RX_AUTO_GAIN       = 0     # 0: disable   -40-0: default tx audio level to be maintained (-20 default) HWEC_TX_GAIN            = 0     # 0: disable   -24-24: db values to be applied to tx signal HWEC_RX_GAIN            = 0     # 0: disable   -24-24: db values to be applied to tx signal

[w1g1] ACTIVE_CH    = ALL TDMV_HWEC    = YES MTU         = 80

    ... and wanpipe2 was also automatically generated so just has '2' for FE_LINE and TDMV_SPAN instead of '1'.

# cat /usr/local/freeswitch/conf/freetdm.conf [span wanpipe wp1] trunk_type =>   bri group=1 b-channel =>   1:1-2 d-channel =>   1:3

[span wanpipe wp2] trunk_type =>   bri group=1 b-channel =>   2:1-2 d-channel =>   2:3

[span wanpipe FXS] name =>   freetdm trunk_type =>   fxs group =>   grp2 fxs-channel =>   3:1

trunk_type =>   fxs group =>   grp2 fxs-channel =>   3:2

# cat /usr/local/freeswitch/conf/autoload_configs/freetdm.conf.xml <configuration name="freetdm.conf" description="Freetdm Configuration"> <settings> <param name="debug" value="0"/> <!--<param name="hold-music" value="$${moh_uri}"/>--> <!--<param name="enable-analog-option" value="call-swap"/>--> <!--<param name="enable-analog-option" value="3-way"/>--> </settings>

<config_profiles>

<profile name="my_bri_te_1"> <param name="switchtype" value="euroisdn" /> <param name="interface" value="cpe"/> <param name="facility" value="no" /> </profile>

</config_profiles>

<sangoma_bri_spans>

<span name="wp1" cfgprofile="my_bri_te_1"> <param name="dialplan" value="XML"/> <param name="context" value="public"/> </span>

<span name="wp2" cfgprofile="my_bri_te_1"> <param name="dialplan" value="XML"/> <param name="context" value="public"/> </span>

</sangoma_bri_spans>

<analog_spans>

<span name="FXS"> <!--<param name="hold-music" value="$${moh_uri}"/>--> <param name="dialplan" value="XML"/> <param name="context" value="default"/> <!-- regex to stop dialing when it matches --> <!--<param name="dial-regex" value="5555"/>--> <!-- regex to stop dialing when it does not match --> <!--<param name="fail-dial-regex" value="^5"/>--> </span>

</analog_spans>

</configuration>

What other config files do I need to supply? I don't want to deluge the list any more in my first post!

2. We have 2 Single Number DDI numbers configured over the 4 channels. I want to set up outgoing calls so that they can appear to come from either of the two numbers, but at present the outgoing CLI appears to be overridden by the telco (BT) to only use one of the numbers.  Has anyone got this working in UK, and what is the format for the outbound_caller_id_number: last 6 digits or full 11 digits?  I note that the inbound called number is only the last 6 digits.

3. I have built FreeSWITCH from git and installed at /usr/local/... and then followed the steps on the Ubuntu page in the Wiki to set up the run control scripts, etc, and run FS non-root as freeswitch:daemon.  With FreeTDM, I have discovered that the /dev/wan* devices are owned by root:root, and so are inaccessible to FS running as non-root.  So for now I have added a line in /etc/init.d/freeswitch to 'chgrp freeswitch /dev/wan*'.  This is not the most elegant solution, because 'wanrouter restart' (which seems to be my best friend at the moment) resets the ownership to root:root.  I have tried grepping to see where the mknods are for these devices, but have been unsuccessful.  Is there a better place to 'permanently' change the device ownership?

Thanks for all the great support I have already got just from editing my Wiki User page; this is a friendly group!

John

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org