CVP 7 (SIP) with AT&T IP Toll Free Service - using transfer connect

Unanswered Question

<p>When I return a label (after a Send To VRU node) that looks like "DTMF*8,,,8005551234" as described in the Guide on p. 439, I can see it going over in the CVP trace and I can see it on the CUBE in the ccsip and voice ccapi trace. I can see the router trying to do something with it - for instance:</p>

<p>SIP/Info/sip_info_parse_dtmf: Parsed digit=*, duration=100ms</p>

<p>and I can see the router construct a SIP INFO message and send it to itself and then a reply with</p>

<p>Signal=*<br />

Duration=100 </p>

<p>but these messages should be going out to AT&T.</p>

<p>Anyone played with this?</p>

<p>Regards,<br />


<p> </p>

<p> </p>

<p> </p>

<p> </p>

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

Made progress on this one by changing the dtmf-relay setting in the dial peer from the gateway to CVP (actually to CUPS).

If I make it "sip-notify", the DTMF tones go up to AT&T as RTPEVENT types as shown in a Wireshark trace.

The problem is - the normal dtmf-relay we need for a SIP trunk, all SIP CVP is "rtp-nte"; so we can choose sales or service, enter our account number and so on.

Now suppose the routing script, for some reason or another, determines that the best service is obtained by an off-net resource (PBX) so it wants to signal DTMF in-band to AT&T.

But it needs the dtmf-type to be sip-notify, and it's not.

I suppose I can return a label, have that go to the gateway, catch it in a dial peer and send it back with a different dtmf-type.

Anyone tried this?



Chad Stachowicz Fri, 09/11/2009 - 09:50
User Badges:
  • Silver, 250 points or more


Wondering what progress you made on all of this. Basically over ISDN I am trying to do a post call survey, which is transfered to the PSTN.

They want me to dial a 1800number when it picks up dial in the agents extension and then complete the transfer. I know UCCX supports this but have you done this in UCCE / CVP?



This was a while ago, but yes, I actually made that work. A patch was created to solve anoher problem in an ES, and this was approriate to my problem too.

But it was not documented. Cisco would be aware of it now (lots of SIP trunk action since then) so if you opened a TAC case they would point you to the engineering special.




This Discussion