vicidial.org

Hello,

I've been struggling with this, I need to enable the CPD on my Vici setup, I upgraded from Vicibox 4 to Vicibox 5, I have followed http://www.eflo.net/VICIDIALforum/viewtopic.php?f=4&t=30769&sid=56bdb1d3fdd3dd7583728694d30503a3 but no luck, I recompiled asterisk using the asterisk-1.8.23.0-vici.tar.gz http://download.vicidial.com/required-apps/asterisk-1.8.23.0-vici.tar.gz but still can't make it work, tried to reapply the patch and fails as I posted on the other forum entry, I really need a hand on this.


Regards,

How are you trying to install CPD?

Hi Michael_N,

I've downloaded the asterisk version Kumba posted on this post http://www.eflo.net/VICIDIALforum/viewtopic.php?f=4&t=30769&sid=56bdb1d3fdd3dd7583728694d30503a3 as per he said that it already has the patches, I tried it but cpd its not getting enabled, basically I installed it and enabled the cpd on a campaign, debugged the sip messages and the cpd=on not showing on the sip messages, also the Sangoma Lyra complains about not receiving the correct sip messages, so I tried to apply the cpd patch but it fails to apply, so even with the fails I tried to rebuild asterisk and tested it again but no success
I really need to enable it as per I'm getting tons of answering machines and my agents are not getting really productive because of this, it used to work on vicibox 4 but asterisk already came patched so was just to add the proxy directive on the carrier and enabling the cpd on the campaign, I moved to Vicibox 5 because following a post from Matt he stated that Asterisk 1.8 has a better performance with the CPD which will help a lot when doing telemarketing.

Any help you can provide will be highly appreciated.

Regards.

is lyra software running a seperate server?

Hello Michael_N

Yes it is, but in the same lan segment.

Regards

So the problem is that the patch wont apply?

maybe you should wipe your testserver and do a clean install?

1) you cannot apply a patch to code that already has the patch, of course it will fail. The elements it wants to change have already been changed.

2) if Lyra is "complaining" about something it is likely failing and not sending the codes back to Vicidial ... and Vicidial then cannot act on codes it did not receive.

