Hey Kshitij , the service parameter 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 > _______________________________________________ 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
