SN4120/2BIS4V PATTON with ISDN mod from ALBIS tech model SANTIS-ab

[georgi071]

Hello

I have installed a 3CX v.15.5 system using the Patton as ISDN gateway. The phone company (OTE) here ins Greece changed my netmod from ELCON to a new one from ALBIS model santis-ab and now the Patton from either digital port of the new netmod does not handle the incoming traffic / calls.

All outgoing is working thought.

what could be wrong? when we connect the old netmod ELCON back the system works ok.

very strange...

please advise ASAP I cant keep the old net mod because the analog ports are damaged and the phone company took it

 

[georgi071]

It seems whenever one of the channels in my ISDN gateway is occupied the system is working ok, handles the call in the other channel.

could anyone advise, please?

 

[eddv123]

Firstly why are you on 3CX v15.5 and not 16, to my knowledge the templates for Patton BRI should work fine still on the latest version. I would also upgrade your Patton firmware also: https://www.patton.com/support/upgrades/

With that being said, login via CLI of the Patton and run the command show port bri 0 0 it may also support show port bri 0 0 detail 5 also (this would be the better command if it does).

Note: 0 0 would be the first BRI port, if you want the second it would be 0 1.

Do this with both the working (ELCON plugged in) and non working (if you can) and compare the two. The next step would be debug logging but we can look at that next.

 

[georgi071]

thanks for the reply.

I tried to upgrade to V.16 following the explicit guide but it was a disaster. The system when boot up had no extensions no trunks no rules nothing from the backup I made before the upgrade. I am very afraid to try again, I thought I lost everything. I am pretty sure i followed the guide.

about my issue: i only have the new netmod santis-ab so i run the commands for port 0 0 and then for port 0 1. the results are attached. thank you again for helping me.

I did also upgrade to the latest firware but this did not solve my issue. under 3CX the patton shows everything ok.

 

[eddv123]

Link up = 1 should be a good indication that there is a connection (I am running a Trinity BRI model 4131 here and get something similar):

Administrative state: Enabled
Link state: Up
Power feed: false
Line termination: true
L1 mode: TE
L1 state: F7

To confirm, they have only changed over the wall-box the line itself should from my estimations be presenting the exact same service/DDI's etc as before.

We can confirm this anyway by testing an inbound call with the following commands.

enable
debug call‐router
debug call‐control
debug ccisdn signaling
debug bri full-detail

Replicate the error for inbound call (then cut and paste onto a notepad file for analysis).

no debug all to stop the trace.

FYI I am only concentrating on the ISDN side (and not SIP) for this first step. Can you also confirm that outbound rules are working across the Patton - and that you dont have a back up SIP trunk or something like that which is taking the calls outbound (and thus not going via the Patton).

There is also a helpful 3CX guide that covers ISDN debugging as well: https://www.3cx.com/docs/patton-isdn-debugging/

 

[georgi071]

Link up = 1 should be a good indication that there is a connection (I am running a Trinity BRI model 4131 here and get something similar):

Administrative state: Enabled
Link state: Up
Power feed: false
Line termination: true
L1 mode: TE
L1 state: F7

To confirm, they have only changed over the wall-box the line itself should from my estimations be presenting the exact same service/DDI's etc as before.

We can confirm this anyway by testing an inbound call with the following commands.

enable
debug call‐router
debug call‐control
debug ccisdn signaling
debug bri full-detail

Replicate the error for inbound call (then cut and paste onto a notepad file for analysis).

no debug all to stop the trace.

FYI I am only concentrating on the ISDN side (and not SIP) for this first step. Can you also confirm that outbound rules are working across the Patton - and that you dont have a back up SIP trunk or something like that which is taking the calls outbound (and thus not going via the Patton).

There is also a helpful 3CX guide that covers ISDN debugging as well: https://www.3cx.com/docs/patton-isdn-debugging/

Hello and thanks once again for your help.

I confirm that the outbound works correctly via the PATTON. No other SIP is handling the specific calls.

Attached is the trace debug you asked me. First, I made an INBOUND call and then an OUTBOUND call using the ISDN gateway - PATTON only.

George

 

[eddv123]

There are a couple of things that concern me here, messages which include:

1) You are getting an ISDN cause code 98:
Message not compatible wth call state or message type non-existent or not implemented
https://networking.ringofsaturn.com/Routers/isdncausecodes.php

But I cannot see anything prior to this (as it is at the top of the trace and has no prior log entries).

2) [EP HG_TO_ISDN-00d290b0/incoming] Set call-leg property: State -> ADDRESS-INCOMPLETE

This I believe is in regards to your inbound call, I have seen this before when an incomplete e164 calling party number is being passed to the BRI line. This was solved with a call to the provider.

What I would say however is more clarity is required here, please PM me the DDI number of the inbound call and run the below commands again making only a single inbound call. This way I can confirm the above as well as the DDI number being received and what you are expecting to see.


enable
debug call‐router
debug call‐control
debug ccisdn signaling
debug bri full-detail
debug isdn error
debug ccisdn error
debug isdn event bri 0 0 (if this is your port number in use)

Just one inbound call from start to finish please.

Commands as per: https://www.patton.com/support/kb_art.asp?art=446&p=128 I have not included anything related to media or SIP traffic yet as I think this issue is still on the ISDN side.

 

[georgi071]

There are a couple of things that concern me here, messages which include:

