<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 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 class="h5"><br>
On May 26, 2015, at 2:44 PM, Barry Howser <<a href="mailto:bhowser5050@gmail.com">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">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>