cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8641
Views
0
Helpful
6
Replies

SIP Dialer - CUBE

rhobab
Level 1
Level 1

Hi

I'm trying to implement a SIP Dialer with no luck.  The dialer is always canceling the call and looking int the logs I see a NODIALTONE.

The call flow is as follows Dialer --> CUPS (Sip proxy) --> CUBE --> Via SIP trunk to PSTN.

From the documentation for the outbound dialer option I see that CUBE is not supported for SCCP Dialer (chapter 5) but there is no mention to this in the SIP Dialer chapter (chapter 4).

Has any one had any experience with this? Does any one know for a fact if the SIP Dialer is supported on a CUBE?

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/outbound_option/outboundoption8_5/installation/guide/icm85otb.pdf

Thanks

Victor

6 Replies 6

dehebert
Cisco Employee
Cisco Employee

Hello  VIctor,

UCCE Compatibilty doc has information on supported Voice GW platforms for SIP DIaler:

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/ipcc_enterprise/compatibility_matrix/ipcccompat.pdf

Thanks,
Denis

Start with getting outbound working without CUSP.  Also, you might need to change the wait for IP dial tone registry key in the outbound PG.  I had to set mine to like 20 seconds.

david

Mark Pareja
Level 1
Level 1

Rhobab,

     Unfortunatly the SIP dialer will not work with CUBE and a carrier SIP trunk, tho you may be able to pass calls the dialer uses CPA call progress analysis to determin how to treat the call and with the SIP Dialer CPA is performed via the DSP on the Voice Gateway. This DSP interaction is not invoked unless you are transcoding the call (isdn -> VoIP) thus CPA will not be performed by the router and the SIP Dialer will not recieve the Rel100 message that is expected to treat the call (answer and deliver to an agent or VRU) . This is outlined breifly and very vaguely in the 8.5 SRND. There is a feature request into Cisco to engage the DSP in a a full IP/VoIP call leg to the carrier however they have not yet released supporting code. There is however a workaround, its not clean, and by no way effecient, however I will show you what you would need to do to engage the DSP for a SIP Trunk provider.

SIP Dialer ---> VG-01 (SIP) Voip Dial-Peer (w/ Rell100 enabled)---> VG-01 (PSTN interface/Pots Dial-peer) --> VG-02

(PSTN interface/Pots Dial-peer) --> VG-02 (SIP Dial-Peer) --> SIP-Trunk Provider

** In ths configuration you would not need CUBE as you are never connecting an IP-IP call leg.

----- { VG-01 (SIP) Voip Dial-Peer (w/ Rell100 enabled)---> VG-01 (PSTN interface/Pots Dial-peer) } -----

At this Point in the call leg the DSP is Engaged and CPA is performed.

I have not tested looping the T1 interface to invoke the DSP however I would imagine that would work aswell.

I currently have our SIP Dialer hitting CUSP then load distributed between to egress PSTN based Voice Gateways. It was a struggle but I learned a lot.

My CC

----------------

CVP 8.5
ICM 8.5.2
CUCM 8.5.1
CUSP 8.5

IOS 15.1.3T2 (15.1 + Reguired for SIP Dialer because of DSP CPA feature)

Mark,

I'm trying to use the SCCP dialer with SIP trunks, I can get the calls out of the SIP trunk but as you know CPA doesn't work.

How would I go about using your method?

UCCE 8.5

CVP 8.0

UCM 8.6

thanks

I am interested in the solution also.

          I have not had time to build this in LAB but I have brought up psudo DS1's between routers before for voice service. I'f I have time this weekend I'll build it and post the config and dbgs .  

1. ) For this to work your CUBE VG will need DSP's and VWIC's, Lets say enoug to support the maximum # of calls you want to pass from the dialer.

2.) Your going to want a unique set of Dial-peers for routing this traffic as I assume you only want SIP Dialer traffice to use the psuedo PSTN Solution.

3.) Next your going to bring your VG-R-A online and connect the first VWIC to VG-R-B (CUBE). This is a dummy DS1 that we will be using to transport the Dialer Calls.

4.) On VG-R-A you will need all your CPA, SIP, and now PSTN configs to this Router. CUBE will become a transport and transcoder node in this solution. VG-R-A will become the destination host for SIP Dialer or you can bring up sip legs to your Proxy (CUSPorCUPS). VG-R-A will perform CPA analysis using DSP and report DSP results back to SIP DIaler via rel100 paramaters.

5.) The DS1 connection on VG-R-B(CUBE) should do any final digit manipulation and route all calls to the carrier of your choice. All calls leaving the new didicated SIP Dialer Router VG-R-A should leave the DS1 interface destin for VG-R-B.

Call Flow From SIP-Dialer


SIP-Dialer-> [SIP] -> VG-R-A -> [DS1] -> VG-R-B -> [SIP] -> SIP-Trunk-Carrier

     The reason this solution is less than favorable is the need for the additional transcoding resources. DSP's are not as expensive as they use to be but still not cheap. This solutions requires 2 DSP's for each call (g.711), One DSP will be consumed by VG-R-A to transcode the call for CPA & PSTN transport. 1 DSP will be consumed by VG-R-B(CUBE) to transcode the call back to SIP/G.711 for final delivery to the carrier.

     I have learned that Cisco is working on a method of envoking DSP's for CPA via tcl application specifically for this use case. This would in theory allow us to use CPA on CUBE .