[OSL | CCIE_Voice] CCIE Collab study group on facebook

2014-05-25 Thread Bashar Aziz
Today I would like to announce publishing a new study group on Facebook,
this group is a closed one, which means that you have to ask a permission
to join and see posts.

It is meant for professionals and experts in CCIE Collaboration field who
preparing for the LAB solution, to join this this group you should meet the
following requirements:

1. Linkedin profile

2. Business email address and website



Regards,
___
Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::

iPexpert on YouTube: www.youtube.com/ipexpertinc

Re: [OSL | CCIE_Voice] MVA the right way to configure it

2013-09-28 Thread Bashar Aziz
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