PRI issue 1

[jak67]

PRI on IP 500v2 running 8.0.44 will not make outgoing calls display says line busy. monitor trace shows the line connecting then getting error of CMCauseMissingMandatoryIE.
here is the trace
CMSetup
Line: type=Q931Line 5 Call: lid=0 id=1015 in=0
Called[] Type=Unknown (0) Reason=CMDRdirect Calling[7654638] Type=Default Plan=Default
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ULaw
BChan: slot=0 chan=23
Timed: 09/01/13 08:17
Locale: enu
966661mS CD: CALL: 0.1013.0 BState=Idle Cut=0 Music=0.0 Aend="Kevin(1012)" (20.8) Bend="Line 5" [Line 5] (0.0) CalledNum=9 () CallingNum=1012 (Kevin) Internal=0 Time=920 AState=Dialling
966662mS CMMap: a=20.8 b=0.0 D0
966663mS ISDNL3Evt: v=5 stacknum=5 State, new=Initiated, old=NullState id=1015
966677mS ISDNL3Evt: v=5 stacknum=5 State, new=NullState, old=Initiated id=1015
966678mS CMLineRx: v=5
CMReleaseComp
Line: type=Q931Line 5 Call: lid=0 id=1015 in=0
BChan: slot=0 chan=23
Cause=96, Mandatory information element missing
966678mS CMCallEvt: 0.1014.0 4 TargetingEP: RequestEnd 0.1015.0 4 Q931 Trunk:5 CHAN=23
966678mS CMTARGET: 0.1013.0 4 Kevin.0: CancelTimer CMTCNoAnswerTimeout
966679mS CMCallEvt: 0.1014.0 -1 BaseEP: DELETE CMEndpoint f517f064 TOTAL NOW=4 CALL_LIST=2
966679mS CMCallEvt: 0.1015.0 4 Q931 Trunk:5 CHAN=23: StateChange: END=B CMCSOffering->CMCSCompleted
966680mS CMLOGGING: CALL:2013/01/0908:17,00:00:00,000,1012,O,,9,Kevin,,,0,,""n/a,0
966681mS CD: CALL: 0.1013.0 BState=Disconnecting Cut=0 Music=0.0 Aend="Kevin(1012)" (20.8) Bend="Line 5" [Line 5] (3.24) CalledNum= () CallingNum=1012 (Kevin) Internal=0 Time=940 AState=Dialling
966681mS CD: CALL: 0.1013.0 Deleted
966682mS CMExtnEvt: Kevin: CALL LOST (CMCauseMissingMandatoryIE)
966682mS CMExtnEvt: Kevin: Extn(1012) Calling Party Number(1012) Type(CMNTypeInternal)
966682mS CMCallEvt: 0.1013.0 -1 Kevin.0: StateChange: END=X CMCSDialling->CMCSCompletedTone
966682mS CMExtnEvt: v=8 State, new=CMESCompleted old=Dialling,0,0,Kevin
966683mS CMCallEvt: 0.1015.0 -1 Q931 Trunk:5 CHAN=23: StateChange: END=X CMCSCompleted->CMCSDelete
966683mS CMCallEvt: END CALL:4 (f51625f0)
966684mS CMTARGET: ISDN BChannel 23: in-service check = 1
966684mS CMTARGET: ISDN BChannel 23: in-service check = 1
966684mS CMCallEvt: 0.1015.0 -1 BaseEP: DELETE CMEndpoint f5160184 TOTAL NOW=3 CALL_LIST=1
966685mS CMMap: a=21.8 b=0.0 DTMF::AllocateRAS allocated CMRTTonegen resource busy 7, total 8
966685mS CMMap: a=21.8 b=1.255 T
966686mS CMMap: a=21.8 b=20.8 M2
970627mS RES: Wed 9/1/2013 08:17:51 FreeMem=61155972(2) CMMsg=3 (4) Buff=5200 893 1000 7372 5 Links=4864
970627mS RES2: IP 500 V2 8.0(44) Tasks=48 RTEngine=0 CMRTEngine=0 ExRTEngine=0 Timer=75 Poll=0 Ready=0 CMReady=0 CMQueue=0 VPNNQueue=0 Monitor=1 SSA=0 TCP=20 TAPI=0 ASC=1 SYS=MNTD OPT=UMNT SDSPD=2034
972423mS H323Evt: Shared tcp socket for line 18 disconnected
973864mS CMExtnRx: v=1012, p1=0

 

[CarGoSki]

So..... What has changed on site? New circuit, added channels, new provider, etc

966678mS CMLineRx: v=5
CMReleaseComp
Line: type=Q931Line 5 Call: lid=0 id=1015 in=0
BChan: slot=0 chan=23
Cause=96, Mandatory information element missing

 

[1043]

Is there anything in the no user source number?

 

[jak67]

This is a new PRI. there wasn't any thing in the no user source number. I tried adding NI2_CALLED_PARTY_TYPE=UNKNOWN to the no user but still the same error.

 

[tlpeter]

Cause No. 96 - mandatory information element is missing.
This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed.
What it means:
This is rarely seen in North America but usually means that the number that is being dialed is in the wrong format, (similar to cause 88). Some part of the format being used is not understood by either the remote side equipment or the switching equipment between the source and destination of the call.

Cause No. 88 - incompatible destination.
This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility. high layer compatibility or other compatibility attributes (e.g., data rate) which cannot be accommodated.
What it means: 
1.	This usually means that the Number To Dial in the Connection Profile is in the wrong format. You may need to dial a 10 or 11 digit number, or dial a 9 in front of the number if it is a Centrex line. 
2.	This problem may also give a Cause 111. 
3.	Dialing at the wrong line speed can also give this Cause.

BAZINGA!

I'm not insane, my mother had me tested!

 

[1043]

You can receive but not make?
What is you ARS setup?
What is the provider seeing on their end?

 

[tlpeter]

He is sending a 9 only so i would try using a ; in the shortcode.
What happens is that somebody dials a 9 and is waiting too long or it is send straight away.


BAZINGA!

I'm not insane, my mother had me tested!

 

[1043]

tech tip 212 changes from the system from sending "national number" to "unknown number plan".

 

[CarGoSki]

Turn on all SDN Layer 2 and 3
Turn on Call\ short code messages and ARS

Try dialing again and post those traces here.
Post everything from just before you dial 9.

Also how is you PRI configured?

 

[Telecomboy]

Make sure you are sending the right number also. More PRI's in the states require a valid number being sent or they will deny the call. Try sending the main BTN. If you are trying to send DID's, the provider may not be programmed for that and therefore deny the call.

 

[jak67]

I added a ; to the end of the tel numbers in the ARS table and now it works. Thanks for the tip.tlpeter you get a star for that one.

 

[CarGoSki]

Right cm logging > 966680mS CMLOGGING: CALL:2013/01/0908:17,00:00:00,000,1012,O,,9,Kevin,,,0,,""n/a,0

Next time turn on the isdn traces when trying to solve PRI issues. Makes it easier for lazy people like me to troubleshoot.