I need help learning how to figure out problems as I dig into developing an HMP layer for our system. I've download several demos, worked for days to get them to compile in VS 2017, and then found other road blocks keeping me from proving the demo code actually works.
Using demo - Sr6Callp
The current problem is
dx_getxmitslot error=0x6a Invalid Switching Handler Bus Mode
What does that mean? I ask myself.
So I go to https://www.dialogic.com/manuals/hmp/hmp30win and open the Global Call API Library reference because …… that has the API calls, right? I do a search for dx_getxmitslot and it shows up as a comment for gc_getxmitslot stating to use dx_ for voice resources. Ok. This HMP demo code appears to be doing that. It says right in the code file for that code block // Get voice device transmit timeslot.
So I did a search for "Invalid Switching Handler Bus Mode" and returned results were a very small number. Even smaller when focused on dx_getxmitslot also. The few entries didn't seem helpful.
I've spent days reading so many PDFs and it hasn't helped get me down the right path.
How do I break this message down and figure out what is going on?
Sound like the dx_getxmitslot call is getting a bad handle in this case. I know I have used that demo on HMP in the past but it was still in context of HMP with DNI (for pstn), not SIP. I know it was originally written for both PSTN (JCT/DM3) and SIP (DMIP/PMAC) boards on SR 6.x baseline. But not sure how much more work was done on HMP as it was very old back then (as I recall) and the project source is probably just as old.
What actual line in the cfg file (outbound or inbound) are you running in this case?
Whoa. More acronyms and history I don't have reference for.
You are telling me HMP is old? What is current?
You mentioned SR 6.x. Does SR = Standard Runtime Library? If so, the latest PDFs on www.dialogic.com/.../hmp30win say they are V5. What is this 6.x?
To answer your question:
I'm attempting to use the provided inbound.cmd with this line uncommented
sr6callp mode=inbound type=JctAnalog protocol=pdk_na_an_io vox=dxxxB1C1 dropOnConnected=0 playFileName=SitNoCircuit.vox
I'm being told that HMP is the layer over PSTN and IP.
No, HMP is not old, the SR 6.x (system release 6.0 PCI software) was a different older animal of which the demo you are using was meant for. Thus the name sr6callp. What I said was I don't recall if is was meant for HMP usage itself, I know it has IP capabilities but like I said that was for DM3 board that had IP caps, like the DMIP and IPT (ie pmac). this is all older hw no longer sold by dialogic.
Moving forward.... the line you have here from the inbound config file is wrong as its looking for analog JCT board (like C120jct), this is not anything you would use with HMP. it references the SR 6.0 release as I mentioned prior.
That is why you get the switching error in this case then. You need to use one of the SIP config lines I suspect.
so in the various demos that I have seen there are API calls with "sr_" prefix. Is that System Release or Standard Runtime that the prefix is referring to? I had been assuming Standard Runtime as that seemed to be the PDF API with applicable hits when searching.
So what is this "system release 6.0 PCI software"? What is the history? I'm not grasping what that is or if it is an "is".
Don't confuse the SRL API (standard runtime library) used for event processing between host library and firmware communications with that of SR (system release software) in this case.
In anycase, the 6.0 software and all board based products were sold off to Sangoma last year and no longer own by dialogic. So if you were really looking to use that going forward you would have to contact them for more information.
But I suspect that is not really the case. Overall, I feel it might be worthy for you to have some conversation with a dialogic field (FAE) sales rep to get you in the right direction.
If you PM me your information i can see if that is a possibility...
Let me talk internally here first. It sounds like I've been given an impossible task. Build a layer that allows for Sip (new stuff) and PSTN (stuff in field).
I don't think the task would be "impossible", I just think you may need some pointers to provide the background on getting you to the point of where you need to be. And that type of conversation would typically be something more elaborate than what would be discussed in the forums...
Overall, it sounds like some type of porting effort is involved here in this case.