What's the proper method to using CPA with a SIP or H.323 call?
Does one use the CCSET_CALLANALYSIS in the MakeCall block or is it more appropriate to wait for the Connect/Alerting/Proceeding event and use a dx_dialp("", ...) to start call progress analysis at that point?
I was trying to use the GC method and then I realized that none of the attributes for CCSET_CALLANALYSIS were available for the IP protocols ... just the regular DM3 boards with physical interfaces.
Bill,
In the pure IP environment dx_dial is a preferrable method, as it gives you a flexibility on when to start CPA and what result to focus on. If you use DNI PSTN boards with HMP, you can use MEDIADETECT method instead (configured via gc_SetPArm and gc_Attach) on the PSTN side.
Thanks.
I take it this means the HMP IP Libs never got the GlobalCall CPA treatment like the DM3 boards. Thus, it's not really possible to use the CCSET_CALLANALYSIS attribute when doing a SIP or H.323 MakeCall?
I only ask because the manuals seem like a circular reference on the subject and never quite say.
That is correct, IPSET_CALLANALYSIS is not supported in HMP SIP/H.323 calls. However, you can set the same values (like CA mode and PAMD speed value) via DX_CAP structure and use it with dx_dial
I've tried the following in my GCEV_CONNECTED routine ...
if (bDoCallProgress && !bInCallProgress && mVOXhandle)
{
dx_clrcap(&cap);
cap.ca_intflg = DX_PVDOPTNOCON;
// cap.ca_pamd_spdval = PAMD_ACCU;
// Issue CPA without use of dialstring
if (dx_dial(mVOXhandle, "", &cap, DX_CALLP | EV_ASYNC) == 0)
bInCallProgress = true;
cout << "CPA started on Connected event.";
}
Hi Bill,
the following code works fine in one of my demos, returning PAMD or PVD
int CVoiceDev::startCallProgress(int timeout)
dx_clrcap(&m_cap);
m_cap.ca_intflg = DX_PAMDOPTEN;
m_cap.ca_noanswer = timeout;
m_cap.ca_cnosig = 1000;
m_cap.ca_pamd_failtime = 400;
return dx_dial(m_hDevHandle, "", &m_cap, EV_ASYNC|DX_CALLP);
I call it upon GCEV_CONNECTED or GCEV_ALERTING, whichever is first
Please make sure that the voice resource is listenning to the IP device (i.e. you obtain the IPM resource timeslot voa gc_GetXmitSlot() and pass it to dx_listen) before starting call progress. The fact that the playback works OK means that the network is listenning to the voice, but not neccessary all the way around
Ah, so you're saying that just because I opened an associated voice device in the gc_OpenEx when I opened the line and media devices, that the voice device may not be connected to the line in a full duplex fashion. Hence, it can play to the line but perhaps can't hear/listen on the line. I will investigate this. I had assumed that opening a voice device with the line and media automatically established a full duplex connection between the voice and media.
I miss the old PEB days.
Well, I always route resources "manualy" to avoid inconsistence between technologies and updates.
If it doesn't work for you, let me know, I'll send you my demo to try
I think I'll try again tomorrow. I can't even get gc_GetXmitSlot to work. It gives me back an "unknown error" in gc_ErrorInfo.
My gc_OpenEx is synchronous so my LineDev should be fully established when it completes and I'm asking for the XmitSlot after a successful open. Probably time to step away and come back later. Do you think I need to wait for an GCEV_UNBLOCKED before I ask for the XmitSlot or something? Or perhaps the media needs to be established before I can ask for the XmitSlot like on a GCEV_CONNECTED event?
BTW, I've updated to SU267 just in case ... since I'm running XPsp3.
You need to wait GCEV_OPENEX event before calling gc_GetxmitSlot. The string you pass to gc_OpenEx must contain :M_ipmBxCy entry to attach the IPM (RTP) resource to the GC (SIP) session.
sprintf(devName, ":N_iptB1C%d:P_SIP:M_ipmB1C%d",m_channel, channel);
gc_OpenEx(&m_hDevHandle, devName, EV_ASYNC, NULL)
Then I'd use dx_open to open a voice resour ce separately and call dx_getxmitslot on the device handle to get a transmit slot for that device.
Upon GCEV_OPENEX or GCEV_UNBLOCKED:
long timeslot; SC_TSINFO tsinfo; tsinfo.sc_numts = 1; tsinfo.sc_tsarrayp = ×lot; if(gc_GetXmitSlot(m_hDevHandle, &tsinfo) == -1) checkError("gc_GetXmitSlot"); else m_txTs=timeslot; // store it in the object / channels structure for future use
Then before gc_MakeCall or on GCEV_OFFERED:
gc_Listen(voice_tsinfo);
dx_listen(gc_tsinfo);
Should work. You can also do routing only 1 time on UNBLOCKED if you don't use dynamica allocation of voice resources (using voice device pool may save mone on licensing)
I don't get a GCEV_OPENEX event ... I'm opening synchronously. I do this in the constructor of my device objects. I assume after a successful open, that I should then be able to get the XmitSlot in that constructor but it doesn't seem to want to work.
I think what I'm going to do now is a record upon receiving the CONNECTED event. That way I'll at least know that what I'm saying into the test phone after I pickup is being heard by the voice process attached to the line.
It concerns me though that my CPA result is CP_NORNG when I run CPA on the line, because my parameters are specifically asking for Call Analysis without the Progress piece. It shouldn't even be looking for a Ringback the way I'm calling it.
Anyway, let's me see if I can at the very least record my response from the test phone.
In the Voice API for HMP:
DX_PAMDOPTEN – Enable PAMD, PVD, DX_OPTNOCON, and fax tone detection. This setting provides full call progress and call analysis (L.P. Including ring back tone detection)
DX_PAMDOPTEN – Enable PAMD, PVD, DX_OPTNOCON, and fax tone detection.
This setting provides full call progress and call analysis (L.P. Including ring back tone detection)
But even if you don't have a ringback (or it cannot be detcted due to its paraetrs), the live voice or AM will trigger the TDX_CALLP anyway. Yes, recording would help to find if your voice path is OK; you may want to specify MD_NOGAIN flag to record with no AGC and see if the level of incoming audio is high enough
My recordings are empty and the dx_reciottdata is terminating before the 10 seconds I've requested. I'm doing the LISTEN stuff now just to make sure, and the call is successful. But I'm getting an empty Wave file. So I have more research to do here. I suspect the same issue would be causing my CPA to fail as well so if I can solve the record problem I will likely have solved the CPA problem.
Thanks for your help. It's been a while since I've done Dialogic ... since SR5.1 anyway. I've tried some small stuff in HMP using H.323 but that didn't fare well in the Cisco environment. Hence, I've moved over to SIP.
You are welcome. It may be a good idea to capture a wireshark (ethereal) trace and make sure the audio is in fact there - some endpoints may behave wierd. I can check the RTP payload if you don't have tools handy, let me know.
I think Leo's guidance should help with looking into the audio issues
There is a also a general application describing call progress analysis which may be of interest as well.
http://www.dialogic.com/products/docs/appnotes/10117_CPA_SR6_HMP2.pdf
- DL
