Re: [OSL | CCIE_Voice] MVA the right way to configure it
Why I am getting 0% in Voice Gateway and Signalling for the 6th time, 100% tested and worked, what is the trick ? Regards, On Fri, Sep 27, 2013 at 4:29 PM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys, Thanks once again for your replies. @Lakshmish using your method of creating a seperate partition for RDP ( on the left side) and not having the SB PH1 have access to it . I noticed that when a call is made from PSTN ( with calling number 525) to 3300 and if we enter the pin and dial a number say 2001 ( internal) . The 2001 phone rings and the call can be answered. However the SBPH1 ( physical phone) is unable show that the 3001 line is active by showing a red light and therefore this does not appear to the requirement for MVA is achieved . What do you think? -MJ On Fri, Sep 27, 2013 at 2:11 AM, Lakshmish NS lakshmish...@gmail.comwrote: Hi MJ, Martin is right, I had issues with SNR after configuring the RD to 7 digits and setting the service parameter to complete match, MVA and SNR wouldn't go together. Martin however has proposed a new fix, you could try it. The workaround I used for this was to create an Application Dial Rule, which would certainly solve the issue. Cheers, Laksh On Tue, Sep 24, 2013 at 8:39 PM, Martin Sloan martinsloa...@gmail.comwrote: Hi MJ, 1) If you set the partial match to 7 digits and then configure your remote destination as a 10 digit number, you'll get a match if the ANI is either 7 or 10 digits since the match rule takes 'X' partial-match digits from the RD starting with the last number (2 in this case) and compares it to the ANI of the calling number, *but* the calling party number must be equal to or shorter in length than the configured remote destination, which is why it's good to just set your RD at 10+ digits if you're using partial match. Here are some scenarios and the outcome for partial match: Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 972525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 525 Result = *Match* * * Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 972525 Result = *No* *Match (ANI is longer than RD)* When using Complete match, the ANI and RD have to be exactly the same. I like to make a call into SB from the PSTN phone prior to configuring SNR and I can quickly see what the ANI is, which is what I then make my RD. I had mentioned some buggy behavior with SNR though I never spent time working with partial match since when I heard about that issue I just stuck with complete match but I wanted to test my info above to make sure I wasn't sending incorrect info. It wasn't too hard to run into this buggy behavior. I found a workaround as well so I thought I'd share. When changing the Complete Match service parameter to Partial Match you get a screen pop that says to remember and set the Number of Digits for Caller ID Partial Match service parameter. The default for that parameter is 10 and the bug that I found is that on the initial change from default 10 to 7, the new setting does not take effect. After changing from 10-7 I started to make test calls and my CLID to SB PH1 was showing as the 7 digit ANI of the PSTN phone and not SB PHONE 2 3002 like it should. I dug around for a bit and tweaked a couple parameters and re-tested. The deal is that you have change Complete Match to Partial Match - Save then change Partial Match digits from 10 to 7 and Save again. 2) For this one if your service parameter is set to Complete Match and your ANI is 7 digits, just set your RD to the 7 digit number then use route patterns/xlations to manipulate as needed. 3) Not sure about that one. I've definitely seen conflicting information on certain things but I've realized that some of the training material is years in the making and when things are discovered or updated, maybe the old information is not or it's just floating out there. I can confirm that based on some recent experience with trusted trainers it was reiterated not to use partial match, maybe in part because of the issue that I hit today. Marty On Tue, Sep 24, 2013 at 8:19 AM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys , Thanks a lot for taking time out to reply to my question. It was really helpful. I was trying to understand the difference between full match with 10 digits and partial match with 7 digits. Here are my scenarios... 1) If I use partial match with 7 digits then this will satisfy the condition where my calling number is 7 digits ( in this
Re: [OSL | CCIE_Voice] MVA the right way to configure it
Can you past your config here to see what you did? Sent from my iPhone On Sep 28, 2013, at 11:40 AM, Bashar Aziz bashar1a...@gmail.com wrote: Why I am getting 0% in Voice Gateway and Signalling for the 6th time, 100% tested and worked, what is the trick ? Regards, On Fri, Sep 27, 2013 at 4:29 PM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys, Thanks once again for your replies. @Lakshmish using your method of creating a seperate partition for RDP ( on the left side) and not having the SB PH1 have access to it . I noticed that when a call is made from PSTN ( with calling number 525) to 3300 and if we enter the pin and dial a number say 2001 ( internal) . The 2001 phone rings and the call can be answered. However the SBPH1 ( physical phone) is unable show that the 3001 line is active by showing a red light and therefore this does not appear to the requirement for MVA is achieved . What do you think? -MJ On Fri, Sep 27, 2013 at 2:11 AM, Lakshmish NS lakshmish...@gmail.com wrote: Hi MJ, Martin is right, I had issues with SNR after configuring the RD to 7 digits and setting the service parameter to complete match, MVA and SNR wouldn't go together. Martin however has proposed a new fix, you could try it. The workaround I used for this was to create an Application Dial Rule, which would certainly solve the issue. Cheers, Laksh On Tue, Sep 24, 2013 at 8:39 PM, Martin Sloan martinsloa...@gmail.com wrote: Hi MJ, 1) If you set the partial match to 7 digits and then configure your remote destination as a 10 digit number, you'll get a match if the ANI is either 7 or 10 digits since the match rule takes 'X' partial-match digits from the RD starting with the last number (2 in this case) and compares it to the ANI of the calling number, but the calling party number must be equal to or shorter in length than the configured remote destination, which is why it's good to just set your RD at 10+ digits if you're using partial match. Here are some scenarios and the outcome for partial match: Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 525 Result = Match Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 972525 Result = Match Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 525 Result = Match Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 972525 Result = No Match (ANI is longer than RD) When using Complete match, the ANI and RD have to be exactly the same. I like to make a call into SB from the PSTN phone prior to configuring SNR and I can quickly see what the ANI is, which is what I then make my RD. I had mentioned some buggy behavior with SNR though I never spent time working with partial match since when I heard about that issue I just stuck with complete match but I wanted to test my info above to make sure I wasn't sending incorrect info. It wasn't too hard to run into this buggy behavior. I found a workaround as well so I thought I'd share. When changing the Complete Match service parameter to Partial Match you get a screen pop that says to remember and set the Number of Digits for Caller ID Partial Match service parameter. The default for that parameter is 10 and the bug that I found is that on the initial change from default 10 to 7, the new setting does not take effect. After changing from 10-7 I started to make test calls and my CLID to SB PH1 was showing as the 7 digit ANI of the PSTN phone and not SB PHONE 2 3002 like it should. I dug around for a bit and tweaked a couple parameters and re-tested. The deal is that you have change Complete Match to Partial Match - Save then change Partial Match digits from 10 to 7 and Save again. 2) For this one if your service parameter is set to Complete Match and your ANI is 7 digits, just set your RD to the 7 digit number then use route patterns/xlations to manipulate as needed. 3) Not sure about that one. I've definitely seen conflicting information on certain things but I've realized that some of the training material is years in the making and when things are discovered or updated, maybe the old information is not or it's just floating out there. I can confirm that based on some recent experience with trusted trainers it was reiterated not to use partial match, maybe in part because of the issue that I hit today. Marty On Tue, Sep 24, 2013 at 8:19 AM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys , Thanks a lot for taking time out to reply to my question. It was really helpful. I was trying to understand the difference between full match
Re: [OSL | CCIE_Voice] MVA the right way to configure it
Hi Guys, Thanks once again for your replies. @Lakshmish using your method of creating a seperate partition for RDP ( on the left side) and not having the SB PH1 have access to it . I noticed that when a call is made from PSTN ( with calling number 525) to 3300 and if we enter the pin and dial a number say 2001 ( internal) . The 2001 phone rings and the call can be answered. However the SBPH1 ( physical phone) is unable show that the 3001 line is active by showing a red light and therefore this does not appear to the requirement for MVA is achieved . What do you think? -MJ On Fri, Sep 27, 2013 at 2:11 AM, Lakshmish NS lakshmish...@gmail.comwrote: Hi MJ, Martin is right, I had issues with SNR after configuring the RD to 7 digits and setting the service parameter to complete match, MVA and SNR wouldn't go together. Martin however has proposed a new fix, you could try it. The workaround I used for this was to create an Application Dial Rule, which would certainly solve the issue. Cheers, Laksh On Tue, Sep 24, 2013 at 8:39 PM, Martin Sloan martinsloa...@gmail.comwrote: Hi MJ, 1) If you set the partial match to 7 digits and then configure your remote destination as a 10 digit number, you'll get a match if the ANI is either 7 or 10 digits since the match rule takes 'X' partial-match digits from the RD starting with the last number (2 in this case) and compares it to the ANI of the calling number, *but* the calling party number must be equal to or shorter in length than the configured remote destination, which is why it's good to just set your RD at 10+ digits if you're using partial match. Here are some scenarios and the outcome for partial match: Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 972525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 525 Result = *Match* * * Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 972525 Result = *No* *Match (ANI is longer than RD)* When using Complete match, the ANI and RD have to be exactly the same. I like to make a call into SB from the PSTN phone prior to configuring SNR and I can quickly see what the ANI is, which is what I then make my RD. I had mentioned some buggy behavior with SNR though I never spent time working with partial match since when I heard about that issue I just stuck with complete match but I wanted to test my info above to make sure I wasn't sending incorrect info. It wasn't too hard to run into this buggy behavior. I found a workaround as well so I thought I'd share. When changing the Complete Match service parameter to Partial Match you get a screen pop that says to remember and set the Number of Digits for Caller ID Partial Match service parameter. The default for that parameter is 10 and the bug that I found is that on the initial change from default 10 to 7, the new setting does not take effect. After changing from 10-7 I started to make test calls and my CLID to SB PH1 was showing as the 7 digit ANI of the PSTN phone and not SB PHONE 2 3002 like it should. I dug around for a bit and tweaked a couple parameters and re-tested. The deal is that you have change Complete Match to Partial Match - Save then change Partial Match digits from 10 to 7 and Save again. 2) For this one if your service parameter is set to Complete Match and your ANI is 7 digits, just set your RD to the 7 digit number then use route patterns/xlations to manipulate as needed. 3) Not sure about that one. I've definitely seen conflicting information on certain things but I've realized that some of the training material is years in the making and when things are discovered or updated, maybe the old information is not or it's just floating out there. I can confirm that based on some recent experience with trusted trainers it was reiterated not to use partial match, maybe in part because of the issue that I hit today. Marty On Tue, Sep 24, 2013 at 8:19 AM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys , Thanks a lot for taking time out to reply to my question. It was really helpful. I was trying to understand the difference between full match with 10 digits and partial match with 7 digits. Here are my scenarios... 1) If I use partial match with 7 digits then this will satisfy the condition where my calling number is 7 digits ( in this instance it is 525) but what happens if my calling number is in the form 972525 in this case it is 10 digits whereas my service parameter indicates just 7 digits ? 2) If I use complete match with 10 digits then will
Re: [OSL | CCIE_Voice] MVA the right way to configure it
Hi MJ, Martin is right, I had issues with SNR after configuring the RD to 7 digits and setting the service parameter to complete match, MVA and SNR wouldn't go together. Martin however has proposed a new fix, you could try it. The workaround I used for this was to create an Application Dial Rule, which would certainly solve the issue. Cheers, Laksh On Tue, Sep 24, 2013 at 8:39 PM, Martin Sloan martinsloa...@gmail.comwrote: Hi MJ, 1) If you set the partial match to 7 digits and then configure your remote destination as a 10 digit number, you'll get a match if the ANI is either 7 or 10 digits since the match rule takes 'X' partial-match digits from the RD starting with the last number (2 in this case) and compares it to the ANI of the calling number, *but* the calling party number must be equal to or shorter in length than the configured remote destination, which is why it's good to just set your RD at 10+ digits if you're using partial match. Here are some scenarios and the outcome for partial match: Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 972525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 525 Result = *Match* * * Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 972525 Result = *No* *Match (ANI is longer than RD)* When using Complete match, the ANI and RD have to be exactly the same. I like to make a call into SB from the PSTN phone prior to configuring SNR and I can quickly see what the ANI is, which is what I then make my RD. I had mentioned some buggy behavior with SNR though I never spent time working with partial match since when I heard about that issue I just stuck with complete match but I wanted to test my info above to make sure I wasn't sending incorrect info. It wasn't too hard to run into this buggy behavior. I found a workaround as well so I thought I'd share. When changing the Complete Match service parameter to Partial Match you get a screen pop that says to remember and set the Number of Digits for Caller ID Partial Match service parameter. The default for that parameter is 10 and the bug that I found is that on the initial change from default 10 to 7, the new setting does not take effect. After changing from 10-7 I started to make test calls and my CLID to SB PH1 was showing as the 7 digit ANI of the PSTN phone and not SB PHONE 2 3002 like it should. I dug around for a bit and tweaked a couple parameters and re-tested. The deal is that you have change Complete Match to Partial Match - Save then change Partial Match digits from 10 to 7 and Save again. 2) For this one if your service parameter is set to Complete Match and your ANI is 7 digits, just set your RD to the 7 digit number then use route patterns/xlations to manipulate as needed. 3) Not sure about that one. I've definitely seen conflicting information on certain things but I've realized that some of the training material is years in the making and when things are discovered or updated, maybe the old information is not or it's just floating out there. I can confirm that based on some recent experience with trusted trainers it was reiterated not to use partial match, maybe in part because of the issue that I hit today. Marty On Tue, Sep 24, 2013 at 8:19 AM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys , Thanks a lot for taking time out to reply to my question. It was really helpful. I was trying to understand the difference between full match with 10 digits and partial match with 7 digits. Here are my scenarios... 1) If I use partial match with 7 digits then this will satisfy the condition where my calling number is 7 digits ( in this instance it is 525) but what happens if my calling number is in the form 972525 in this case it is 10 digits whereas my service parameter indicates just 7 digits ? 2) If I use complete match with 10 digits then will satisfy the condition where my calling number is 10 digits but not when 7 digits . I am not sure where complete match means it includes the condition of the calling number with 7 digits as well. Would you be able to throw some light on this? 3)In some of the IPexpert walk through videos I see the instructor seems to prefer partial match with 7 digits . However this may be for a specific condition. I am I correct on this ? MJ On Wed, Sep 18, 2013 at 8:55 PM, Martin Sloan martinsloa...@gmail.comwrote: Hi MJ, I did some research on this since I've been configuring MVA for a while but have had some questions about underlying architecture. Here's some responses
Re: [OSL | CCIE_Voice] MVA the right way to configure it
Hi Guys , Thanks a lot for taking time out to reply to my question. It was really helpful. I was trying to understand the difference between full match with 10 digits and partial match with 7 digits. Here are my scenarios... 1) If I use partial match with 7 digits then this will satisfy the condition where my calling number is 7 digits ( in this instance it is 525) but what happens if my calling number is in the form 972525 in this case it is 10 digits whereas my service parameter indicates just 7 digits ? 2) If I use complete match with 10 digits then will satisfy the condition where my calling number is 10 digits but not when 7 digits . I am not sure where complete match means it includes the condition of the calling number with 7 digits as well. Would you be able to throw some light on this? 3)In some of the IPexpert walk through videos I see the instructor seems to prefer partial match with 7 digits . However this may be for a specific condition. I am I correct on this ? MJ On Wed, Sep 18, 2013 at 8:55 PM, Martin Sloan martinsloa...@gmail.comwrote: Hi MJ, I did some research on this since I've been configuring MVA for a while but have had some questions about underlying architecture. Here's some responses to your info plus some of my findings. 1) If the MVA DID is in line with your standard DID range for the site, why not just piggy back on the existing CUCM dial-peers instead of creating a new one just for MVA. Say Site B for example with a 3XXX extension range, you could use the CUCM dial-peer: dial-peer voice 3000 voip destination pattern 3...$ session target ipv4:10.10.210.11 no vad voice-class codec 1 voice-class h323 1 dtmf-relay h245-alpha incoming called-number . 2) Looks good. I change my service name to MVA since I think there's a typo somewhere in the CUCM pages where I copy/paste from but as long as the names match up between the service and dial-peer, no worries. 3) Right, I use the same to chop DID's to local extensions: voice translation-rule 1 rule 1 /.+\(\)/ /\1/ voice translation-profile PSTN translate called 1 voice-port 0/0/0:23 translation-prof in PSTN 4) Here, I do not use partial match. I've heard from a truly reliable source that there is some buggi-ness with this particular version of CUCM and partial matches. In the end, I think it's less thinking and moving parts if you just use a full match anyway. Just my POV on this one. Also, the 'Mobile Voice Access Number' in the CCM service parameters isn't used for VXML MVA. From what I understand, this parameter is for Mobile Communicator. I've been through the SRND and several other pages and cannot pin the exact meaning of the parameter, but in the SRND configuration guide for VXML MVA, it cruises right over this parameter so I believe it's safe to leave at default (blank). 5) I've never had a specific requirement for this. I'd say don't waste the time setting it up if it's not required but if anyone has good reason to think it should be configured, lemme know. 6) Agreed 7) Be sure to set the re-routing CSS on the RDP (if SNR is required). CSS = MVA dialing Rerouting CSS = SNR dialing Also, just as a heads up you shouldn't use SLRL for SNR as it will use the RG of the calling party (say HQ phone 2) so the call would try to go out HQ GW. Make sure to create a route list for SB (if SNR is at site B) and point the SNR pattern to it so it goes out the SB gateway as a local call. 8) I use the full number here. 9) I never set this and have not had any issues with MVA/SNR. The CUCM help file says its for CDR usage. Anyone know how/if this setting impacts MVA/SNR? 10) Agreed About your questions, I'm not clear on #1. Like I mentioned, I use full match and don't do any manipulation of the calling number for SNR/MVA questions. For #2, you haven't mentioned the Media Resources-Mobile Voice Access-Mobile Voice Access Directory Number. Unlike the Service Parameter Setting, this is the number that's used for calls from the H323 GW to CUCM. Here are some debugs from a call into MVA from my lab. The process is that the CUCM instructs the GW to play prompts and collect digits based on the DTMF input from the caller. The call was placed from my configured Remote Destination so I'm not prompted to enter my RD Number: ---GET PIN Here the gateway prompts to enter my pin to authenticate vxml version=2.0 form id=Pin grammar type=application/grammar+regex./grammar field name=pin type=digits?minlength=1;maxlength=20 prompt audio s ---GET FUNCTION Here the GW asks what I'd like to do (Press 1 to place a call) vxml version=2.0 form id=GetFunctionSel grammar type=application/grammar+regex./grammar field name=funcsel type=digits?length=1 pro ---GET DIALED DIGITS
Re: [OSL | CCIE_Voice] MVA the right way to configure it
Hi MJ, 1) If you set the partial match to 7 digits and then configure your remote destination as a 10 digit number, you'll get a match if the ANI is either 7 or 10 digits since the match rule takes 'X' partial-match digits from the RD starting with the last number (2 in this case) and compares it to the ANI of the calling number, *but* the calling party number must be equal to or shorter in length than the configured remote destination, which is why it's good to just set your RD at 10+ digits if you're using partial match. Here are some scenarios and the outcome for partial match: Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 972525 Calling Party Number = 972525 Result = *Match* Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 525 Result = *Match* * * Partial Match = True Number of Digits For Match = 7 digits Remote Destination = 525 Calling Party Number = 972525 Result = *No* *Match (ANI is longer than RD)* When using Complete match, the ANI and RD have to be exactly the same. I like to make a call into SB from the PSTN phone prior to configuring SNR and I can quickly see what the ANI is, which is what I then make my RD. I had mentioned some buggy behavior with SNR though I never spent time working with partial match since when I heard about that issue I just stuck with complete match but I wanted to test my info above to make sure I wasn't sending incorrect info. It wasn't too hard to run into this buggy behavior. I found a workaround as well so I thought I'd share. When changing the Complete Match service parameter to Partial Match you get a screen pop that says to remember and set the Number of Digits for Caller ID Partial Match service parameter. The default for that parameter is 10 and the bug that I found is that on the initial change from default 10 to 7, the new setting does not take effect. After changing from 10-7 I started to make test calls and my CLID to SB PH1 was showing as the 7 digit ANI of the PSTN phone and not SB PHONE 2 3002 like it should. I dug around for a bit and tweaked a couple parameters and re-tested. The deal is that you have change Complete Match to Partial Match - Save then change Partial Match digits from 10 to 7 and Save again. 2) For this one if your service parameter is set to Complete Match and your ANI is 7 digits, just set your RD to the 7 digit number then use route patterns/xlations to manipulate as needed. 3) Not sure about that one. I've definitely seen conflicting information on certain things but I've realized that some of the training material is years in the making and when things are discovered or updated, maybe the old information is not or it's just floating out there. I can confirm that based on some recent experience with trusted trainers it was reiterated not to use partial match, maybe in part because of the issue that I hit today. Marty On Tue, Sep 24, 2013 at 8:19 AM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys , Thanks a lot for taking time out to reply to my question. It was really helpful. I was trying to understand the difference between full match with 10 digits and partial match with 7 digits. Here are my scenarios... 1) If I use partial match with 7 digits then this will satisfy the condition where my calling number is 7 digits ( in this instance it is 525) but what happens if my calling number is in the form 972525 in this case it is 10 digits whereas my service parameter indicates just 7 digits ? 2) If I use complete match with 10 digits then will satisfy the condition where my calling number is 10 digits but not when 7 digits . I am not sure where complete match means it includes the condition of the calling number with 7 digits as well. Would you be able to throw some light on this? 3)In some of the IPexpert walk through videos I see the instructor seems to prefer partial match with 7 digits . However this may be for a specific condition. I am I correct on this ? MJ On Wed, Sep 18, 2013 at 8:55 PM, Martin Sloan martinsloa...@gmail.comwrote: Hi MJ, I did some research on this since I've been configuring MVA for a while but have had some questions about underlying architecture. Here's some responses to your info plus some of my findings. 1) If the MVA DID is in line with your standard DID range for the site, why not just piggy back on the existing CUCM dial-peers instead of creating a new one just for MVA. Say Site B for example with a 3XXX extension range, you could use the CUCM dial-peer: dial-peer voice 3000 voip destination pattern 3...$ session target ipv4:10.10.210.11 no vad voice-class codec 1 voice-class h323 1 dtmf-relay h245-alpha incoming
Re: [OSL | CCIE_Voice] MVA the right way to configure it
Hi, OR You could assign a different partition to the line that you associate with remote destination profile. While configuring RDP, the line extension (Towards left, the partition option is only available after saving the RDP config) that you see is different from the line that's associated with the phone.The extension that's associated to the MAC address (IP Phone) is different than the the extension that's associated to the RDP. So, assigning a different partition to the RDP line eliminates the busy trigger problem as the phone cannot access RDP line at all. Hope you got it. Cheers, Laksh On Wed, Sep 18, 2013 at 9:55 AM, sanity insanity networksanitytoinsan...@gmail.com wrote: Hi Guys, I have been trying to find the right way of configuring MVA. Below is my configuration Details: = My config is following 1) The dial-peers are set in the following way dial-peer voice 102 voip preference 2 destination-pattern 3300 session target ipv4:ip address of the CUCM Pub dtmf-relay h245-alphanumeric codec g711ulaw no vad ! dial-peer voice 3300 pots service cmm incoming called-number 3300 no digit-strip 2) here is the MVA service url ! application service cmm http://ip address of the CUCM Pub:8080/ccmivr/pages/IVRMainpage.vxml ! 3) I am stripping 3033300 coming from pstn to last 4 digits using a translation-rule on the voice-port level . That is 3033300 becomes 3300 when it reaches CUCM. 4) On CUCM in the service parameters... Enable Mobile Voice access is set to True Mobile voice access number is 3300 Matching caller id with Remote Destination is Partial Match Number of digits of Caller ID Partial Match is 7 5) The Mobility softkey has been added for on hold and connected at the softkey template level and applied to the phone ( SB PH1) 6)At the User SB phone 1 I have enabled Enable Mobility and Enable Mobile Voice Access also selected the MAC address of the phone 7) Created a Remote Dest profile and selected user id of sb ph1 and the correct calling search space for the phone 8) Added a Remoted Destination number of 525 9) Also went to device phone and selected the Owner User ID of SB Ph1 10) Cisco Unified Mobile Voice Access Service is running on both Sub and Pub on CUCM Questions : 1) Do I need to change my incoming calling number (coming from pstn) from 525 to 9525 because the busy trigger on 3001 (phone) is set to 1 and therefore any other calling coming to this number will head to Voicemail? 2) Anything else you find incorrect with my configuration? -MJ ___ 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
[OSL | CCIE_Voice] MVA the right way to configure it
Hi Guys, I have been trying to find the right way of configuring MVA. Below is my configuration Details: = My config is following 1) The dial-peers are set in the following way dial-peer voice 102 voip preference 2 destination-pattern 3300 session target ipv4:ip address of the CUCM Pub dtmf-relay h245-alphanumeric codec g711ulaw no vad ! dial-peer voice 3300 pots service cmm incoming called-number 3300 no digit-strip 2) here is the MVA service url ! application service cmm http://ip address of the CUCM Pub:8080/ccmivr/pages/IVRMainpage.vxml ! 3) I am stripping 3033300 coming from pstn to last 4 digits using a translation-rule on the voice-port level . That is 3033300 becomes 3300 when it reaches CUCM. 4) On CUCM in the service parameters... Enable Mobile Voice access is set to True Mobile voice access number is 3300 Matching caller id with Remote Destination is Partial Match Number of digits of Caller ID Partial Match is 7 5) The Mobility softkey has been added for on hold and connected at the softkey template level and applied to the phone ( SB PH1) 6)At the User SB phone 1 I have enabled Enable Mobility and Enable Mobile Voice Access also selected the MAC address of the phone 7) Created a Remote Dest profile and selected user id of sb ph1 and the correct calling search space for the phone 8) Added a Remoted Destination number of 525 9) Also went to device phone and selected the Owner User ID of SB Ph1 10) Cisco Unified Mobile Voice Access Service is running on both Sub and Pub on CUCM Questions : 1) Do I need to change my incoming calling number (coming from pstn) from 525 to 9525 because the busy trigger on 3001 (phone) is set to 1 and therefore any other calling coming to this number will head to Voicemail? 2) Anything else you find incorrect with my configuration? -MJ ___ 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