1) You are getting an ISDN cause code 98:
Message not compatible wth call state or message type non-existent or not implemented
https://networking.ringofsaturn.com/Routers/isdncausecodes.php

But I cannot see anything prior to this (as it is at the top of the trace and has no prior log entries).

2) [EP HG_TO_ISDN-00d290b0/incoming] Set call-leg property: State -> ADDRESS-INCOMPLETE

This I believe is in regards to your inbound call, I have seen this before when an incomplete e164 calling party number is being passed to the BRI line. This was solved with a call to the provider.

What I would say however is more clarity is required here, please PM me the DDI number of the inbound call and run the below commands again making only a single inbound call. This way I can confirm the above as well as the DDI number being received and what you are expecting to see.


enable
debug call‐router
debug call‐control
debug ccisdn signaling
debug bri full-detail
debug isdn error
debug ccisdn error
debug isdn event bri 0 0 (if this is your port number in use)

Just one inbound call from start to finish please.

Commands as per: https://www.patton.com/support/kb_art.asp?art=446&p=128 I have not included anything related to media or SIP traffic yet as I think this issue is still on the ISDN side.

 

[georgi071]

here is the new debug, thanks.

 

[eddv123]

Looking at your debug logs I would try the following as per: https://www.patton.com/support/kb_art.asp?art=406&p=140

Configure the following on the BRI port(s) in question:
address-complete-indication accept set

enable
configure
context cs switch
interface isdn IF_BRI_00

(on the ISDN interface not the port - the above is an example for port BRI 00)

It looks like the remote end does not like the gateways setup message, this command will prevent the device from sending this. Please let me know how you get on.

 

[georgi071]

i tried a couple of times the above

Looking at your debug logs I would try the following as per: https://www.patton.com/support/kb_art.asp?art=406&p=140

Configure the following on the BRI port(s) in question:
address-complete-indication accept set

enable
configure
context cs switch
interface isdn IF_BRI_00

(on the ISDN interface not the port - the above is an example for port BRI 00)

It looks like the remote end does not like the gateways setup message, this command will prevent the device from sending this. Please let me know how you get on.

I tried a couple of times to enter the commands but nothing changed.
The first line "address-complete-indication accept set" returns keyword mismatch

see below:

==================

login: administrator
password:
192.168.0.50>address-complete-indication accept set
% ^ Keyword mismatch
192.168.0.50>enable
192.168.0.50#configure
192.168.0.50(cfg)#context cs switch
192.168.0.50(ctx-cs)[switch]#interface isdn IF_BRI_00
192.168.0.50(if-isdn)[IF_BRI_~]#
=========================

 

[eddv123]

I have just gone through the process on my BRI unit here (which is Trinity based not Smartware like yours) but the concepts are pretty similar, commands attached - and below:

0FAA00#enable
0FAA00#configure
0FAA00(cfg)#context cs
0FAA00(ctx-cs)[SWITCH]#interface isdn IF_BRI_00
0FAA00(if-isdn)[SWITCH.IF_BRI_~]#address-complete-indication accept set

Again there will be slight differences for Smartware but I don't have a Smartware box here to do this on.

 

[georgi071]

I have just gone through the process on my BRI unit here (which is Trinity based not Smartware like yours) but the concepts are pretty similar, commands attached - and below:

0FAA00#enable
0FAA00#configure
0FAA00(cfg)#context cs
0FAA00(ctx-cs)[SWITCH]#interface isdn IF_BRI_00
0FAA00(if-isdn)[SWITCH.IF_BRI_~]#address-complete-indication accept set

Again there will be slight differences for Smartware but I don't have a Smartware box here to do this on.

i entered these commands like you sent me:

enable
configure
context cs
interface isdn IF_BRI_00
address-complete-indication accept set

no errors from what i see. then i try an inbound call but Patton does not take over. the outbound calls are working ok. is there anything else we can do? how about the menu from patton web interface? any options to explore there?

 

[eddv123]

To confirm these settings please run and send over the results from:

show running-config

If the command is present on the port then I think it is probably time to raise this with your service provider and ask them what they have changed and why they are rejecing the Pattons now very basic setupack message ? Could be a b channel allocation or pp vs pmp issue.

With the command ""address-complete-indication accept set" then the setupack is not sent anymore.

 

[georgi071]

here it is

 

[eddv123]

The command looks fine to me, did you raise the issue to the provider ? I have sent you a PM also.

 

[georgi071]

I did and they say they will come and replace with the one i had. still nothing more. I really dont expect them to understand the patton issue very well. i doubt they are trained.

also i dont know why Patton support takes so long to provide a solution.
thank you for helping me.

 

[eddv123]

Did you raise this with Patton ? they are normally very quick to respond. In this case I do believe it to be a provider issue (something has changed between these boxed).

As said, the Patton now is only sending a very basic SETUP ACK message which should be accepted so the question to the provider is why are they rejecting this.

 

[eddv123]

SOLVED

The "address-complete-indication accept set" command needs to be set on interface IF_ISDN_00 not IF_BRI_00 (like you would with a Trinity based 3CX template).

Putting the BRI command would simply create an interface that is does not exist. Inbound calls confirmed working now by @georgi071

Note: with Patton's these interface names are not set as standard (you can call them what you like) however these are the names set by the 3CX template on auto-configuration.

The issue is because the remote side does not support overlap sending of digits, that is why it does not like the basic SETUP_ACK sent by the Patton.