cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
713
Views
5
Helpful
4
Replies

Not sure if I need a VXML licensing on gateway

jgardner150
Level 4
Level 4

Hello All,

I am in the process of replacing a remote office gateway and have ran into a question on VXML licensing. The current gateway has a configuration that includes some basic cvp applications with a SIP trunk pointed to our CVP servers located in our data center which are on the other side of a WAN connection. I do not see any commands enabling local media caching for prompts so I am questioning if this gateway is even gaining us anything in the current way it is configured. Below are the pieces of the configuration that are specific to the CVP/VXML interactions:


no ip domain lookup
ip domain name xyzcompany
ip host cvp02.ucce.xyzcompany 10.2.175.94
ip host cvp01.ucce.xyzcompany 10.2.175.93
ip host ucmsub01.ucm.xyzcompany 10.2.175.66
ip host ucmsub02.ucm.xyzcompany 10.2.175.67
ip host _sip._udp.cvp.ucce.xyzcompany srv 50 50 5060 cvp01.ucce.xyzcompany
ip host _sip._udp.cvp.ucce.xyzcompany srv 50 50 5060 cvp02.ucce.xyzcompany
ip host _sip._tcp.cvp.ucce.xyzcompany srv 50 50 5060 cvp01.ucce.xyzcompany
ip host _sip._tcp.cvp.ucce.xyzcompany srv 50 50 5060 cvp02.ucce.xyzcompany
ip host _sip._tcp.ucm.xyzcompany srv 50 50 5060 ucmsub01.ucm.xyzcompany
ip host _sip._tcp.ucm.xyzcompany srv 50 50 5060 ucmsub02.ucm.xyzcompany
ip host _sip._udp.ucm.xyzcompany srv 50 50 5060 ucmsub01.ucm.xyzcompany
ip host _sip._udp.ucm.xyzcompany srv 50 50 5060 ucmsub02.ucm.xyzcompany
!
!
application
 service cvp-survivability flash:survivability.tcl
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
 !
 service ringtone flash:ringtone.tcl
  paramspace english language en
  paramspace english index 0
  paramspace english location flash
  paramspace english prefix en
 !
 service cvperror flash:cvperror.tcl
  paramspace english language en
  paramspace english index 0
  paramspace english location flash
  paramspace english prefix en
 !
 service handoff flash:handoff.tcl
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
 !
!
no ip http server
no ip http secure-server
!
dial-peer voice 21 voip
 destination-pattern 4......
 progress_ind setup enable 3
 session protocol sipv2
 session target dns:ucm.xyzcompany
 incoming called-number .
 voice-class codec 1  
 dtmf-relay rtp-nte
 fax-relay ecm disable
 fax rate disable
 fax nsf 000000
 ip qos dscp cs5 media
 ip qos dscp cs3 signaling
 no vad
!
!
dial-peer voice 18224 pots
 description incoming CVP
 service cvp-survivability
 incoming called-number 4308224
 direct-inward-dial
!
dial-peer voice 28224 voip
 description To CVP
 destination-pattern 4308224
 session protocol sipv2
 session target dns:cvp.ucce.xyzcompany
 session transport tcp
 voice-class codec 1  
 voice-class sip rel1xx disable
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 79 voip
 destination-pattern 79.....
 session protocol sipv2
 session target dns:cvp.ucce.xyzcompany
 session transport tcp
 voice-class codec 1  
 voice-class sip rel1xx disable
 dtmf-relay rtp-nte
 no vad
!
!
num-exp 4308224 7999290
gateway 
 media-inactivity-criteria all
 timer receive-rtcp 6
 timer receive-rtp 1200
!
sip-ua 
 no remote-party-id
 retry invite 2
 retry bye 1
 timers expires 60000
 timers buffer-invite 5000
 sip-server dns:cvp.ucce.xyzcompany
 reason-header override
!

 

I would like to know the following:

1. In this gateways current configurations do I require VXML licensing (eg. FL-VXML-12)

2. Since local caching is not enabled is there any advantage to keeping the configuration this way? Alternative would be to route the main local number to CUCM and then to a central VXML/CVP setup from there. 

 

Thanks in advance for any help on this!

1 Accepted Solution

Accepted Solutions

Chintan Gajjar
Level 8
Level 8

Hi,

 

Looking at the configuration, i feel the gateway is acting as only ingress gateway and not VXML gateway as there is no VRU dial-peer  and bootstrap application configured.

you will not need VXML pack as you will be replacing only ingress functionality.

to answer your second question, you need to enable caching only if the solution requires it and only on VXML gateway. as per your configuration i think this VG is functioning as only ingress gateway and VXML functionality must be offloaded to to some other gateway. so configs are correct unless you want to co-reside ingress and VXML on same VG.

 

please see CVP SRND, for the Voice Gateway Deployment model section. you will get some idea on why the configurations are kept in this way.

 

HTH

 

Regards

Chintan

View solution in original post

4 Replies 4

Chintan Gajjar
Level 8
Level 8

Hi,

 

Looking at the configuration, i feel the gateway is acting as only ingress gateway and not VXML gateway as there is no VRU dial-peer  and bootstrap application configured.

you will not need VXML pack as you will be replacing only ingress functionality.

to answer your second question, you need to enable caching only if the solution requires it and only on VXML gateway. as per your configuration i think this VG is functioning as only ingress gateway and VXML functionality must be offloaded to to some other gateway. so configs are correct unless you want to co-reside ingress and VXML on same VG.

 

please see CVP SRND, for the Voice Gateway Deployment model section. you will get some idea on why the configurations are kept in this way.

 

HTH

 

Regards

Chintan

Thanks for the reply Chintan. I did take a look at the SRND and this does help me understand what we are doing with this gateway a bit better. I do have one follow up thought/questions on this...

 

Since this gateway is being used only for ingress PSTN termination and we do have other central VXML gateways is there any reason I need to have it configured in CVP? I am thinking I could reduce the complexity of this configuration by instead routing the incoming calls to a CTI route point on my call manager which is registered to CVP. This is how internal users reach the same call center.

Would I be loosing anything by doing this? (beside maybe cvp survivability, we use SRST anyway...)

Why would you want to do that? you are just adding one more component in call flow and that is CUCM.

Gateways can directly route a call to CVP or use SIP proxy to route to CVP. and that is the preferred design.

CTI RP registers to agent PG. i think you will complicate it more by introducing CUCM in the call flow.

internal users can use CTI RP or Route Pattern to reach CVP from phones registered to CUCM. 

 

Regards

Chintan

Thanks again Chintan!

Sorry, yes you are correct that the CTI route point is registered to our PGs (not the CVP servers as I originally thought). What you are saying does make more sense now and we would be better off keeping the CVP config for these gateways as you stated. I think that answers all my questions.