Showing results for 
Search instead for 
Did you mean: 

No ISDN L2 response from far end: "ISDN Se2/0:15 Q921: User TX -> SABMEp sapi=0 tei=0"


Hi all,

We are trying to get an older Spirent Abacus 5000 call generator to connect to one of our 3845 router gateways.

Initially we had tried to use MGCP with the backhaul to CallManager, but we were only able to get the port to be active at Layer1.  A second port (connecting to our Telco) came up fine on Layer1 and Layer2 (MULTIPLE_FRAME_ESTABLISHED).

The link to the Call Generator will only achieve Layer1.  Layer2 seems to cycle between TEI_ASSIGNED and AWAITING_ESTABLISHMENT.

We have since swapped both connections into another 3845 that does NOT run MGCP or CallManager backhaul. This other 3845 uses SIP and H323 with some fairly basic commands on the router.  Once again we were able to get the Telco connection to come up at L1 and L2, but the Call Generator only ever acheives L1.

I ran some Q921 debug and i see this (seemingly no response from the Call Generator?):

Jun 25 15:50:03.072: ISDN Se2/0:15 Q921: User TX -> SABMEp sapi=0 tei=0

*Jun 25 15:50:04.072: ISDN Se2/0:15 Q921: User TX -> SABMEp sapi=0 tei=0

*Jun 25 15:50:05.072: ISDN Se2/0:15 Q921: User TX -> SABMEp sapi=0 tei=0

*Jun 25 15:50:06.072: ISDN Se2/0:15 Q921: User TX -> SABMEp sapi=0 tei=0

I've made changes to the serial interface to try and get L2 working, but cannot seem to get a working connection:

interface Serial2/0:15

 no ip address

 encapsulation hdlc

 isdn switch-type primary-net5

 isdn overlap-receiving

 isdn incoming-voice voice

 no cdp enable


We have swapped the isdn switch type command for a multitude of others with no joy.  The Spirent seems to be set to use ISDN and ETSI voice (although i can change this to QSIG voice which seems to make no difference even if i change the switchtype on the router serial interface to primary-qsig)



Any ideas?  Are there additional debug commands i could run to see if the far-end is sending anything at all/trying to talk over DMS-100 not primary-net5 etc?


Thoughts very much appreciated   :O)

3 Replies 3

George Thomas

Is the Abacus going to be the network side or user side? Try adding this command under your serial: 

isdn protocol-emulate network.

Please rate useful posts.

Thanks George.  Show controllers E1 did show some errors (slip errors). Once we set the clocking to be internal (i think) the errors stopped.


E1 2/0 is up.
  Applique type is Channelized E1 - balanced
  Description: Call Generator
  No alarms detected.
  alarm-trigger is not set
  Version info Firmware: 20100222, FPGA: 255, spm_count = 0
  Framing is NO-CRC4, Line Code is HDB3, Clock Source is Internal.
  Current port master clock:recovered from controller 2/1
  Data in current interval (313 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     12 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     12 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs



When i check the controler e1 status now, i see zero errors.  Despite this, the MFE L2 establishment issue continues:


Jun 25 15:50:04.072: ISDN Se2/0:15 Q921: User TX -> SABMEp sapi=0 tei=0


If i check an active E1 (we have one working to our telco on another port) i see constant Tx and Rx messages between the two.  I'm not seeing this from the Spirent Device, which leads me to think there is something fundamentally wrong with the isdn switchtype primary-net5/primary-qsig etc...  We've switched the isdn type on the 3845 and tried all available. A change triggers an 'Awaiting Establishment' on the serial interface...but that then goes back to TEI-Assigned.


L2 is clearly the issue, and as best i can tell the issue stems from the Spirent device.  We've changed settings on that too but didnt see MFE being established.  I may try to change setings one at a time on the Spirent and check if the 'Awaiting-Establishement' appears on the serial interface of the 3845. If it doesnt, that would suggest that the Spirent isnt talking to the 3845 over L2 and that we need to focus our efforts at that end.



EDIT - i should add that we also tried the isdn protocol-emulate network / user commands on the 3845 serial interface, and that didnt seem to get the L2 working either.  We may need to repeat the test and change the setting on the Spirent after we make each change on the 3845 (ie spirent as user if we are network) just incase the spirent GUI is flaky in how it saves the config.



Ya L2 is usually a switch-type or User/network negotiation. I would try the various switch type with the Spirent as the user and see how that works out. 

Please rate useful posts.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: