[cisco-voip] MGCP Odd issue
Dave Goodwin
dave.goodwin at december.net
Wed May 27 08:25:22 EDT 2015
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).
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.
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.
-Dave
On Tue, May 26, 2015 at 11:26 PM, Barry Howser <bhowser5050 at gmail.com>
wrote:
> Hi Dave. I have placed the full q931 from a failed call inline below. The
> mandatory missing IE is at the bottom.
>
> Syslog logging: enabled (0 messages dropped, 63 messages rate-limited, 0
> flushes, 0 overruns, xml disabled, filtering disabled)
>
> No Active Message Discriminator.
>
>
>
> No Inactive Message Discriminator.
>
>
> Console logging: disabled
> Monitor logging: level debugging, 0 messages logged, xml disabled,
> filtering disabled
> Buffer logging: level debugging, 140 messages logged, xml disabled,
> filtering disabled
> Exception Logging: size (4096 bytes)
> Count and timestamp logging messages: disabled
> Persistent logging: disabled
>
> No active filter modules.
>
> Trap logging: level informational, 1381 message lines logged
> Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled,
> link up),
> 1380 message lines logged,
> 0 message lines rate-limited,
> 0 message lines dropped-by-MD,
> xml disabled, sequence number disabled
> filtering disabled
> Logging to XXX.XXX.XXX.XXX (udp port 514, audit disabled,
> link up),
> 1381 message lines logged,
> 0 message lines rate-limited,
> 0 message lines dropped-by-MD,
> xml disabled, sequence number disabled
> filtering disabled
> Logging Source-Interface: VRF Name:
> Loopback0
>
> Log Buffer (10000000 bytes):
>
> May 27 03:21:05.580: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8 callref =
> 0x005D
> Bearer Capability i = 0x8090A2
> Standard = CCITT
> Transfer Capability = Speech
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0xA18381
> Preferred, Channel 1
> Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E
> Protocol Profile = Networking Extensions
> 0xA1110201010201008009485546462C5259414E
> Component = Invoke component
> Invoke Id = 1
> Operation = CallingName
> Name Presentation Allowed Extended
> Name = HOWSER,BARRY
> Calling Party Number i = 0x2180, '<DN-INTENTIONALLY-REMOVED>'
> Plan:ISDN, Type:National
> Called Party Number i = 0xA1, '<DN-INTENTIONALLY-REMOVED>'
> Plan:ISDN, Type:National
> May 27 03:21:05.632: ISDN Se0/1/0:23 Q931: TX -> SETUP_ACK pd = 8 callref
> = 0x805D
> Channel ID i = 0xA98381
> Exclusive, Channel 1
> May 27 03:21:05.656: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref =
> 0x005D
> Cause i = 0x82E50D - Message not compatible with call state
> Call State i = 0x06
> May 27 03:21:09.560: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8 callref =
> 0x005D
> Bearer Capability i = 0x8090A2
> Standard = CCITT
> Transfer Capability = Speech
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0xA18381
> Preferred, Channel 1
> Facility i = 0x9F8B0100A1110201010201008009485546462C5259414E
> Protocol Profile = Networking Extensions
> 0xA1110201010201008009485546462C5259414E
> Component = Invoke component
> Invoke Id = 1
> Operation = CallingName
> Name Presentation Allowed Extended
> Name = HOWSER,BARRY
> Calling Party Number i = 0x2180, '<DN-INTENTIONALLY-REMOVED>'
> Plan:ISDN, Type:National
> Called Party Number i = 0xA1, '<DN-INTENTIONALLY-REMOVED>'
> Plan:ISDN, Type:National
> May 27 03:21:11.700: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8 callref
> = 0x805D
> May 27 03:21:11.700: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8 callref
> = 0x805D
> Progress Ind i = 0x8088 - In-band info or appropriate now
> available
> May 27 03:21:11.716: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8
> callref = 0x005D
> Cause i = 0x82E018 - Mandatory information element missing
> May 27 03:21:11.716: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref =
> 0x005D
> Cause i = 0x82D1 - Invalid call reference value
>
> On Tue, May 26, 2015 at 7:12 PM, Dave Goodwin <dave.goodwin at december.net>
> wrote:
>
>> 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.
>>
>> TAC may be able to provide help as well, if you can provide that debug
>> for them.
>>
>> On Tue, May 26, 2015 at 3:53 PM, Barry Howser <bhowser5050 at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>> On Tue, May 26, 2015 at 3:33 PM, Wes Sisk (wsisk) <wsisk at cisco.com>
>>> wrote:
>>>
>>>> a couple things here -
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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 )
>>>>
>>>> -w
>>>>
>>>> On May 26, 2015, at 2:44 PM, Barry Howser <bhowser5050 at gmail.com>
>>>> wrote:
>>>>
>>>> So I've had an MGCP/T1 gateway up and running with CCM, happy as a clam
>>>> for several weeks.
>>>>
>>>> Then all of the sudden today it stopped passing inbound communication.
>>>> Egress works just fine, but ingress rings once then a fast busy.
>>>>
>>>> In the ISDN logs I get "mandatory information element missing".
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>> Thanks
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150527/c256a966/attachment.html>
More information about the cisco-voip
mailing list