<div dir="ltr">Hi Dave. I have placed the full q931 from a failed call inline below. The mandatory missing IE is at the bottom.<br><br>Syslog logging: enabled (0 messages dropped, 63 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)<br><br>No Active Message Discriminator.<br><br><br><br>No Inactive Message Discriminator.<br><br><br>    Console logging: disabled<br>    Monitor logging: level debugging, 0 messages logged, xml disabled,<br>                     filtering disabled<br>    Buffer logging:  level debugging, 140 messages logged, xml disabled,<br>                    filtering disabled<br>    Exception Logging: size (4096 bytes)<br>    Count and timestamp logging messages: disabled<br>    Persistent logging: disabled<br><br>No active filter modules.<br><br>    Trap logging: level informational, 1381 message lines logged<br>        Logging to XXX.XXX.XXX.XXX  (udp port 514, audit disabled,<br>              link up),<br>              1380 message lines logged, <br>              0 message lines rate-limited, <br>              0 message lines dropped-by-MD, <br>              xml disabled, sequence number disabled<br>              filtering disabled<br>        Logging to XXX.XXX.XXX.XXX  (udp port 514, audit disabled,<br>              link up),<br>              1381 message lines logged, <br>              0 message lines rate-limited, <br>              0 message lines dropped-by-MD, <br>              xml disabled, sequence number disabled<br>              filtering disabled<br>        Logging Source-Interface:       VRF Name:<br>        Loopback0                       <br><br>Log Buffer (10000000 bytes):<br><br>May 27 03:21:05.580: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x005D <br>    Bearer Capability i = 0x8090A2 <br>        Standard = CCITT <br>        Transfer Capability = Speech  <br>                Transfer Mode = Circuit <br>        Transfer Rate = 64 kbit/s <br>    Channel ID i = 0xA18381 <br>        Preferred, Channel 1 <br>    Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E <br>        Protocol Profile =  Networking Extensions <br>        0xA1110201010201008009485546462C5259414E <br>        Component = Invoke component <br>            Invoke Id = 1 <br>            Operation = CallingName <br>                Name Presentation Allowed Extended<br>                Name = HOWSER,BARRY<br>    Calling Party Number i = 0x2180, '<DN-INTENTIONALLY-REMOVED>' <br>        Plan:ISDN, Type:National <br>    Called Party Number i = 0xA1, '<DN-INTENTIONALLY-REMOVED>' <br>        Plan:ISDN, Type:National<br>May 27 03:21:05.632: ISDN Se0/1/0:23 Q931: TX -> SETUP_ACK pd = 8  callref = 0x805D <br>    Channel ID i = 0xA98381 <br>        Exclusive, Channel 1<br>May 27 03:21:05.656: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8  callref = 0x005D <br>    Cause i = 0x82E50D - Message not compatible with call state <br>    Call State i = 0x06<br>May 27 03:21:09.560: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x005D <br>    Bearer Capability i = 0x8090A2 <br>        Standard = CCITT <br>        Transfer Capability = Speech  <br>        Transfer Mode = Circuit <br>        Transfer Rate = 64 kbit/s <br>    Channel ID i = 0xA18381 <br>        Preferred, Channel 1 <br>    Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E <br>        Protocol Profile =  Networking Extensions <br>        0xA1110201010201008009485546462C5259414E <br>        Component = Invoke component <br>            Invoke Id = 1 <br>            Operation = CallingName <br>                Name Presentation Allowed Extended<br>                Name = HOWSER,BARRY<br>    Calling Party Number i = 0x2180, '<DN-INTENTIONALLY-REMOVED>' <br>        Plan:ISDN, Type:National <br>    Called Party Number i = 0xA1, '<DN-INTENTIONALLY-REMOVED>' <br>        Plan:ISDN, Type:National<br>May 27 03:21:11.700: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x805D<br>May 27 03:21:11.700: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x805D <br>        Progress Ind i = 0x8088 - In-band info or appropriate now available <br>May 27 03:21:11.716: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x005D <br>    Cause i = 0x82E018 - Mandatory information element missing<br>May 27 03:21:11.716: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x005D <br>    Cause i = 0x82D1 - Invalid call reference value<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 7:12 PM, Dave Goodwin <span dir="ltr"><<a href="mailto:dave.goodwin@december.net" target="_blank">dave.goodwin@december.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Barry, if you have the q931 debug from when the error occurred, and if you are able to share it, that may help shed light on the error. The mandatory IE missing issue is an ISDN protocol error where the CUCM and telco switch are in disagreement about something. It is sometimes possible to determine which IE is missing from the debug of the entire failed call.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">TAC may be able to provide help as well, if you can provide that debug for them.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 3:53 PM, Barry Howser <span dir="ltr"><<a href="mailto:bhowser5050@gmail.com" target="_blank">bhowser5050@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Wes. The "mandatory missing IE" message was at the end of a q931 debug right before the call goes busy. I may have over simplified my original explanation. I have several gateways that this exact same scenario happened to. All experienced the same condition, with the same configurations.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 3:33 PM, Wes Sisk (wsisk) <span dir="ltr"><<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">a couple things here -<br>
<br>
you say MGCP.. if using MGCP and d-channel bachaul then it is CCM’s ISDN stack in use. Where did you see the error “mandatory IE missing?” if it was with debugs on the gateway then it may have been generated by the gateway’s ISDN stack.<br>
<br>
each isdn ‘switch type’ has subtle nuances in implementation. the right answer really depends on what physical equipment the telco is using as well as how they have the d-ch provisioned on their end.<br>
<br>
it could be the telco changed config. or they might have upgraded the switch. or you may have started using a different call flow that added/removed IE’s.<br>
<br>
also possible that a lingering reset/restart was not applied on the UCM side (CSCtw80866    Reset Required flag in CCMAdmin for any device/trunk that has been )<br>
<br>
-w<br>
<div><div><br>
On May 26, 2015, at 2:44 PM, Barry Howser <<a href="mailto:bhowser5050@gmail.com" target="_blank">bhowser5050@gmail.com</a>> wrote:<br>
<br>
So I've had an MGCP/T1 gateway up and running with CCM, happy as a clam for several weeks.<br>
<br>
Then all of the sudden today it stopped passing inbound communication. Egress works just fine, but ingress rings once then a fast busy.<br>
<br>
In the ISDN logs I get "mandatory information element missing".<br>
<br>
I am using; EF, BZ8S, Primary-ni (which is telco settings). Again everything WAS fine. After some research I found that error to mean that the CCM side kicked the call back to the gateway because it didn't get everything it needed in the header.<br>
<br>
A proposed suggestion was to use a different switch-type. So in the CCM/Gateway/PRI config page, I changed the switch type to PRI-4ESS -> Saved/Applied/Reset (then restarted mgcp on the gateway) and presto, ingress is now working.<br>
<br>
If I reverse the process and go back to the Primary-ni in the CCM/Gateway/PRI config, I get the same problem with ingress again.<br>
<br>
Can anyone explain this to me? Does it sound like my telco changed something? Seems like something with MGCP is goofed right? Is this something that a telco would just arbitrarily change?<br>
<br>
Thanks<br>
</div></div>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>