Hi Ken, Sure - will do that once I get to work. Will also do a bit of testing (i.e. test things out by maxing the channels, SRST, bakcup etc.) and post the results.
On Sun, Oct 9, 2011 at 12:40 PM, Ken Wyan <kew...@gmail.com> wrote: > 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
