<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">The "Mandatory information element missing" error states the missing IE is 0x18. That is referring to the fact that the CALL_PROC you sent telco contains no Channel ID IE, which is normally required. Looking further back in the call flow, it seems that after the initial SETUP message was received, you sent telco a SETUP_ACK - which they also complained about receiving (Message not compatible with call state).</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">If this PRI is truly under the control of UCM registered as MGCP, and not under local IOS control, it seems like UCM has gone into overlap receiving mode, where it expects to receive potentially additional digits in INFORMATION messages. I don't think you're going to find any public PRI service providers (at least not in the US) who will use overlap sending; they will send you all the digits in the initial SETUP. Can you look in your Service Parameters for CallManager and check if the Overlap Receiving for PRI Flag is set to True? It is normally False by default (from memory). Keep in mind the setting is cluster-wide, so if you decide to change it, make sure you don't have any UCM-managed PRI interfaces where you actually do need to use overlap receiving.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">BTW, from what I am able to find, the 5ESS protocol (and presumably 4ESS) has no such message SETUP_ACK that would be used for overlap receiving mode. That is probably why changing the protocol makes the error go away, since UCM is probably not going to send that message telco doesn't like, since doing so would violate the configured protocol.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">-Dave</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 11:26 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 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="HOEnZb"><div class="h5"><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><div><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>
</div></div></blockquote></div><br></div>