[cisco-voip] MGCP Odd issue

[Barry Howser]

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/20150526/0c0b1a70/attachment.html>