[OSL | CCIE_Voice] Invitation to use Google Talk
--- You've been invited by antik kuntik to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/invite/ANGjdJ9d3xlsisq6kWBb4bIsI-b22i_6q0KobCGVpCvVFkfpRaiBkNtMLuafmu-5QVAKf9JczyYO2pI_MhFb To sign up for a Google account and get started with Google Talk, you can visit: http://mail.google.com/mail/invite/ANGjdJ_tziKWb3zBimzZVClNJNOz8fF1Ib-VTvAwY7E6DJ4F2DKmd6UzuzSkRwcwAIL6DzyL-tkR0si8zEra?pc=en-rf---a Learn more at: http://www.google.com/intl/en/landing/accounts/ Thanks, The Google Team ___ 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
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
