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 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 > 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 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 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 > 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
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 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 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 tryin
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 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 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 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
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 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 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 wrote: >> >>> Hi MJ, >>> >>> I did some research on this since I've been
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 wrote: > >> 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 h3
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 wrote:
> 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
>
>
>
>
>
>
>
>
>
> .
>
>
>
>
>
> ---GET FUNCTION
>
> Here the GW asks what I'd like to do ("Press 1 to place a call")
>
>
>
>
>
>
>
> .
>
>
>
>
>
> ---GET DIALED DIGITS
>
> Here the GW plays the prompt to enter the digits followed by pound
>
>
>
>
>
>
>
>
> .
>
>
>
>
>
> ---TRANSFER CALL
>
> Here is wher
Re: [OSL | CCIE_Voice] MVA the right way to configure it
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 . . . ---TRANSFER CALL Here is where the gateway hands the call to CUCM. MVA section cisco-ani="phone://4088397263" ANI AKA Remote Destination number cisco-rdn="phone://2002" << My dialed digits cisco-rdntype="0" cisco-rdnp So the lesson for me was the the Media Resource->MVA Dir Num does not have to match up with the actual MVA DID whatsoever. The requirement is that the H323 GW has a dial-peer with a destination-pattern that matches the number provided by CUCM to the GW in the dest="phone://3300" field and also that the H323 GW CSS within CUCM has access to the PT that the MVA Dirn was assigned to. In the case of using the existing CUCM outbound dial-peer from above, it's a match. Here's an example of a failed transfer: ---FAILED TRANSFER MVA and the call failed. But, after I copied my CUCM dial-peer on the GW and changed the destination-pattern to 33$, it worked. I hope this helps, and thanks for prompting me to stop procrastinating on researching MVA! Marty On Wed, Sep 18, 2013 at 12:25 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: dtmf-rel
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: 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:// 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