This leads me to assert it would be a good idea to tack the errors reported by Lyra. Probably by posting them in a technical manner (as opposed to "complains about not receiving the correct sip messages" which doesn't make it possible to troubleshoot anything ...).

Happy Hunting!

Ok, After digging into this for long time, I finally got it working, there is no documentation about this or at least I didn't find any, it tunrs out that CPD its not enabled by default even after you recompile Asterisk, I mean if you read the docs it says this:

Section 3. Configuring your Carrier in VICIDIAL.

Step 1. Log into the VICIDIAL admin page and go to the Admin -> Carriers section.
Step 2. Click on the MODIFY link for your Carrier on the right hand side.
Step 3. In the "Account Entry" section add the following:
outboundproxy=NETBORDERIP
port=5060
Where NETBORDERIP is the ip address of the Windows system that you are running NetBorder on. If "outboundproxy" is already set for your carrier it may not be possible to use NetBorder with them.

On Asterisk 1.8.x you need to set this:

outboundproxy=NETBORDERIP
outboundproxyport=NETBORDERPort

But also there is one more option that is not showed in any other place which is:

enable-netborder-cpd=true

Without that option you will be hunting a ghost like I did for near a month, having my job on line because was not able to enable the answering machine detection, but I hope this will help others to enable Sangoma Lyra/ NetBorder on their Vicidial with Asterisk 1.8.x

Cheers!!!

Nice that you finaly got it to work

Hello guys,

I'm back, it seems that my efforts weren't enough to get the CPD working, as per the calls are getting hungup after exact 30 seconds, I started to debug the issue and it turns out that calls are getting graded by CPD but after the 30 seconds its sending a Cancel message, so I opened a ticket with sangoma about this problem but it has been a week and have not heard about them(every day I ask them if they have an update but no answer from them) so maybe anyone one of you have had this same issue or can point me to something, the problem is that Vici(Asterisk) its not sending an 200 ACK back to the CPD and because of that the call its getting cancelled by the CPD, here is my trunk configuration on Vici

[mg]
username=xxxxxx
disallow=all
context=trunkinbound
allow=ulaw
type=friend
secret=1234
host=10.0.5.40
qualify=1000
enable-netborder-cpd=true
insecure=port,invite
outboundproxy=10.0.5.35
outboundproxyport=5062

I have the Sangoma Lyra configured on a B2BUA mode, so its the vici --> Sangoma Lyra --> Media Gateway(Asterisk PBX) --> Firewall --> ITSP
This setup used to work when I was using Vicibox 4 with Asterisk 1.4 but for some reason its not working now, here is the call flow
Vicidial Telephony Server: 10.0.5.234:5060
Sangoma Lyra: 10.0.5.35:5062
Asterisk Media Gateway: 10.0.5.40:5060

Code: Select all

|Time     | 10.0.5.234                            | 10.0.5.40                             |
|         |                   | 10.0.5.35         |                   
|19.096715|         INVITE SDP (g711U telephone-event)          |                   |SIP From: "1001" <sip:1001@10.0.5.234 To:<sip:71XXXXXXXXXX@10.0.5.40;cpd=on
|         |(5060)   ------------------>  (5062)   |                   |
|19.193631|         100 Trying|                   |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|22.191723|         183 Session Progress          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|28.983934|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|28.984472|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|28.996060|         RTP (g711U)                   |                   |RTP Num packets:1600  Duration:31.981s SSRC:0x72493C94
|         |(12396)  <--------------------------------------  (14768)  |
|29.092716|         RTP (g711U)                   |                   |RTP Num packets:21  Duration:0.398s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|29.492697|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|29.492954|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|29.512802|         RTP (g711U)                   |                   |RTP Num packets:50  Duration:0.977s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|30.506712|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|30.507003|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|30.512723|         RTP (g711U)                   |                   |RTP Num packets:101  Duration:2.000s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|32.519237|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|32.519489|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|32.532749|         RTP (g711U)                   |                   |RTP Num packets:200  Duration:3.981s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|36.528133|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|36.528413|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|36.532065|         RTP (g711U)                   |                   |RTP Num packets:201  Duration:4.000s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|40.537530|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|40.537797|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|40.553601|         RTP (g711U)                   |                   |RTP Num packets:200  Duration:3.979s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|44.546631|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|44.546851|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|44.550777|         RTP (g711U)                   |                   |RTP Num packets:185  Duration:3.684s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|48.251210|         RTP (telephone-event) DTMF Two 2                  |RTP Num packets:8  Duration:0.104s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|48.377018|         RTP (g711U)                   |                   |RTP Num packets:10  Duration:0.173s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|48.555845|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|48.556083|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|48.572751|         RTP (g711U)                   |                   |RTP Num packets:200  Duration:3.981s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|52.564630|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|52.564851|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|52.570574|         RTP (g711U)                   |                   |RTP Num packets:201  Duration:4.002s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|56.573974|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|56.574199|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|56.593295|         RTP (g711U)                   |                   |RTP Num packets:200  Duration:3.980s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|60.582959|         200 OK SDP (g711U telephone-event)          |                   |SIP Status
|         |(5060)   <------------------  (5062)   |                   |
|60.583184|         ACK       |                   |                   |SIP Request
|         |(5060)   -------------------------------------->  (5060)   |
|60.592910|         RTP (g711U)                   |                   |RTP Num packets:21  Duration:0.399s SSRC:0x3B877286
|         |(12396)  -------------------------------------->  (14768)  |
|60.994317|         BYE       |                   |                   |SIP Request
|         |(5060)   <------------------  (5062)   |                   |
|60.994719|         200 OK    |                   |                   |SIP Status
|         |(5060)   -------------------------------------->  (5060)   |
|61.497784|         BYE       |                   |                   |SIP Request
|         |(5060)   <------------------  (5062)   |                   |
|61.498100|         200 OK    |                   |                   |SIP Status
|         |(5060)   -------------------------------------->  (5060)   |
|62.511778|         BYE       |                   |                   |SIP Request
|         |(5060)   <------------------  (5062)   |                   |
|62.512078|         200 OK    |                   |                   |SIP Status
|         |(5060)   -------------------------------------->  (5060)   |
|64.524129|         BYE       |                   |                   |SIP Request
|         |(5060)   <------------------  (5062)   |                   |
|64.524482|         200 OK    |                   |                   |SIP Status
|         |(5060)   -------------------------------------->  (5060)   |


If you see the beginning of the call seems fine, but when CPD request the ACK, Vici sends it to the MG instead of sending the ACK to the CPD and that's why the call gets hungedup, at the end of the flow you can see how the CPD sends a BYE Message, any ideas on why this is happening?

Guys is it possible that no one has experienced this problem, maybe Matt can provide his wisdom about this

post the termination reason that's given after 30 seconds. normally asterisk will terminate after 60 seconds of inactivity (not 30)

X-Lite is the only 30 second termination bug I recall (30 seconds to call termination in times of network instability ... turning off that option solves the problem).

but I do not recall having sangoma or asterisk ever terminate after 30 seconds. so having the actual termination request (issued by Sangoma?) would be useful. not a "technician saying it was requested", of course, but the actual SIP debug request to terminate.

Hello William,

We use Hardphones, Grandstream 1405, they are on the same location, not the same vlan but same building and same backbone, this is the message I get from CPD:

Code: Select all

call-id=1385003923-695682-343-8 The SIP UAC did not answer our SIP 200 response with a ACK request as specified by RFC 3261. Terminating the call. (State: CALLER_CALLEE_CONNECTED)

And this the the SIP Debug

Code: Select all


U 2013/11/20 21:19:21.047665 10.0.5.35:5062 -> 10.0.5.234:5060
SIP/2.0 200 OK^@
Via: SIP/2.0/UDP 10.0.5.234:5060;branch=z9hG4bK3ea32dcb;rport=5060^@
Contact: <sip:NetBorder@10.0.5.35:5062>^@
To: <sip:719723387844@10.0.5.40;cpd=on>;tag=df37ff71^@
From: "1001"<sip:1001@10.0.5.234>;tag=as60a5058f^@
Call-ID: 325c4cfc1fa1d7db57ee9dad73e2d852@10.0.5.234:5060^@
CSeq: 102 INVITE^@
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO^@
Content-Type: application/sdp^@
Content-Length: 231^@
CPD-Result: Voice^@
X-Netborder-Detailed-CPD-Result-v2-0: Human^@
X-Netborder-Call-ID: 1385003923-695682-343-8^@
^@
v=0^@
o=root 2081441141 2081441143 IN IP4 10.0.5.40^@
s=Asterisk PBX 1.8.11.0^@
c=IN IP4 10.0.5.40^@
t=0 0^@
m=audio 16530 RTP/AVP 0 101^@
a=fmtp:101 0-16^@
a=ptime:20^@
a=rtpmap:0 PCMU/8000^@
a=rtpmap:101 telephone-event/8000^@
a=sendrecv^@

#
U 2013/11/20 21:19:21.048017 10.0.5.234:5060 -> 10.0.5.40:5060
ACK sip:NetBorder@10.0.5.35:5062 SIP/2.0^@
Via: SIP/2.0/UDP 10.0.5.234:5060;branch=z9hG4bK793881a9;rport^@
Max-Forwards: 70^@
From: "1001" <sip:1001@10.0.5.234>;tag=as60a5058f^@
To: <sip:719723387844@10.0.5.40;cpd=on>;tag=df37ff71^@
Contact: <sip:1001@10.0.5.234:5060>^@
Call-ID: 325c4cfc1fa1d7db57ee9dad73e2d852@10.0.5.234:5060^@
CSeq: 102 ACK^@
User-Agent: Asterisk PBX 1.8.23.0-vici^@
Content-Length: 0^@

U 2013/11/20 21:19:25.056668 10.0.5.35:5062 -> 10.0.5.234:5060
SIP/2.0 200 OK^@
Via: SIP/2.0/UDP 10.0.5.234:5060;branch=z9hG4bK3ea32dcb;rport=5060^@
Contact: <sip:NetBorder@10.0.5.35:5062>^@
To: <sip:719723387844@10.0.5.40;cpd=on>;tag=df37ff71^@
From: "1001"<sip:1001@10.0.5.234>;tag=as60a5058f^@
Call-ID: 325c4cfc1fa1d7db57ee9dad73e2d852@10.0.5.234:5060^@
CSeq: 102 INVITE^@
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO^@
Content-Type: application/sdp^@
Content-Length: 231^@
CPD-Result: Voice^@
X-Netborder-Detailed-CPD-Result-v2-0: Human^@
X-Netborder-Call-ID: 1385003923-695682-343-8^@
^@
v=0^@
o=root 2081441141 2081441143 IN IP4 10.0.5.40^@
s=Asterisk PBX 1.8.11.0^@
c=IN IP4 10.0.5.40^@
t=0 0^@
m=audio 16530 RTP/AVP 0 101^@
a=fmtp:101 0-16^@
a=ptime:20^@
a=rtpmap:0 PCMU/8000^@
a=rtpmap:101 telephone-event/8000^@
a=sendrecv^@

#
U 2013/11/20 21:19:25.056974 10.0.5.234:5060 -> 10.0.5.40:5060
ACK sip:NetBorder@10.0.5.35:5062 SIP/2.0^@
Via: SIP/2.0/UDP 10.0.5.234:5060;branch=z9hG4bK6af3cb66;rport^@
Max-Forwards: 70^@
From: "1001" <sip:1001@10.0.5.234>;tag=as60a5058f^@
To: <sip:719723387844@10.0.5.40;cpd=on>;tag=df37ff71^@
Contact: <sip:1001@10.0.5.234:5060>^@
Call-ID: 325c4cfc1fa1d7db57ee9dad73e2d852@10.0.5.234:5060^@
CSeq: 102 ACK^@
User-Agent: Asterisk PBX 1.8.23.0-vici^@
Content-Length: 0^@
^@

#
U 2013/11/20 21:19:25.483805 10.0.5.35:5062 -> 10.0.5.234:5060
BYE sip:1001@10.0.5.234:5060 SIP/2.0^@
Via: SIP/2.0/UDP 10.0.5.35:5062;branch=z9hG4bK-d99999-e74efd075269a965-1---d99999-;rport^@
Max-Forwards: 70^@
Contact: <sip:NetBorder@10.0.5.35:5062>^@
To: "1001"<sip:1001@10.0.5.234>;tag=as60a5058f^@
From: <sip:719723387844@10.0.5.40;cpd=on>;tag=df37ff71^@
Call-ID: 325c4cfc1fa1d7db57ee9dad73e2d852@10.0.5.234:5060^@
CSeq: 2 BYE^@
Content-Length: 0^@



It's good to see I'm not alone on this.

Currently I have the exact same behavior,

Code: Select all

May 21 13:05:53 go netborder-call-analyzer: No audio received for this call. Make sure RTP packets are allowed to reach NCA engine.
May 21 13:06:25 go netborder-call-analyzer: The SIP UAC did not answer our SIP 200 response with a ACK request as specified by RFC 3261. Terminating the call. (State: CALLER_CALLEE_CONNECTED)


Calls get terminated also 30 seconds later.

Anyone managed to solve this?

I can't say that I've run into this issue before, but keep in mind that we only ever use the Windows version of CPD due to bug and stability issues that we have experienced with the CPD software on Linux. We just set up a CPD system for a client a couple weeks ago and did not run into any of these problems that you mention.

Just curious as to the version of the CPD that you are running from Sangoma. It works very well for me maybe I can shed some light and share my config. Can you elaborate on the versions of windows and CPD you are running?

Our Vicidial Server uses another asterisk server as the gateway since it is attached to a T1.
so its like this:

Vicidial => Freepbx => T1
With CPD:
( PROXY )
Vicidial => (CPD Machine) => Freepbx => T1

We are using the Windows version of Sangoma Netborder CPD 2.0.3

This is the version of the Call Analyzer we are using:

NetBorderCallAnalyzerSetup2.xLinux_2.0.3

However, fixed this problem.

I made sure RTP port configuration is the same on asterisk and the call analyzer, and IT opened those UDP ports on the firewall, and that solved it.

Glad to hear that it worked, I am using Windows version 2.0.3 and it seems to work fairly well. I do notice that it misses a lot of SIT tones and dispos them as CPDNA, I tried to tweak the tone database a bit from some samples that I took and measured the actual tones as it seems that their tones don't align with all of the tones we see. Helped a bit but I still see a lot of NA's that are really bad numbers. Someday when I get time, I will spend a bit more time on the tonedb and then post my configs as it gets more of the SIT tones than the factory tonedb.. Dont know if that same config is there for the linux version.?

TroyD wrote:Glad to hear that it worked, I am using Windows version 2.0.3 and it seems to work fairly well. I do notice that it misses a lot of SIT tones and dispos them as CPDNA, I tried to tweak the tone database a bit from some samples that I took and measured the actual tones as it seems that their tones don't align with all of the tones we see. Helped a bit but I still see a lot of NA's that are really bad numbers. Someday when I get time, I will spend a bit more time on the tonedb and then post my configs as it gets more of the SIT tones than the factory tonedb.. Dont know if that same config is there for the linux version.?

Did you verify that the sit tones are actually being heard before the NA determination? We've found that some are delayed enough that Vicidial has terminated the call too soon. Had to allow 45 seconds to get the bulk of them.

Clients use the Linux version of Sangoma, but use Vicibox 4 since Vicibox 5 does not like the latest version of Sangoma (asterisk 1.8, I suppose).

Asterisk 1.8 actually seems to work better with Sangoma CPD in some situations we've found.