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" <somp...@gmail.com> 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 x8888. [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 "x8888" 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 x8888, 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* > |<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 11/01/2013 15:38:14.871 CCM|DbMobility: getMatchedRemDest: full match > case|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 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]|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initRemDest: > initialized a remdest > [258001]|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 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 = > |<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 11/01/2013 15:38:14.871 CCM|DbMobility: found DN association for remdest > [258001]|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 11/01/2013 15:38:14.871 CCM|DbMobility: found remdest cnumber = 258001, > devicepkid = > cf26b6d2-64d7-b771-0347-d08f6d8d950c|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > ... > ... > 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initRemDest: > initialized a remdest > [258001]|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 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 = > |<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 11/01/2013 15:38:14.871 CCM|DbMobilityRemDestTable:initMobilityUser: -- > created mobility > user|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > 11/01/2013 15:38:14.872 *CCM|DbMobility - User dump: userId = SiteB2*, > isIVREnabled = 1, maxDeskPickupWaitTime = > 10000|<CLID::StandAloneCluster><NID::142.100.64.11><LVL::Detailed><MASK::ffffff> > ... > ... > > 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)* > |<CLID::StandAloneCluster><NID::142.100.64.11><CT::1,100,37,1.3275><IP::142.100.64.254><DEV::SEPA8B1D4FBEEF0><LVL::Arbitrary><MASK::0800> > 11/01/2013 15:45:23.904 CCM|ConnectionManager - storeMediaInfo(30376367): > ADD NEW ENTRY, > size=1|<CLID::StandAloneCluster><NID::142.100.64.11><CT::1,100,37,1.3275><IP::142.100.64.254><DEV::SEPA8B1D4FBEEF0><LVL::Arbitrary><MASK::0800> > 11/01/2013 15:45:23.904 CCM|ConnectionManager - storeMediaInfo(30376369): > ADD NEW ENTRY, > size=2|<CLID::StandAloneCluster><NID::142.100.64.11><CT::1,100,37,1.3275><IP::142.100.64.254><DEV::SEPA8B1D4FBEEF0><LVL::Arbitrary><MASK::0800> > ... > ... > 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),FS(0,0) IpAddrMode(0 0) aPid(1, 152, 44), > bPid(1, 38, > 6)|<CLID::StandAloneCluster><NID::142.100.64.11><CT::1,100,37,1.3275><IP::142.100.64.254><DEV::SEPA8B1D4FBEEF0><LVL::Significant><MASK::0800> > > > I found out also that if an appropriate MTP/Xcoder is not available, the > call will fail. > > ... > ... > 11/01/2013 15:45:23.905 CCM|MediaManager(45)::*sendMTPXcoderAllocationRequest, > allocate MTP(ci=30376371)*, suppressMatchCap=0, > mrgl=f2590a96-7e9c-b104-8660-781ca3dcc16a > DTMF=0|<CLID::StandAloneCluster><NID::142.100.64.11><CT::1,100,37,1.3275><IP::142.100.64.254><DEV::SEPA8B1D4FBEEF0><LVL::Significant><MASK::0800> > ... > ... > 11/01/2013 15:45:23.906 CCM|MRM::*waiting_AllocateMtpResourceErr - ERROR > - no resources are available -- ci = 30376371* > |<CLID::StandAloneCluster><NID::142.100.64.11><CT::1,100,37,1.3275><IP::142.100.64.254><DEV::SEPA8B1D4FBEEF0><LVL::Error><MASK::8000> > ... > ... > > > Regards, > --Somphol. > > > > > On Wed, Nov 6, 2013 at 11:30 PM, StefanoS <stefan...@gmail.com> wrote: > >> 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 >> > >
_______________________________________________ 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
