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 >> > _______________________________________________ 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
