Re: [OSL | CCIE_Voice] SRST display problem

Mon, 26 Jul 2010 15:09:00 -0700

Hi Kevin,

That will work perfectly fine provided you apply correct rules under correct dialpeers.
But that would be too much work.

I was just thinking that you don't  have to create different dial peers. You can manipulate ANI etc using the one dial peer 9[2-9] whatever and then applying a translation rule which takes care of both SRST and normal condition based on calling number. For e.g.

Dialing 911 for Site B requirement is different in SRST and Normal mode.

Normal mode requirement is 10-digit ANI like 6178631001

SRST requirement is 7-digit ANI like 8631001

I would prefer the following approach:

voice translation-rule 2
 rule 1 /^1...$/ /863\0/ type any Sub plan any isdn    ** SRST **
 rule 2 /^1\(6178631...$\)/ /\1/ type any nat plan any isdn  **Normal**
!

voice translation-rule 5
rule 1 // // type any unknown plan any isdn

voice translation-profile pstn-em
translate calling 2
translate called 5

dial-peer voice 2 pots
translation-profile outgoing pstn-em
destination-pattern 911
no digit-strip
port 0/0/0:23


Note: At call manaher, check this:
Calling Party Transformations

Ash>


Kevin Damisch wrote:

Thinking outside the box and bringing up an old thread.  Would this work for calls to an H323 site that needs different name/number requirements between normal and SRST modes?

 

·         In ccmadmin, strip predot to get rid of the 9 and prefix 8 on the 9. route patterns.

·         On the H323 gateway, create 2 sets of dials peers.  For example, one set has a destination pattern of 9[2-9]……. for SRST calling.  The other has 8[2-9]…… for the destination-patterns that would be used for normal mode call.

·         Create 2 sets of translation rules and profiles that get applied to these dial peers if needed.  The ones with 9 would apply certain requirements and the ones with 8 would apply a different set of requirements.

·         In normal mode, the phones would dial 9 555 1212, match the 9.[2-9]XXXXXX route pattern, strip the 9 and prefix an 8 instead.  The H323 gateway receives 85551212 and uses the 8[2-9]…… dial peer to send name and number.

·         In SRST mode, the phones would still dial 9 555 1212, match the 9[2-9]…… dial peer that would have the clid strip name on it so it would only send the number, not the name.

 

I haven’t tested this yet so I have no idea if this actually works.  But in theory, I think it would.  Just make sure you set the correct rules in the translation rules and apply the translation-profiles to the correct dial peers.

 

Anyone agree or disagree?

 

Thanks,

Kevin

 

From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Angel Perez
Sent: Tuesday, March 23, 2010 3:35 AM
To: siddas...@gmail.com; mjbe...@krollontrack.com
Cc: osl osl
Subject: Re: [OSL | CCIE_Voice] SRST display problem

 

Hi:
 
If call-manager-fallback is not a requirement, you can use telephony-service in srts mode:
 
telephony-service
ip source-address
max-dn
max-ephone
srst mode auto provision all

 
Wait until ephones get registered to srst the first time, then you will see ephones config below telephony-serv configuration, change the ephone-dn's line description for example:
 
ephone-dn 1
description br1-ph1
 
ephone 1
reset  
 
This will take some time becouse the ephone would try to register to its primary, secondary and then srst. You can also no shut the serial interface wait until phones register to ccm and then shut it again to force ephones to register to srts gw (this may take less time if you have configured switchback immediate at the gw and connection monitor duration 30 sec in device pool)
 
hth
 


Date: Mon, 22 Mar 2010 23:09:27 +0000
From: siddas...@gmail.com
To: mjbe...@krollontrack.com
CC: ccie_voice@onlinestudylist.com
Subject: Re: [OSL | CCIE_Voice] SRST display problem

Berry,

Thanks for your feedback.

Actually I cannot change the display as it will have to remain as +1617863XXXX on CUCM external phone number mask (are you talking about this?) when in normal mode. The problem comes in SRST as I want only the number to appear at PSTN phone and not this whole +16178631001.

Someone suggested to use clid strip name on the dial-peer which works perfectly fine and I am getting the desired results but on a H323 gateway this clid command is also stripping name when in normal mode which is not desired. How can we manipulate settings so that this name is restricted in SRST but not in normal mode. There is no issue for an MGCP gateway but how we can do this on an H323 gateway?

Anyone came across this issue?

Ash>

On 22/03/2010 21:09, Berry, Matthew J. wrote:

Ashar –

 

You need to change the display name on your ephone.  The “+617….” Is in the place where you’d normally put the caller ID. 

 

Your are displaying the digits correctly.  You just need to change the CID.

 

From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Ashar
Sent: Sunday, March 21, 2010 10:54 AM
To: CCIE Voice OSL (ccie_voice@onlinestudylist.com)
Subject: [OSL | CCIE_Voice] SRST display problem

 

Hello,

I am having some issues in displaying the number on PSTN phone while in SRST mode. I only want the calling number to get displayed on PSTN phone but I am getting a number with + and then number again in brackets for e.g. it display this on PSTN phone > From +16178631001 (6178631001) while I want it to display like From 6178631001.


Please see the debug:

Mar 21 19:34:04.775: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x1, Calling num 6178631001
Mar 21 19:34:04.775: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x0094 callID = 0x8015 switch = primary-ni interface = User
Mar 21 19:34:04.779: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0094
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Progress Ind i = 0x8183 - Origination address is non-ISDN
 
        Display i = '+16178631001'
        Calling Party Number i = 0x0180, '6178631001'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0xA1, '12123945001'
                Plan:ISDN, Type:National
Mar 21 19:34:04.811: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8094
        Channel ID i = 0xA98381
                Exclusive, Channel 1
Mar 21 19:34:04.871: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x8094
        Progress Ind i = 0x8088 - In-band info or appropriate now available
 --More--
Mar 21 19:34:08.819: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x0094
        Cause i = 0x8090 - Normal call clearing
Mar 21 19:34:08.831: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x8094
Mar 21 19:34:08.835: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x0094
         
I am not sure but that Display bit in red above might be the problem. I am using following telephony-service commands:

telephony-service
 srst mode auto-provision none
srst dn line-mode dual
 max-ephones 5
 max-dn 5
 ip source-address 10.10.201.1 port 2000
 max-redirect 10
 voicemail 912123945220
 max-conferences 2 gain -6
 moh music-on-hold.au
 transfer-system full-consult
 transfer-pattern .T
 secondary-dialtone 9
 create cnf-files

Is there a way to get rid of that display thing? Does it depend on PSTN configuration?
Any help would be much appreciated.

-- 
Thanks,
Ashar Siddiqui

 

-- 
Thanks,
Ashar Siddiqui

 

Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.



This communication (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Vital Support Systems at 515 334 5700 and delete or destroy all copies and the original document.
 




_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to