Re: [OSL | CCIE_Voice] MGCP MVA CSS and call routing
Hey Bill. It totally made sense. I've seen an issue within the current blueprint 7.0 UCM with complete match and 10 digits. Even if the RD number was 10 digits long and matched exactly the RD number it didn't trigger the IVR. It was working though with partial match 10 digits. Since the remote destination numbers in the implementation I'm talking about are a variable number of digits, I'm forced to use partial match and lower digit match like 7 digits. Thanks, Stefanos On Thu, Nov 7, 2013 at 5:16 AM, Bill Hatcher wrote: > Stefano, > > Something else you will want to watch for once you get it working. If you > want the Remote caller ID to be presented to all sites as if the > call originated from the users desk phone, then the remote CLID at each > sites gateway must be an exact match to the remote destination if the > service parameter is set to "Complete Match." In other words the clid of > the remote device when calling a device at HQ, at Site B, and at Site C > must be the same. If you set the parameter to "Partial Match" then the > remote clid must not be longer than the Remote Destination's destination > number. > > I ran into this in my lab. I had the Service parameter set to Partial > Match, and the number of digits for Partial Match set to 7. When calling > into site B from the Site B PSTN phone number 863-2683 the inbound clid > would present as 7 digits and the caller id on the Site B phone would say > from Site B Phone 1 1001. If I called into the HQ site, the inbound clid > would be 6178632683 and the call on the HQ phone would say from PSTN Phone > Site B 6178632683. Same behavior for Site C. > > The way I got the internal clid to work was set the Remote Destination's > destination number to +16178632683, and the parameters to Partial Match > and 7. Then I created a partition and css called mva-xlate. I assigned > the mva-xlate css as the Rerouting CSS and created a translation pattern \ > +16178632683 in the mva-xlate partition with a SiteB css, and the Called > Party Translations to be mask:XXX Prefix 9. (My Site B uses 9 and 7 > digits for local calls) > > Hope that all made sense and helps. > > Bill > > > On Wed, Nov 6, 2013 at 8:08 PM, StefanoS wrote: > >> Somphol, >> >> Thank you very much for your thorough explanation. >> >> Since the scenario I'm implementing involves several GWs in different >> countries, I've already created different mva DIDs for each country and a >> unique mva DN media resource. I've also placed this DN to the none >> partition in order to avoid any issues. So the h323 trunk/gw does not need >> any CSS, none will do the trick. >> >> I've also allowed h323 to h323 connections and bind it to the SVI of the >> GW. >> >> I'm surprised that didn't think to check the MTP. You're right. The DPs >> use the UCM resources which will do the job I believe since every thing is >> G711ulaw. I'll check the conf of the h323 trunk/gw again. >> >> I'll also use your trace output you added in order to compare it with my >> traces and I'll update you. >> >> Thanks, >> Stefanos >> On Nov 7, 2013 1:16 AM, "Somphol Boonjing" wrote: >> >>> Hi StefanoS, >>> >>> The typical CUCM SDI's DETAIL trace with default ticks should be enough. >>> >>> >>> I think it is likely that the CSS applied to RDP doesn't have access to >>> your "Mobile Voice Access Directory Number"' media resource. (The one you >>> define in Media Resources -> Mobile Voice Access),I found that one out >>> from the trace, it should show that the Call Manager try to search for that >>> number and the number is not accessible via the given CSS on the RDP. >>> >>> I read long time ago from an article (which I am sorry I couldn't recall >>> where I see it), it helps me a lot to distinguish between "Mobile Voice >>> Access DID" and "Mobile Voice Access DN". The author wrote that in a >>> cluster where multiple voice gateways spread across area codes or >>> countries, you are likely to have different "Mobile Voice Access DID", one >>> for each site. There is however only one "Mobile Voice Access DN" media >>> resource. >>> >>> So, we can have 5 H323 GW with MVA DID of x1010, x2010, x3010, x4010, >>> and x5010, these are the DN that reach the IVR.Then, you can define a >>> more distinctive extension for "Mobile Voice Access DID" such as x. >>> [This is the key, once you distinguish these numbers clearly, your trace >>> will be much more easy to understand.I used to assume that the MVA DID >>> and MVA DN must be the same number.] >>> >>> On the H323 Voice Gateway, I also find that you need to >>> "allow-connection h323 to h323" for this to work. >>> >>> >>> Below is a bit of an excerpt for what you can see from CUCM SDI trace >>> relevant to MVA operation, you can skip it entirely. >>> >>> Once the PIN (and the RD Number when applicable) is entered via the IVR, >>> and you tried to make the outgoing call by pressing "1", the IVR script >>> will try to establish a call with that "Mobile
Re: [OSL | CCIE_Voice] MGCP MVA CSS and call routing
Stefano, Something else you will want to watch for once you get it working. If you want the Remote caller ID to be presented to all sites as if the call originated from the users desk phone, then the remote CLID at each sites gateway must be an exact match to the remote destination if the service parameter is set to "Complete Match." In other words the clid of the remote device when calling a device at HQ, at Site B, and at Site C must be the same. If you set the parameter to "Partial Match" then the remote clid must not be longer than the Remote Destination's destination number. I ran into this in my lab. I had the Service parameter set to Partial Match, and the number of digits for Partial Match set to 7. When calling into site B from the Site B PSTN phone number 863-2683 the inbound clid would present as 7 digits and the caller id on the Site B phone would say from Site B Phone 1 1001. If I called into the HQ site, the inbound clid would be 6178632683 and the call on the HQ phone would say from PSTN Phone Site B 6178632683. Same behavior for Site C. The way I got the internal clid to work was set the Remote Destination's destination number to +16178632683, and the parameters to Partial Match and 7. Then I created a partition and css called mva-xlate. I assigned the mva-xlate css as the Rerouting CSS and created a translation pattern \+16178632683 in the mva-xlate partition with a SiteB css, and the Called Party Translations to be mask:XXX Prefix 9. (My Site B uses 9 and 7 digits for local calls) Hope that all made sense and helps. Bill On Wed, Nov 6, 2013 at 8:08 PM, StefanoS wrote: > Somphol, > > Thank you very much for your thorough explanation. > > Since the scenario I'm implementing involves several GWs in different > countries, I've already created different mva DIDs for each country and a > unique mva DN media resource. I've also placed this DN to the none > partition in order to avoid any issues. So the h323 trunk/gw does not need > any CSS, none will do the trick. > > I've also allowed h323 to h323 connections and bind it to the SVI of the > GW. > > I'm surprised that didn't think to check the MTP. You're right. The DPs > use the UCM resources which will do the job I believe since every thing is > G711ulaw. I'll check the conf of the h323 trunk/gw again. > > I'll also use your trace output you added in order to compare it with my > traces and I'll update you. > > Thanks, > Stefanos > On Nov 7, 2013 1:16 AM, "Somphol Boonjing" wrote: > >> Hi StefanoS, >> >> The typical CUCM SDI's DETAIL trace with default ticks should be enough. >> >> I think it is likely that the CSS applied to RDP doesn't have access to >> your "Mobile Voice Access Directory Number"' media resource. (The one you >> define in Media Resources -> Mobile Voice Access),I found that one out >> from the trace, it should show that the Call Manager try to search for that >> number and the number is not accessible via the given CSS on the RDP. >> >> I read long time ago from an article (which I am sorry I couldn't recall >> where I see it), it helps me a lot to distinguish between "Mobile Voice >> Access DID" and "Mobile Voice Access DN". The author wrote that in a >> cluster where multiple voice gateways spread across area codes or >> countries, you are likely to have different "Mobile Voice Access DID", one >> for each site. There is however only one "Mobile Voice Access DN" media >> resource. >> >> So, we can have 5 H323 GW with MVA DID of x1010, x2010, x3010, x4010, and >> x5010, these are the DN that reach the IVR.Then, you can define a more >> distinctive extension for "Mobile Voice Access DID" such as x. [This >> is the key, once you distinguish these numbers clearly, your trace will be >> much more easy to understand.I used to assume that the MVA DID and MVA >> DN must be the same number.] >> >> On the H323 Voice Gateway, I also find that you need to "allow-connection >> h323 to h323" for this to work. >> >> >> Below is a bit of an excerpt for what you can see from CUCM SDI trace >> relevant to MVA operation, you can skip it entirely. >> >> Once the PIN (and the RD Number when applicable) is entered via the IVR, >> and you tried to make the outgoing call by pressing "1", the IVR script >> will try to establish a call with that "Mobile Voice Access DID" media >> resource. (Hence, on every one of those H323 GW, you will need to have a >> dial-peer that allow "x" in our case to be reachable from the H323 GW). >> >> That's one leg of the outgoing call being made. >> >> Another leg is created by that media resource, which I think is a >> software controlling x, in our case.From the trace below, the work >> involves searching for a matched owner and DN, etc. Then make a second >> call leg with the DN. In the trace below, CCM|DbMobility found that Caller >> ID "258001" is a Remote Destination Number for userId "SiteB2". >> >> 11/01/2013 15:38:14.871 *CCM|DbMobility: getMatc
Re: [OSL | CCIE_Voice] MGCP MVA CSS and call routing
Somphol, Thank you very much for your thorough explanation. Since the scenario I'm implementing involves several GWs in different countries, I've already created different mva DIDs for each country and a unique mva DN media resource. I've also placed this DN to the none partition in order to avoid any issues. So the h323 trunk/gw does not need any CSS, none will do the trick. I've also allowed h323 to h323 connections and bind it to the SVI of the GW. I'm surprised that didn't think to check the MTP. You're right. The DPs use the UCM resources which will do the job I believe since every thing is G711ulaw. I'll check the conf of the h323 trunk/gw again. I'll also use your trace output you added in order to compare it with my traces and I'll update you. Thanks, Stefanos On Nov 7, 2013 1:16 AM, "Somphol Boonjing" wrote: > Hi StefanoS, > > The typical CUCM SDI's DETAIL trace with default ticks should be enough. > > I think it is likely that the CSS applied to RDP doesn't have access to > your "Mobile Voice Access Directory Number"' media resource. (The one you > define in Media Resources -> Mobile Voice Access),I found that one out > from the trace, it should show that the Call Manager try to search for that > number and the number is not accessible via the given CSS on the RDP. > > I read long time ago from an article (which I am sorry I couldn't recall > where I see it), it helps me a lot to distinguish between "Mobile Voice > Access DID" and "Mobile Voice Access DN". The author wrote that in a > cluster where multiple voice gateways spread across area codes or > countries, you are likely to have different "Mobile Voice Access DID", one > for each site. There is however only one "Mobile Voice Access DN" media > resource. > > So, we can have 5 H323 GW with MVA DID of x1010, x2010, x3010, x4010, and > x5010, these are the DN that reach the IVR.Then, you can define a more > distinctive extension for "Mobile Voice Access DID" such as x. [This > is the key, once you distinguish these numbers clearly, your trace will be > much more easy to understand.I used to assume that the MVA DID and MVA > DN must be the same number.] > > On the H323 Voice Gateway, I also find that you need to "allow-connection > h323 to h323" for this to work. > > > Below is a bit of an excerpt for what you can see from CUCM SDI trace > relevant to MVA operation, you can skip it entirely. > > Once the PIN (and the RD Number when applicable) is entered via the IVR, > and you tried to make the outgoing call by pressing "1", the IVR script > will try to establish a call with that "Mobile Voice Access DID" media > resource. (Hence, on every one of those H323 GW, you will need to have a > dial-peer that allow "x" in our case to be reachable from the H323 GW). > > That's one leg of the outgoing call being made. > > Another leg is created by that media resource, which I think is a software > controlling x, in our case.From the trace below, the work involves > searching for a matched owner and DN, etc. Then make a second call leg > with the DN. In the trace below, CCM|DbMobility found that Caller ID > "258001" is a Remote Destination Number for userId "SiteB2". > > 11/01/2013 15:38:14.871 *CCM|DbMobility: getMatchedRemDest starts: > cnumber = 258001* > | > 11/01/2013 15:38:14.871 CCM|DbMobility: getMatchedRemDest: full match > case| > 11/01/2013 15:38:14.871 CCM|DbMobility:initRemDest: device pkid > [cf26b6d2-64d7-b771-0347-d08f6d8d950c], profile pkid > [67569716-698c-f39c-cb7c-c0e60c9c12bf], isDualmode [0], isSmartPhone > [0]| > 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initRemDest: > initialized a remdest > [258001]| > 11/01/2013 15:38:14.871 *CCM|DbMobility - RemDest dump: cnumber = 258001*, > devicePkid = cf26b6d2-64d7-b771-0347-d08f6d8d950c, remDestProfilePkidStr = > 67569716-698c-f39c-cb7c-c0e60c9c12bf, isMobilePhone = 0, isDualMode = 0, > isSmartPhone = 0, isSNREnabled= 0, answerTooSoonTimer = 1500, > answerTooLateTimer = 19000, delayBeforeRingingCellTimer = 4000, userId = > SiteB2, timeZoneIndex = 22, description = 258001, url = > | > 11/01/2013 15:38:14.871 CCM|DbMobility: found DN association for remdest > [258001]| > 11/01/2013 15:38:14.871 CCM|DbMobility: found remdest cnumber = 258001, > devicepkid = > cf26b6d2-64d7-b771-0347-d08f6d8d950c| > ... > ... > 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initRemDest: > initialized a remdest > [258001]| > 11/01/2013 15:38:14.871 CCM|DbMobility - RemDest dump: cnumber = 258001, > devicePkid = cf26b6d2-64d7-b771-0347-d08f6d8d950c, remDestProfilePkidStr = > 67569716-698c-f39c-cb7c-c0e60c9c12bf, isMobilePhone = 0, isDualMode = 0, > isSmartPhone = 0, isSNREnabled= 0, answerTooSoonTimer = 1500, > answerTooLateTimer = 19000, delayBeforeRingingCellTimer = 4000, userId = > SiteB2, timeZoneIndex = 22, description = 258001, url = > | > 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initMobilityUser: -- > created mobility > user| > 11/01/2013
Re: [OSL | CCIE_Voice] MGCP MVA CSS and call routing
Hi StefanoS, The typical CUCM SDI's DETAIL trace with default ticks should be enough. I think it is likely that the CSS applied to RDP doesn't have access to your "Mobile Voice Access Directory Number"' media resource. (The one you define in Media Resources -> Mobile Voice Access),I found that one out from the trace, it should show that the Call Manager try to search for that number and the number is not accessible via the given CSS on the RDP. I read long time ago from an article (which I am sorry I couldn't recall where I see it), it helps me a lot to distinguish between "Mobile Voice Access DID" and "Mobile Voice Access DN". The author wrote that in a cluster where multiple voice gateways spread across area codes or countries, you are likely to have different "Mobile Voice Access DID", one for each site. There is however only one "Mobile Voice Access DN" media resource. So, we can have 5 H323 GW with MVA DID of x1010, x2010, x3010, x4010, and x5010, these are the DN that reach the IVR.Then, you can define a more distinctive extension for "Mobile Voice Access DID" such as x. [This is the key, once you distinguish these numbers clearly, your trace will be much more easy to understand.I used to assume that the MVA DID and MVA DN must be the same number.] On the H323 Voice Gateway, I also find that you need to "allow-connection h323 to h323" for this to work. Below is a bit of an excerpt for what you can see from CUCM SDI trace relevant to MVA operation, you can skip it entirely. Once the PIN (and the RD Number when applicable) is entered via the IVR, and you tried to make the outgoing call by pressing "1", the IVR script will try to establish a call with that "Mobile Voice Access DID" media resource. (Hence, on every one of those H323 GW, you will need to have a dial-peer that allow "x" in our case to be reachable from the H323 GW). That's one leg of the outgoing call being made. Another leg is created by that media resource, which I think is a software controlling x, in our case.From the trace below, the work involves searching for a matched owner and DN, etc. Then make a second call leg with the DN. In the trace below, CCM|DbMobility found that Caller ID "258001" is a Remote Destination Number for userId "SiteB2". 11/01/2013 15:38:14.871 *CCM|DbMobility: getMatchedRemDest starts: cnumber = 258001* | 11/01/2013 15:38:14.871 CCM|DbMobility: getMatchedRemDest: full match case| 11/01/2013 15:38:14.871 CCM|DbMobility:initRemDest: device pkid [cf26b6d2-64d7-b771-0347-d08f6d8d950c], profile pkid [67569716-698c-f39c-cb7c-c0e60c9c12bf], isDualmode [0], isSmartPhone [0]| 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initRemDest: initialized a remdest [258001]| 11/01/2013 15:38:14.871 *CCM|DbMobility - RemDest dump: cnumber = 258001*, devicePkid = cf26b6d2-64d7-b771-0347-d08f6d8d950c, remDestProfilePkidStr = 67569716-698c-f39c-cb7c-c0e60c9c12bf, isMobilePhone = 0, isDualMode = 0, isSmartPhone = 0, isSNREnabled= 0, answerTooSoonTimer = 1500, answerTooLateTimer = 19000, delayBeforeRingingCellTimer = 4000, userId = SiteB2, timeZoneIndex = 22, description = 258001, url = | 11/01/2013 15:38:14.871 CCM|DbMobility: found DN association for remdest [258001]| 11/01/2013 15:38:14.871 CCM|DbMobility: found remdest cnumber = 258001, devicepkid = cf26b6d2-64d7-b771-0347-d08f6d8d950c| ... ... 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initRemDest: initialized a remdest [258001]| 11/01/2013 15:38:14.871 CCM|DbMobility - RemDest dump: cnumber = 258001, devicePkid = cf26b6d2-64d7-b771-0347-d08f6d8d950c, remDestProfilePkidStr = 67569716-698c-f39c-cb7c-c0e60c9c12bf, isMobilePhone = 0, isDualMode = 0, isSmartPhone = 0, isSNREnabled= 0, answerTooSoonTimer = 1500, answerTooLateTimer = 19000, delayBeforeRingingCellTimer = 4000, userId = SiteB2, timeZoneIndex = 22, description = 258001, url = | 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initMobilityUser: -- created mobility user| 11/01/2013 15:38:14.872 *CCM|DbMobility - User dump: userId = SiteB2*, isIVREnabled = 1, maxDeskPickupWaitTime = 1| ... ... Then, a call is made to the target number. Once the 2nd call leg is established. The two call legs will be joined by an MTP (well and/or Xcoder when applicable). You can see two CallID below. 11/01/2013 15:45:23.904 *CCM|ConnectionManager - wait_AuConnectRequest(30376367,30376369)* | 11/01/2013 15:45:23.904 CCM|ConnectionManager - storeMediaInfo(30376367): ADD NEW ENTRY, size=1| 11/01/2013 15:45:23.904 CCM|ConnectionManager - storeMediaInfo(30376369): ADD NEW ENTRY, size=2| ... ... 11/01/2013 15:45:23.904 CCM|MediaManager(45)::wait_AuConnectRequest, CI(30376367,30376369), mcNodeId(0,0), xferMode(13,4), reConnectType(0), mrid (0, 0) IFCreated(0 0) proIns(0 0), AC(1,0) party1DTMF(4 4 0 1) party2DTMF(4 1 0 0),reConnFlag=0, connType(3,3), IFHand(0,0),MTP(2,0),MRGL(f2590a96-7e9c-b104-8660-781ca3dcc16a,f2590a96-7e9c-b104-8660-781ca3dcc16a) videoCap(0 0), mmCallType(0)
[OSL | CCIE_Voice] MGCP MVA CSS and call routing
Hello all. I know that there are so many references to this subject but from what I've read nothing helped me so far. So thank you for your patience and understanding. I have a MVA scenario: PSTN > MGCP GW > UCM SUB with H323 VXML The MVA triggers OK I'm listening the IVR. I enter the remote destination number, I enter the PIN. After authentication I press 1 to make a call. So whatever I try to call (internal extensions or PSTN numbers) I hear the message "Your call cannot be completed as dialed. Please ... blah blah blah". I've configured the RDP with the appropriate CSS (not the rerouting CSS for SNR but the normal one) in order to make calls to the PSTN/internal. This CSS works fine to make calls using the local MGCP gateway (which is the same as the MVA GW) from the user's phone. All the RPs are created and matching the dial plan I use. I'm using G711ulaw since this is the HQ I'm testing. everything is in the same DP. I've made it work in the past many times in real life or lab environment. In any case what traces should I enable in the UCM in order to troubleshoot this? Have you any other suggestion for resolve this issue? What am I missing here? Thank you, Stefanos ___ 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
