Hi Michael,
Yes, you are right, the voice resources are split among virtual boards, 4 resources per board. The IPT and IPM are only limited by the license. You may have iptB1T4000, if you wish :-). You can also configure more than 1 IPT virtual board in gc_Start (I assume, we are talking about HMP). In this case you'll use iptB1, B2... but overall number of assigned resources is still limited by the license.
Hi Leonid,
Thanks for the extremely fast response.
Just out of curiosity, do the devices have to be opened in a particular order. For example, for IPM devices, can I use ipm_open to open ipmB1C3, then ipmB1C2 and then ipmB1C1 or does it always have to be ipmB1C1 first, then ipmB1C2 and then ipmB1C3?
Thanks,
Michael
No, there is no restriction on the order you open your IPM devices. The recommendation would be to open the IPM devices only once per application life time, and close them when the app exits.
Leonid,
Thanks for the confirmation.
Michael
Hi,
I understand that for the voice devices, there is a limit of 4 channels per board - so the naming convention would be dxxxB1C1...dxxxB1C4, dxxxB2C1...dxxxB2C4, etc...
For net and Ipm devices, I know that I can provision iptB1T1...iptB1T10 and ipmB1C1...ipmB1C10 but is there any limits as to how many channels a specific virtual board can specify (assuming there are enough licenses)?
Thanks & Regards,
Michael
Hi,
We've had problems with SIP RE-INVITEs and SIP 491 in our environment and we followed this page to solve them:
But now we are seeing that some INVITEs sent to Dialogic HMP are taking too long to have a response, the PBX tries to resend the unanswered INVITEs 4 times until the PBX quits trying.
The parameter IPPARM_DEFER_PENDING_REINVITE can be the source of those problems?
I'm attaching a packet capture of the scenario, IP 192.168.46.43 is the Dialogic HMP host, IP 172.17.0.200 is the PBX host.
Some problematic calls are around the time of capture 700.07, 931.39, 960.09, 1905.54, etc.
Thanks.
Hi,
We've had problems with SIP RE-INVITEs and SIP 491 in our environment with HMP 3.0 Win SU 367 and we followed this page to solve them:
But now we are seeing that some INVITEs sent to Dialogic HMP are taking too long to have a response, the PBX tries to resend the unanswered INVITEs 4 times until the PBX quits trying.
The parameter IPPARM_DEFER_PENDING_REINVITE can be the source of those problems?
I'm attaching a packet capture of the scenario, IP 192.168.46.43 is the Dialogic HMP host, IP 172.17.0.200 is the PBX host.
Thanks.
How many ports are on your system? It seems like the calls with RE-invite all worked, but like the 16th or 17th call had issues with the initial INVITE to establish the call much like a few attempts further down in the flow. I really suspect some other issue is going on here not related to RE-INVITE in this case. Maybe a parse error, or hitting capacity of some sort. As in that case, we see no ACK sent back after 200ok is sent from HMP repeatedly. You may want to check why the end-point of switch is not responding with ACK in that case. . After that its seems some other call attempts are not answered, one or two rejects as well.
This would really require further investigation by the support team if the issue were reported via proper channels (should you have a support contract). Otherwise I can only really provide some basic advice on things to check.
Jeff
Its hard to comment without more specifics as to what caused of the crash. Was this an application level exception being caught?
So you say if you recompiled with Su361 the same still occurred? (As opposed to using the earlier SU.)
Does this happen with a single call, or only underload? is there an additional data points that can be provided about what media activity is taking place on the system at that time?
We would need to see the actual stack output to pinpoint the libraries involved in this case. I know there were some changes made in the codebase for merging baselines between Linux and Windows releases, and things were seen and addressed.
Overall, issues like these would need to reported via proper channels to the Dialogic Support Group, but I can provide some guidance if can answer above questions.
Jeff
I had a similar problem.
It was due to SU's above 349 where Dialogic had changed the way in which ipmGetCapabities was returning values and the way in which I used these values in my app.
I resolved the issue by detecting which SU was being used and having my app handle them accordingly.
See:
Hello,
Thank you for your help.
I'm not sure that my problem is the same as you.
I do not use the ipmGetCapabities function in my code.
I will anyway check my media functions.
Yvan
Hi jeff,
The crash occurs when there are one or more sessions in progress.
For the stack, the server is in production. I do not know the stack back up on a process that is compiled in release mode.
Thank you for your help.
I'll try to see with Dialogic Support.
Yvan
I guess you would need to enable user-mode dump collection to get the proper application exe based dump file (full):
msdn.microsoft.com/.../bb787181(v=vs.85).aspx
Jeff
Thank you, Jeff.
I try this now.
Yvan
Hi,
I have a process compile with SU349 HMP libraries, and this run normaly whitout problem.
I updated HMP in SU 354, and now, my process crashs in MSVCR80.dll.
My server is in Windows server 2012 R2 standard, but in Windows 7 pro, I have the same problem.
I already tested in SU 361 and SU367 and I have the same problem.
My process is compile with VS11.
I tried to compile with VS8 and I have the same problem.
How I can do to track and check the problem?
I put an attached file with the windows event.
Thank you for your help.
Yvan
SR140 to Avaya CM over H.323 IP Trunks. What is the maximum number of individual Avaya systems I can interface with? Currently interfacing to a single instance of CM, wish to add one or two more individual instances. Searched blogs and support docs, no information found.
Thank you for your help.
Hello,
I decided to test HMP 367 update. Everything seems to be working as usual, but one thing is broken - T.38 fax, I cannot send any fax from one HMP channel to another though with previous updates it works normally.
The situation is following: T.38 fax connection is established properly, but then fx_sendfax and fx_rcvfax immediately return after execution with errors:
On the incoming channel:
TFX_FAXERROR. Fax disconnect occurred, phase E status: Receiver communication error
On the outgoing channel
TFX_FAXERROR. Fax disconnect occurred, phase E status: Timed out while waiting for a message
I don't understand how an error can be related to "timeout" when it is received immediately after the function execution.
G.711 faxes are sent and received properly.
Could you help me?
Delete this duplicate post, please
From a quick look I see this line after fx_rcvfax called:
10/12/2016 02:51:08.237 6072 6828 dm3fax APPL libdm3fax dxxxB6C2 ::::> fx_rcvfax(0x4) returns 0
....
10/12/2016 02:51:08.334 6072 6696 dm3fax INFO Dm3Fax dxxxB6C2 <---- OnHangupStatusEvt [112] in state FaxAnswer
10/12/2016 02:51:08.334 6072 6696 dm3fax DEBG Dm3Fax dxxxB6C2 ----- *QFC3 IS DONE* (St=112,0)
Basically firmware is complaining that something with RX rate is wrong as per internal define I have:
#define QFC3_MsgHangupStatusEvt_Status_RXB_UNSPECIFIED 0x70 /* 112 */
I see before the call that one setparm fails here:
10/12/2016 02:51:08.235 6072 6828 spwrfax APPL r4 dxxxB6C2 <:::: fx_setparm(4, FC_RXCODING (0x23000020), 0x936a314)
10/12/2016 02:51:08.235 6072 6828 dm3fax APPL libdm3fax dxxxB6C2 <:::: fx_setparm(0x4,0x23000020,0x936a314)
10/12/2016 02:51:08.235 6072 6828 dm3fax DEBG FaxDevice dxxxB6C2 ==<== SetParameter (0x23000020,0x4)
10/12/2016 02:51:08.235 6072 6828 dm3fax ERR1 libdm3fax dxxxB6C2 ::::> fx_setparm returns -1
This could be the reason for failure.
Jeff