Kshitij, Can you share with us the screenshot of relevant MGCP Gateway Endpoint Configuration page of CUCM GUI as well.
Thanks, Ken On Fri, Oct 7, 2011 at 12:36 PM, Kshitij Singhi <martinian.ksin...@gmail.com > wrote: > OK. Let's dance. > > Given below is my configuration (the pertinent section): > > show run | sec controller > controller T1 0/0/0 > framing esf > linecode b8zs > pri-group timeslots 1-3,24 service mgcp > > show run | sec interface Serial0/0/0 > interface Serial0/0/0:23 > no ip address > encapsulation hdlc > isdn switch-type primary-ni > isdn incoming-voice voice > isdn bind-l3 ccm-manager > isdn outgoing display-ie > isdn outgoing ie redirecting-number > no cdp enable > > show run | in mgcp > pri-group timeslots 1-3,24 service mgcp > ccm-manager mgcp > mgcp > mgcp call-agent 192.168.10.47 service-type mgcp version 0.1 > no mgcp package-capability res-package > no mgcp timer receive-rtcp > mgcp bind control source-interface GigabitEthernet0/0.102 > mgcp bind media source-interface GigabitEthernet0/0.102 > mgcp profile default > > show run | in ccm > isdn bind-l3 ccm-manager > ccm-manager switchback immediate > ccm-manager redundant-host 192.168.10.46 > ccm-manager mgcp > no ccm-manager fax protocol cisco > ccm-manager music-on-hold > > do show ccm-manager > MGCP Domain Name: SiteA > Priority Status Host > ============================================================ > Primary Registered 192.168.10.47 > First Backup Backup Ready 192.168.10.46 > Second Backup None > > Current active Call Manager: 192.168.10.47 > Backhaul/Redundant link port: 2428 > Failover Interval: 30 seconds > Keepalive Interval: 15 seconds > Last keepalive sent: 21:50:15 PDT Oct 6 2011 (elapsed time: > 00:00:10) > Last MGCP traffic time: 21:50:15 PDT Oct 6 2011 (elapsed time: > 00:00:10) > Last failover time: 01:07:35 PDT Oct 1 2011 from > (192.168.10.47) > Last switchback time: 01:08:05 PDT Oct 1 2011 from > (192.168.10.46) > Switchback mode: Immediate > MGCP Fallback mode: Not Selected > Last MGCP Fallback start time: None > Last MGCP Fallback end time: None > MGCP Download Tones: Disabled > TFTP retry count to shut Ports: 2 > > Backhaul Link info: > Link Protocol: TCP > Remote Port Number: 2428 > Remote IP Address: 192.168.10.47 > Current Link State: OPEN > Statistics: > Packets recvd: 1 > Recv failures: 0 > Packets xmitted: 1 > Xmit failures: 0 > PRI Ports being backhauled: > Slot 0, VIC 0, port 0 > FAX mode: disable > Configuration Error History: > > Let's take a look at this section in point 1: > > "we here talking about the B Channel not > the D-Channal so getting 500 on the AUEP doesnt mean > the mgcp gw will busy out this channel and thats exactly why we have > this service paramert in the ccm to busy out the b-chann" > > Since I have only 3 channels configured on the T1 controller, I took a > debug mgcp packet and saw: > > Oct 7 04:48:00.453: MGCP Packet sent to 192.168.10.47:2427---> > RSIP 696986311 *@SiteA MGCP 0.1 > RM: restart > <--- > > Oct 7 04:48:00.457: MGCP Packet received from 192.168.10.47:2427---> > 200 696986311 > <--- > > Oct 7 04:48:00.461: MGCP Packet received from 192.168.10.47:2427---> > AUEP 259 S0/SU0/DS1-0/1@SiteA MGCP 0.1 > F: X, A, I > <--- > > Oct 7 04:48:00.461: MGCP Packet sent to 192.168.10.47:2427---> > 200 259 > I: > X: 0 > L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, > r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, > t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, > r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, > netwloop, netwtest > <--- > > Oct 7 04:48:00.461: MGCP Packet received from 192.168.10.47:2427---> > AUEP 260 S0/SU0/DS1-0/2@SiteA MGCP 0.1 > F: X, A, I > <--- > > Oct 7 04:48:00.465: MGCP Packet sent to 192.168.10.47:2427---> > 200 260 > I: > X: 0 > L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, > r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, > t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, > r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, > netwloop, netwtest > <--- > > Oct 7 04:48:00.465: MGCP Packet received from 192.168.10.47:2427---> > AUEP 261 S0/SU0/DS1-0/3@SiteA MGCP 0.1 > F: X, A, I > <--- > > Oct 7 04:48:00.465: MGCP Packet sent to 192.168.10.47:2427---> > 200 261 > I: > X: 0 > L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, > r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, > nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, > t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, > r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR > M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, > netwloop, netwtest > <--- > > We receive an AUEP for channels 1,2 and 3 and send a 200 OK for each. > > We receive an AUEP for channels 4 - 23 and send an "Endpoint unknown" for > each channel. > > Oct 7 04:48:00.469: MGCP Packet received from 192.168.10.47:2427---> > AUEP 262 S0/SU0/DS1-0/4@SiteA MGCP 0.1 > F: X, A, I > <--- > > Oct 7 04:48:00.469: MGCP Packet sent to 192.168.10.47:2427---> > 500 262 Endpt Unknown > <--- > > Oct 7 04:48:00.469: MGCP Packet received from 192.168.10.47:2427---> > AUEP 263 S0/SU0/DS1-0/5@SiteA MGCP 0.1 > F: X, A, I > <--- > ... > ... > ... > ... > (output cut for brevity since this is going to be one heck of a long email) > > Oct 7 04:48:00.481: MGCP Packet received from 192.168.10.47:2427---> > AUEP 281 S0/SU0/DS1-0/23@SiteA MGCP 0.1 > F: X, A, I > <--- > > Oct 7 04:48:00.481: MGCP Packet sent to 192.168.10.47:2427---> > 500 281 Endpt Unknown > <--- > > Hence, CUCM asks the GW about the status of the endpoint(s) i.e. the > B-channels configured via the pri-group timeslots command the the GW sends > an appropriate response to channels > > 1,2 and 3 but doesn't have knowledge of the rest of the B-channels. Hence, > the GW sends an endpoint unknown. (Note, all this is being done WITHOUT > changing any Service Parameter > > in CUCM). If we check the "show isdn status", we see: > > do show isdn stat > Global ISDN Switchtype = primary-ni > > %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not > apply > > ISDN Serial0/0/0:23 interface > dsl 0, interface ISDN Switchtype = primary-ni > L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003 > Layer 1 Status: > ACTIVE > Layer 2 Status: > TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED > Layer 3 Status: > 0 Active Layer 3 Call(s) > Active dsl 0 CCBs = 0 > The Free Channel Mask: 0x80000007 > Number of L2 Discards = 0, L2 Session ID = 5 > Total Allocated ISDN CCBs = 0 > > Hence, L2 is in MULTIPLE_FRAME_ESTABLISHED and we have Q.931 backhauling. > > Now let's check what does the gateway have to say about the channels on the > PRI: > > do show isdn ser > PRI Channel Statistics: > > %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not > apply > > ISDN Se0/0/0:23, Channel [1-24] > Configured Isdn Interface (dsl) 0 > Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart > 5=Maint_Pend) > Channel : 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > State : 0 0 0 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > Service State (0=Inservice 1=Maint 2=Outofservice 8=MaintPend 9=OOSPend) > Channel : 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > State : 0 0 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 > > ONLY CHANNELS 1,2 and 3 are Idle/Inservice. All the rest of the channels > are in a reserved state/OOS. (Once again, this is WITHOUT changing any > service parameter on CUCM). > > Just for kicks, let's take a look at the show perf query class "Cisco MGCP > PRI Device" from the SUB, which is where the GW is registered as of now: > > admin:show perf query class "Cisco MGCP PRI Device" > ==>query class : > > - Perf class (Cisco MGCP PRI Device) has instances and values: > sitea::S0_SU0_DS1-0 -> CallsActive = 0 > sitea::S0_SU0_DS1-0 -> CallsCompleted = 0 > sitea::S0_SU0_DS1-0 -> Channel 1 Status = 2 > sitea::S0_SU0_DS1-0 -> Channel 2 Status = 2 > sitea::S0_SU0_DS1-0 -> Channel 3 Status = 2 > sitea::S0_SU0_DS1-0 -> Channel 4 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 5 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 6 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 7 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 8 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 9 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 10 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 11 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 12 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 13 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 14 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 15 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 16 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 17 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 18 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 19 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 20 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 21 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 22 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 23 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 24 Status = 4 > sitea::S0_SU0_DS1-0 -> Channel 25 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 26 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 27 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 28 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 29 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 30 Status = 0 > sitea::S0_SU0_DS1-0 -> Channel 31 Status = 0 > sitea::S0_SU0_DS1-0 -> DatalinkInService = 1 > sitea::S0_SU0_DS1-0 -> OutboundBusyAttempts = 0 > > As this link will tell you: > > > http://www.cisco.com/en/US/docs/net_mgmt/cisco_unified_operations_manager/8.0/user/guide/TrapMIBS.html#wp1054379 > > 0 - Unknown > 1 - OOS > 2 - Idle > 3 - Busy > 4 - Reserved > > Hence, as a result of the "endpoint unknown" sent by the GW, CUCM has > placed ALL the channels in an unknown state (except channels 1,2 and 3). > Question of the day - will CM route > > the call to an endpoint that is in an unknown status? (My neice will be > able to answer that and she just about reaches my waist). Hence, the GW is > putting the "unconfigured" B- > > channels OOS WITHOUT any intervention from the CUCM. The statement "500 on > the AUEP doesnt mean the mgcp gw will busy out this channel and thats > exactly why we have > this service paramert in the ccm to busy out the b-chann" has thus been > shot down. > > After this, it has been stated that: > > "and after > that you can verify this from the show perf query class of the mgcp > pri and you will see the bchannl not in use on status 2" > > Firstly, status 2 means the channel is idle and not that the B-channel is > not in use. > Secondly, CUCM is intelligent enough to put the B-channel in an unknown > state without modifying the parameter, as is evident from the output given > above. > > > One might argue - what about functionality? Is it really so simple to get > 3/4 points in the GW section? Do we have any proof of the functionality? > Surprisingly, we do!!! I made the > > following tests: > > 1. Call to 911 with the aforementioned configuration. > > MGCP CRCX shows: > > Oct 7 05:41:34.913: MGCP Packet received from 192.168.10.47:2427---> > CRCX 290 S0/SU0/DS1-0/3@SiteA MGCP 0.1 > C: D00000000202e629000000F500000003 > X: 3 > L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 > M: recvonly > R: D/[0-9ABCD*#] > Q: process,loop > <--- > > What do you know - my neice was correct!! CUCM is sending the call on > Channel 3 of the PRI despite the Service Parameter in CUCM being left > untouched. > > ISDN setup shows the same: > > Oct 7 05:41:34.933: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = > 0x0003 > Bearer Capability i = 0x8090A2 > Standard = CCITT > Transfer Capability = Speech > Transfer Mode = Circuit > Transfer Rate = 64 kbit/s > Channel ID i = 0xA98383 > Exclusive, Channel 3 > Called Party Number i = 0x81, '911' > Plan:ISDN, Type:Unknown > Oct 7 05:41:34.945: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref > = 0x8003 > Channel ID i = 0xA98383 > Exclusive, Channel 3 > > 2, For laughs, I went ahead and changed the channel selection on the PRI > endpoint page such that CUCM uses channel 1. (just to see if functionality > changes post changing this back > > again). For now, as expected, we saw that: > > MGCP is sending the call on channel 1: > > Oct 7 05:43:00.141: MGCP Packet received from 192.168.10.47:2427---> > CRCX 317 S0/SU0/DS1-0/1@SiteA MGCP 0.1 > C: D00000000202e62b000000F500000001 > X: 1 > L: p:20, a:PCMU, s:off, t:00 > M: recvonly > R: D/[0-9ABCD*#] > Q: process,loop > <--- > > ISDN forwards the same: > > Oct 7 05:43:00.157: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = > 0x0001 > Bearer Capability i = 0x8090A2 > Standard = CCITT > Transfer Capability = Speech > Transfer Mode = Circuit > Transfer Rate = 64 kbit/s > Channel ID i = 0xA98381 > Exclusive, Channel 1 > Called Party Number i = 0x81, '911' > Plan:ISDN, Type:Unknown > Oct 7 05:43:00.169: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref > = 0x8001 > Channel ID i = 0xA98381 > Exclusive, Channel 1 > > 3. I now flipped this over to what it was originally at, to check if CUCM > suddenly decides that it doesn't know that channels 4-23 are OOS/unknown > since the service parameter has > > not been configured, and the results were obvious. The call went out > channel 3 again: > > Oct 7 06:16:51.836: MGCP Packet received from 192.168.10.47:2427---> > CRCX 344 S0/SU0/DS1-0/3@SiteA MGCP 0.1 > C: D00000000202e62d000000F500000001 > X: 3 > L: p:20, a:PCMU, s:off, t:00 > M: recvonly > R: D/[0-9ABCD*#] > Q: process,loop > <--- > > Oct 7 06:16:51.856: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = > 0x0001 > Bearer Capability i = 0x8090A2 > Standard = CCITT > Transfer Capability = Speech > Transfer Mode = Circuit > Transfer Rate = 64 kbit/s > Channel ID i = 0xA98383 > Exclusive, Channel 3 > Called Party Number i = 0x81, '911' > Plan:ISDN, Type:Unknown > Oct 7 06:16:51.868: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref > = 0x8001 > Channel ID i = 0xA98383 > Exclusive, Channel 3 > > Thus, the long and short of it is that the configuration/setup given above > is "working" great and is "true". > > Ash - I had humbly requested you not to stoop lower and that is exactly > what happened - empty threats. It's sad. Very sad. > > I'm not really sure what you mean by "Real Labs" or "Real expert/escalation > team" > > Not once has anyone ever mentioned that the word of a TAC engineer is law > and it should be followed without question, but you seem to have inferred > that from somewhere - I hope the delusion passes. > > Everyone, I would like to sincerely apologize for the unfortunate exchange > of emails (and applaud whoever had the patience to look through this one coz > I dozed off while reading through it :) ) that should not have taken place > on the OSL in the first place. It goes against the spirit of the OSL and > creates unnecessary friction. > > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
