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 5252222) 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 = 9725252222
>>> Calling Party Number = 5252222
>>> Result = *Match*
>>>
>>> Partial Match = True
>>> Number of Digits For Match = 7 digits
>>> Remote Destination = 9725252222
>>> Calling Party Number = 9725252222
>>> Result = *Match*
>>>
>>> Partial Match = True
>>> Number of Digits For Match = 7 digits
>>> Remote Destination = 5252222
>>> Calling Party Number = 5252222
>>> Result = *Match*
>>> *
>>> *
>>> Partial Match = True
>>> Number of Digits For Match = 7 digits
>>> Remote Destination = 5252222
>>> Calling Party Number = 9725252222
>>> 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
>>>> 5252222) but what happens if my calling
>>>> number is in the form 9725252222 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.com>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
>>>>>
>>>>> <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------------
>>>>>
>>>>> Here the GW plays the prompt to enter the digits followed by pound
>>>>>
>>>>> <vxml version="2.0">
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <form id="Getdialno">
>>>>>
>>>>> <grammar type="application/grammar+regex">.</grammar>
>>>>> <field name="dialno" type="digits?minlength=1;maxlength=50">
>>>>>
>>>>> <prompt>
>>>>>
>>>>>
>>>>> -------TRANSFER CALL------------
>>>>>
>>>>> Here is where the gateway hands the call to CUCM.
>>>>>
>>>>> <vxml version="2.0">
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <form id="Transfer">
>>>>>
>>>>> <transfer name="mycall"
>>>>> dest="phone://3300" <<<<<<<<<<< This is the number
>>>>> that is set within the CUCM Media Resource->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------------
>>>>>
>>>>> <vxml version="2.0">
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <form id="Transfer">
>>>>>
>>>>> <transfer name="mycall"
>>>>> dest="phone://33"
>>>>> cisco-ani="phone://4088397263"
>>>>> cisco-rdn="phone://2002"
>>>>> cisco-rdntype="0"
>>>>> cisco-rdnpla
>>>>>
>>>>>
>>>>> In this case the 'dest' field was changed to just '33' within CUCM
>>>>> Media Resource->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:<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 5252222
>>>>>>
>>>>>>
>>>>>> 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 5252222 to 95252222 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
>>>
>>
>>
>
> _______________________________________________
> 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
