Hi all, I just got my score report and even though i got 100% for alot of things i didnt pass and got low scores fer stuff like VM, High availibilty.
Now i tested all these and they worked as asked. I was wondering if anyone can give me any ideas on what could have caused such low scores. Thanks Kev -----Original Message----- From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of ccie_voice-requ...@onlinestudylist.com Sent: 11 October 2011 05:22 To: ccie_voice@onlinestudylist.com Subject: CCIE_Voice Digest, Vol 68, Issue 71 Send CCIE_Voice mailing list submissions to ccie_voice@onlinestudylist.com To subscribe or unsubscribe via the World Wide Web, visit http://onlinestudylist.com/mailman/listinfo/ccie_voice or, via email, send a message with subject or body 'help' to ccie_voice-requ...@onlinestudylist.com You can reach the person managing the list at ccie_voice-ow...@onlinestudylist.com When replying, please edit your Subject line so it is more specific than "Re: Contents of CCIE_Voice digest..." Today's Topics: 1. Re: Fwd: Fractional MGCP (Ashraf Ayyash) ---------------------------------------------------------------------- Message: 1 Date: Mon, 10 Oct 2011 23:22:25 -0500 From: Ashraf Ayyash <ash.ayy...@gmail.com> To: Kshitij Singhi <martinian.ksin...@gmail.com> Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] Fwd: Fractional MGCP Message-ID: <CAEW==nt4-GYD-spnRN_FOD+==s9kdvfpplsibyvtlkpy++6...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 sorry small correction On Mon, Oct 10, 2011 at 11:19 PM, Ashraf Ayyash <ash.ayy...@gmail.com> wrote: > Hey Kshitij , > > the service parameter WILL NOT come to play in the SRST as you are taking the > ccm out of the game and bringing the default routing application in > charge (h323) , the service parameter will come to play when you will > have for example 3 bchannal group configured under the controller and > you have no service parameter on the ccm ( so the ccm thought he have > full T1/E1) ?, and then get 3 concurrent calls (so full of what you > have) and then try to setup the 4th call , the ccm will send the call > over (please put one GW in the RG) and then you will see Setup going > on Channel 4 and you will see the call getting disconnected with > requested channel not available and you MUST have configured 3 > channels only configured on the PSTN router (which will emulate the > real life as the PSTN will setup only channels # of what you paid for > and if you will sent new call ( we have 3 active calls) on the 4rth > Channel you will get i mentioned about ) and hence the need of the > service parameter . > > > finally , in your example i don't think the GW debugs is the good > place to check as the route Group is A CCM decision and the GW is MGCP > Slave to the CCM so please include ccm sdi /SDL traces on the detailed > level so we can see how the ccm decided to send the call to specific > endpoint in the route group > > Ash > > On Mon, Oct 10, 2011 at 4:59 PM, Kshitij Singhi > <martinian.ksin...@gmail.com> wrote: >> Resending since the email bounced due to its size. I guess Ken would have >> received the endpoint configuration and hence removing the attachments. >> >> ---------- Forwarded message ---------- >> From: Kshitij Singhi <martinian.ksin...@gmail.com> >> Date: Mon, Oct 10, 2011 at 7:36 PM >> Subject: Re: [OSL | CCIE_Voice] Fractional MGCP >> To: Ken Wyan <kew...@gmail.com> >> Cc: ccie_voice@onlinestudylist.com >> >> >> Attached are the screenshots of the GW configuration (main page and >> endpoint). Site A and Site B are more or less identical (except for the >> domain names) and both have the defaults configured (SF set to 4 and Display >> IE delivery, Redirecting IE delivery outbound/inbound being checked). >> I performed the following tests: >> 1. Maxing out the channels and then checking if it fails over to the next >> option in the RG. >> 2. Maxing out the channels and then checking if it fails over to the next >> option in the RL. >> 3. Maxing out the channels by making incoming calls and then calling out to >> check if the call goes out via the next option in the RG. >> 4. Calls during SRST. (both incoming and outgoing to see if there is any >> change in behavior) >> 5. Bringing the Site out of SRST to see if there is any change in behavior. >> FOR POINT 1 GIVEN ABOVE >> Call 1 going out via channel 3 >> ========================== >> Oct 10 12:57:30.789: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 463 S2/DS1-0/3...@site-b.yourdomain.com MGCP 0.1 >> C: D00000000202e650000000F500000003 >> X: 3 >> L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Oct 10 12:57:30.813: ISDN Se2/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 >> Calling Party Number i = 0x0081, '3002' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0x80, '911' >> Plan:Unknown, Type:Unknown >> Oct 10 12:57:30.829: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8003 >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Call 2 going out via channel 2 >> =========================== >> Oct 10 12:57:39.806: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 467 S2/DS1-0/2...@site-b.yourdomain.com MGCP 0.1 >> C: D00000000202e653000000F500000004 >> X: 2 >> L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Oct 10 12:57:39.826: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x0004 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Calling Party Number i = 0x0081, '3002' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0x80, '911' >> Plan:Unknown, Type:Unknown >> Oct 10 12:57:39.842: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8004 >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> >> Call 3 going out via channel 1 >> ========================== >> Oct 10 12:57:49.279: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 471 S2/DS1-0/1...@site-b.yourdomain.com MGCP 0.1 >> C: D00000000202e656000000F500000005 >> X: 1 >> L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Oct 10 12:57:49.299: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x0005 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> Calling Party Number i = 0x0081, '3002' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0x80, '911' >> Plan:Unknown, Type:Unknown >> Oct 10 12:57:49.315: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8005 >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> All 3 channels of the MGCP PRI now have an active call on them. I have set >> the RG to point to the Site B GW as the first option and the Site A GW as >> the second option with a hunting algorithm of top-down. >> Here is the output from the Site A GW when a call was attempted from the >> Site B GW after maxing out the channels: >> Call 4 going out of Site A channel 3 >> ================================ >> Oct 10 13:00:34.985: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 477 S0/SU0/DS1-0/3@SiteA MGCP 0.1 >> C: D00000000202e65b000000F500000003 >> X: 3 >> L: p:20, a:G.729b, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Oct 10 13:00:35.001: 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 >> Calling Party Number i = 0x0081, '3002' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0x80, '911' >> Plan:Unknown, Type:Unknown >> Oct 10 13:00:35.017: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8003 >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> >> FOR POINT 2 GIVEN ABOVE >> Set only 1 GW in the RG and added a new RG with just the SiteA GW. Added the >> new RG to the RL. Results were identical. >> FOR POINT 3 GIVEN ABOVE >> >> Call 1 coming in on channel 1 >> ========================= >> Oct 10 13:12:17.889: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x0084 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033002' >> Plan:ISDN, Type:National >> Oct 10 13:12:17.905: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 554 S2/DS1-0/1...@site-b.yourdomain.com MGCP 0.1 >> C: D00000000202e684000000F580000084 >> X: 1 >> L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Call 2 coming in on channel 2 >> ========================== >> Oct 10 13:12:31.210: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x0085 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033002' >> Plan:ISDN, Type:National >> Oct 10 13:12:31.222: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 557 S2/DS1-0/2...@site-b.yourdomain.com MGCP 0.1 >> C: D00000000202e687000000F580000085 >> X: 2 >> L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Call 3 coming in on channel 3 >> ========================== >> Oct 10 13:12:41.759: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x0086 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033102' >> Plan:ISDN, Type:National >> >> CRCX 562 S2/DS1-0/3...@site-b.yourdomain.com MGCP 0.1 >> C: D00000000202e68b000000F580000086 >> X: 3 >> L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> (I had to change the called number over here since Extension 3002 had a busy >> trigger of 2) >> Hence, all channels are maxed out as of now on Site B (incoming calls only). >> I now attempted to make a call to 911 from a Site B Phone (the RP has a RL - >> - - RG (which has the Site B GW as the first option and the Site A GW as the >> second option, algorithm is top-down). There was no output from the Site B >> GW but the Site A GW showed: >> Oct 10 13:13:43.239: MGCP Packet received from 192.168.10.47:2427---> >> CRCX 573 S0/SU0/DS1-0/3@SiteA MGCP 0.1 >> C: D00000000202e692000000F50000000b >> X: 3 >> L: p:20, a:G.729b, s:off, t:b8, fxr/fx:t38 >> M: recvonly >> R: D/[0-9ABCD*#] >> Q: process,loop >> <--- >> Oct 10 13:13:43.255: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x000B >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Calling Party Number i = 0x0081, '3102' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0x80, '911' >> Plan:Unknown, Type:Unknown >> Oct 10 13:13:43.271: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x800B >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> As we can see, the call is going out on of the Site A MGCP PRI on channel 3 >> with a calling number of 3102 (which is a Site B Extension). >> FOR POINT 4 GIVEN ABOVE >> I put Site B into SRST to see if there is a change in the incoming/outgoing >> call behavior. I first made outgoing calls: >> MGCP Domain Name: Site-B.yourdomain.com >> Priority ? ? ? ?Status ? ? ? ? ? ? ? ? ? Host >> ============================================================ >> Primary ? ? ? ? Down ? ? ? ? ? ? ? ? ? ? 192.168.10.47 >> First Backup ? ?Registering with CM ? ? ?192.168.10.46 >> Second Backup ? None >> Site-B(config)#do show ephon reg >> >> ephone-1[0] Mac:0018.1885.5C05 TCP socket:[1] activeLine:0 whisperLine:0 >> REGISTERED in SCCP ver 17/12 max_streams=5 >> mediaActive:0 whisper_mediaActive:0 startMedia:0 offhook:0 ringing:0 reset:0 >> reset_sent:0 paging 0 debug:0 caps:8 privacy:1 >> IP:142.102.65.30 22606 7971 ?keepalive 1 max_line 8 available_line 2 >> button 1: dn 1 ?number 3002 ?CM Fallback CH1 ? IDLE ? ? ? ? CH2 ? IDLE >> ? CH3 ? IDLE ? ? ? ? CH4 ? IDLE ? ? ? ? CH5 ? IDLE ? ? ? ? CH6 ? IDLE >> ? CH7 ? IDLE ? ? ? ? CH8 ? IDLE >> button 2: dn 2 ?number 3102 ?CM Fallback CH1 ? IDLE ? ? ? ? CH2 ? IDLE >> ? CH3 ? IDLE ? ? ? ? CH4 ? IDLE ? ? ? ? CH5 ? IDLE ? ? ? ? CH6 ? IDLE >> ? CH7 ? IDLE ? ? ? ? CH8 ? IDLE >> Preferred Codec: g711ulaw >> 1st outbound call went out channel 3 as before >> =========================================== >> Oct 10 13:20:56.422: ISDN Se2/0:23 Q931: Applying typeplan for sw-type 0xD >> is 0x4 0x1, Calling num 3033002 >> Oct 10 13:20:56.422: ISDN Se2/0:23 Q931: Sending SETUP ?callref = 0x0080 >> callID = 0x8001 switch = primary-ni interface = User >> Oct 10 13:20:56.422: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x0080 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Progress Ind i = 0x8183 - Origination address is non-ISDN >> Calling Party Number i = 0x4180, '3033002' >> Plan:ISDN, Type:Subscriber(local) >> Called Party Number i = 0x81, '911' >> Plan:ISDN, Type:Unknown >> Oct 10 13:20:56.442: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8080 >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> 2nd outbound call went out channel 2 as before >> =========================================== >> Oct 10 13:21:03.006: ISDN Se2/0:23 Q931: Applying typeplan for sw-type 0xD >> is 0x4 0x1, Calling num 3033002 >> Oct 10 13:21:03.006: ISDN Se2/0:23 Q931: Sending SETUP ?callref = 0x0081 >> callID = 0x8002 switch = primary-ni interface = User >> Oct 10 13:21:03.006: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x0081 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Progress Ind i = 0x8183 - Origination address is non-ISDN >> Calling Party Number i = 0x4180, '3033002' >> Plan:ISDN, Type:Subscriber(local) >> Called Party Number i = 0x81, '911' >> Plan:ISDN, Type:Unknown >> Oct 10 13:21:03.022: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8081 >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> 3rd outbound call went out channel 3 as before >> ============================================ >> Oct 10 13:21:09.058: ISDN Se2/0:23 Q931: Applying typeplan for sw-type 0xD >> is 0x4 0x1, Calling num 3033002 >> Oct 10 13:21:09.058: ISDN Se2/0:23 Q931: Sending SETUP ?callref = 0x0082 >> callID = 0x8003 switch = primary-ni interface = User >> Oct 10 13:21:09.062: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x0082 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> Progress Ind i = 0x8183 - Origination address is non-ISDN >> Calling Party Number i = 0x4180, '3033002' >> Plan:ISDN, Type:Subscriber(local) >> Called Party Number i = 0x81, '911' >> Plan:ISDN, Type:Unknown >> Oct 10 13:21:09.078: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8082 >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> I then disconnected all three calls and set the huntstop channel under >> call-manager-fallback to 1: >> Oct 10 13:21:21.191: %ISDN-6-DISCONNECT: Interface Serial2/0:0 ?disconnected >> from 911 , call lasted 10 seconds >> Oct 10 13:21:23.676: %ISDN-6-DISCONNECT: Interface Serial2/0:1 ?disconnected >> from 911 , call lasted 18 seconds >> Oct 10 13:21:25.372: %ISDN-6-DISCONNECT: Interface Serial2/0:2 ?disconnected >> from 911 , call lasted 25 seconds >> Site-B(config)#do show run | sec call-manager >> call-manager-fallback >> ?secondary-dialtone 9 >> ?max-conferences 8 gain -6 >> ?transfer-system full-consult >> ?ip source-address XXX.XXX.XXX.XXX port 2000 >> ?max-ephones 10 >> ?max-dn 10 octo-line >> ?transfer-pattern .T >> ?voicemail 2220 >> ?huntstop channel 1 >> ?call-forward pattern .T >> 1st incoming call to the Site B router came in on channel 1 as before >> ============================================================== >> Oct 10 13:21:49.761: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x0088 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033002' >> Plan:ISDN, Type:National >> Oct 10 13:21:49.761: ISDN Se2/0:23 Q931: Received SETUP ?callref = 0x8088 >> callID = 0x0002 switch = primary-ni interface = User >> Oct 10 13:21:49.765: ISDN Se2/0:23 Q931: TX -> CALL_PROC pd = 8 ?callref = >> 0x8088 >> Channel ID i = 0xA98381 >> Exclusive, Channel 1 >> 2nd incoming call to the Site B router came in on channel 2 as before, but >> gave an unallocated/unassigned number since the CFB for the Site B Phone is >> not reachable yet >> ============================================================================ ============================================================================ === >> Oct 10 13:22:02.242: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x0089 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033002' >> Plan:ISDN, Type:National >> Oct 10 13:22:02.242: ISDN Se2/0:23 Q931: Received SETUP ?callref = 0x8089 >> callID = 0x0003 switch = primary-ni interface = User >> Oct 10 13:22:02.250: ISDN Se2/0:23 Q931: TX -> CALL_PROC pd = 8 ?callref = >> 0x8089 >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Oct 10 13:22:02.250: ISDN Se2/0:23 Q931: TX -> DISCONNECT pd = 8 ?callref = >> 0x8089 >> Cause i = 0x8081 - Unallocated/unassigned number >> >> I then removed the huntstop channel 1 from call-manager-fallback and tried >> another incoming call. >> Hence, next incoming call to the Site B router came in on channel 2 once >> more >> ======================================================================= >> Oct 10 13:22:35.017: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x008A >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033002' >> Plan:ISDN, Type:National >> Oct 10 13:22:35.021: ISDN Se2/0:23 Q931: Received SETUP ?callref = 0x808A >> callID = 0x0004 switch = primary-ni interface = User >> Oct 10 13:22:35.025: ISDN Se2/0:23 Q931: TX -> CALL_PROC pd = 8 ?callref = >> 0x808A >> Channel ID i = 0xA98382 >> Exclusive, Channel 2 >> Oct 10 13:22:35.025: ISDN Se2/0:23 Q931: TX -> ALERTING pd = 8 ?callref = >> 0x808A >> Progress Ind i = 0x8188 - In-band info or appropriate now available >> Last incoming call to the Site B router came in on channel 3 as before >> ================================================================ >> >> Oct 10 13:22:43.805: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8 ?callref = >> 0x008B >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Progress Ind i = 0x8583 - Origination address is non-ISDN >> Display i = 'Emergency Services' >> Calling Party Number i = 0x0080, '911' >> Plan:Unknown, Type:Unknown >> Called Party Number i = 0xA1, '9723033002' >> Plan:ISDN, Type:National >> Oct 10 13:22:43.805: ISDN Se2/0:23 Q931: Received SETUP ?callref = 0x808B >> callID = 0x0005 switch = primary-ni interface = User >> Oct 10 13:22:43.813: ISDN Se2/0:23 Q931: TX -> CALL_PROC pd = 8 ?callref = >> 0x808B >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> I then disconnected one call and made an outgoing call >> Oct 10 13:22:53.914: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8 ?callref = >> 0x0083 >> Bearer Capability i = 0x8090A2 >> Standard = CCITT >> Transfer Capability = Speech >> Transfer Mode = Circuit >> Transfer Rate = 64 kbit/s >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Progress Ind i = 0x8183 - Origination address is non-ISDN >> Calling Party Number i = 0x4180, '3033002' >> Plan:ISDN, Type:Subscriber(local) >> Called Party Number i = 0x81, '911' >> Plan:ISDN, Type:Unknown >> Oct 10 13:22:53.930: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8 ?callref = >> 0x8083 >> Channel ID i = 0xA98383 >> Exclusive, Channel 3 >> Call succeeded as expected. On bringing the Site out of SRST, everything >> worked - without the need to change the Service Parameter in question. If >> there are any more tests that we would like to try, then please let me know >> but so far, from a practical/theoretical standpoint, things are working as >> expected hence I don't see the need to change the Service Parameter. >> >> On Mon, Oct 10, 2011 at 9:14 AM, Kshitij Singhi >> <martinian.ksin...@gmail.com> wrote: >>> >>> 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 >> > ------------------------------ _______________________________________________ CCIE_Voice mailing list CCIE_Voice@onlinestudylist.com http://onlinestudylist.com/mailman/listinfo/ccie_voice End of CCIE_Voice Digest, Vol 68, Issue 71 ****************************************** _______________________________________________ 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
