(CUCM SIP->H323)

[Jon Clark1]

Cause i = 0x82E16E - Message type not implemented
Call State i = 0x0A

065015: Oct 17 15:14:04.893: ISDN Se0/1/0:23 Q931: TX -> NOTIFY pd = 8 callref = 0x0146
Notification Ind i = 0x8300
Display i = 'MY FIRST AND LAST NAME'
Calling Party Number i = 0x0081, '+19999999999'
Plan:Unknown, Type:Unknown

ask for any info and I will provide it as best I can.

[Jon Clark1]

One interesting thing I see is just before the BYE message from VGW2 to CUCM.

CUCM responds with the ACK below to VGW2.

Notice the audio line is out of order

Does this cause VGW2 to immediately send the BYE?

c=IN IP4 (IP Address of VGW1)
b=TIAS:8000
b=AS:8
t=0 0
m=audio 25934 RTP/AVP 101 18 100 (Notice the codec(g729) is 2nd. Typically the codec goes first.)
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:18 G729/8000

Right after this VGW2 sends an immediate BYE

Call Trace from CUCM Below

(Top portion of BYE Message omitted)

User-Agent: Cisco-SIPGateway/IOS-16.6.5
Max-Forwards: 70
Timestamp: 1571343244
CSeq: 101 BYE
Reason: Q.850;cause=86

(snippet from the VGW debugs)

Below... the ACT from CUCM... notice the immediate call disconnected(Cause 111) after

=audio 25934 RTP/AVP 101 18 100
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000

065031: Oct 17 15:14:04.913: //300765/A6B0B9800000/CCAPI/cc_api_call_disconnected:
Cause Value=111, Interface=0x7FC49AE87EF0, Call Id=300765
065032: Oct 17 15:14:04.913: //300765/A6B0B9800000/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=111, Retry Count=0)
065033: Oct 17 15:14:04.913: //300767/A6B0B9800000/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=300767
065034: Oct 17 15:14:04.913: //300765/A6B0B9800000/CCAPI/ccConferenceDestroy:
Conference Id=0x2193, Tag=0x0
065035: Oct 17 15:14:04.914: //300765/A6B0B9800000/CCAPI/ccConferenceDestroy:

[Jon Clark1 · Accepted solution]

Not that the community was any help whatsoever (0 responses) but the problem ended up being codec mismatch. The resolution was to increase the originating region to use G711 to match the E2E region of the cube.

The originating region did not have any codecs defined for the #E2E region thus defaulting to the System Default which was 8kbps.

The outgoing dial peer did not have any voice class codec settings defined thus using G711 in the 183.  For whatever reason CUCM gave a 200OK to using G711 but then sent a re-invite and only offered G729. (Subsequently this is after the Connect and Connect ACK took place between the CUBE and Provider.

So in short, CUCM first agrees on G711, then tries to change it's mind to G729.  This was too late as G711 was already negotiated thus generating the cause code 86 and cause code 111 (protocol error).

Lesson learned.  Codec mismatch can cause a cause code 86 and cause code 111.  Nothing to do with IE's or anything on the provider side.

If the CUBE does all the disconnecting (BYE to CUCM and DISCONNECT to Provider) then most likely check your region settings.

I caught the goofy response of having G729 2nd in the pecking order but I never acted on it. Shame on me. I was close though!

If you have any questions ask away!

JC