[cisco-voip] MGCP Odd issue
Barry Howser
bhowser5050 at gmail.com
Wed May 27 17:53:19 EDT 2015
Hi Wes/Dave,
There wasn't any significant "change" per se; however, this 5 node (4 sub 1
pub) cluster has been onboarding significant amounts of endpoints
frequently, for the past 6 months through a variety of methods; bat, hand
builds ... etc. It's an 8 month old build with 6 months worth of
migrations. In that time, the cluster has never been rebooted. I'm not
above chalking this up to memory corruption or the like and prescribing a
cluster reboot. Especially since nothing in UCM seems to have changed and
this impacted only MGCP gateways and all MGCP gateways at the same time.
I will check the Overlap Receiving flag, to see what state it is in.
Thanks again!
On Wed, May 27, 2015 at 3:38 PM, Wes Sisk (wsisk) <wsisk at cisco.com> wrote:
> [nod to Dave for teaching me much of what I know about ISDN]
>
> and adding to what he said.. UCM sends “setup ack” when the inbound call
> could match multiple destinations. You say this “started suddenly across
> all gateways”. Was there a change on UCM to CSS or adding new patterns that
> would generate multiple potential matches for inbound calls?
>
> Regards,
> Wes
>
> On May 27, 2015, at 8:25 AM, Dave Goodwin <Dave.Goodwin at december.net>
> wrote:
>
> 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/24286bb8/attachment.html>
More information about the cisco-voip
mailing list