[cisco-voip] MGCP Odd issue

Wed May 27 15:38:15 EDT 2015

[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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto: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/ee0ddd54/attachment.html>