My board is a Dialogic Diva UM-Analog-4
I'm having problems taking a working call transfer test with the line test tool into working code. Currently I'm able to transfer a call using the following settings in the line test tool:
Transfer Type - Transfer with consultation call/ Primary Call on hold.
Consultation Call - Use same channel/line
Complete Transfer - During Proceeding State.
However when I go to write my code I'm getting a DivaResultInvalidParameter response when calling incomingCall.CompleteSupervisedCallTransfer(consultCall).
For more info I'm using async mode, and I've attached the relevant bits of code that I'm calling. I would appreciate it if anyone could get me going in the right direction to figuring out what parameter is invalid and how to make it valid.
Anyone have anything on this? Even a link to what DivaResultInvalidParameter means when it's coming back from CompleteSupervisedCallTransfer? The help topics on it just say that it can return invalid parameter, not what it means when that happens.
Maybe a specific log would help? I've got a dead line looming and I would really appreciate the help.
Not sure what the underlying issue is without looking at logs but to simplify this you can just use the single step function BlindTransfer as it does the same thing as a supervised transfer on analog lines. You will need to set TransferUseSameChannel before calling the blind transfer.
I did attempt to use the blind transfer function, however testing a blind transfer was disabled in the line test tool, and it failed the first few ways I tried it, so I had assumed that it was not an option.
I'll attempt it, but is there a specific log that I'd be able to give you that would help you help me. I'll probably just pull all the logs that I know of and attach them here in a few hours.
Thanks for the reply Vic.
Ok here's the log that I just pulled for attempting a Blind Transfer. When I call into my test machine I just hear silence for awhile till it hangs up on me. I'm in async mode and I'm using waitasynccomplete if that helps.
Also included is the logs for the supervised transfer. When I called in for this test i heard it click a few times then I hear dialing, then it hangs up on me.
Here's the supervised transfer log, I couldn't seem to attach more than one file at a time. I'd still really rather have the blind transfer work though. So much cleaner.
Thanks again.
With the blind transfer when you call in you should hear silence or possibly a hold tone, depends on what you are connected to (eg PBX) as the Diva board will first try to put you on hold then reuse the same channel to dial out.
The Blndtransfer seems to fail with error 7 when dialing the new call out, error 7 is line error which would indicate the PBX/Line does not support transfer or we are not sending the correct commands to initiate a transfer.
First thing to try is to plug a normal analog phone into the line you are using for the Diva card then try a blind transfer using the phone. Generally you answer the call, do a hook flash (ie briefly press the hook button) to go on hold then dial the new number.
If that doesn't work then you need to find the sequence of events that you need to do on the phone to make a blind transfer successful, you may need to speak to the PBX people about that. Then replicate that in the Diva configuration. There are various parameters for sending hook flashes, dtmf tones etc in the configuration utility, some PBX need a longer duration hookflash, some need a hookflash to go on hold, dial number then a hookflash to complete the transfer etc. and you can configure these in the Diva configuration so they happen when you invoke the blindtransfer function.
Already tested. I call from line 1 to line 2. I pick up line 2 and hit flash, then dial to line 3, once line 3 picks up I hit flash again and hang up and line 1 and line 3 can talk to each other. I'll start messing around with the PBX settings I guess.
Any words of advice?
By defualt the Diva Analog card does not send a hook flash to complete the transfer so can you change the configuration to do this please.
In the Diva configuration, make sure View/Advanced is selected then click on one of the Analog plugs. In the right hand pane select PBX Parameters/Show and you will see several parameters appear.
In the Complete Call Transfer option enter a ! which means hook flash, do File/Activate and reboot when requested then try again.
Ok I haven't replied in awhile since I've been getting some... interesting results.
I was in messing with PBX settings and kept hearing the line dial, so I figured that maybe the flash hook wasn't long enough and cranked it up to 300ms, and it started transferring calls... In a very odd way.
What I'm doing is having the application listen for phone calls, answer them and start a new thread that does the blind call transfer, then wait on WaitAsyncComplete(30). I'm getting odd results.
What happens is I call in, and the program answers and does a blind call transfer to my target number. Wait async completes after about 10 to 15 seconds and OnSuppServ gets called with a 0 or a 1 (it varies) and OnDisconnect gets called. The program exits and releases the call. About 4 seconds later another call rings in (is the board calling itself?) and my program answers it and goes through the same steps as above, this time it hangs out at WaitAsyncComplete for a bit longer, then OnSuppServ and OnDisconnect both get called again. The program exits and disconnects. After about 10 more seconds of silence the calls actually seem to connect and I can hear ringing. Total time from the initial call transfer attempt to ringing can be about 55 seconds.
What is going on here?
300ms is pretty long so its probably causing the strange behaviour you are seeing which sounds a bit like the PBX calling you back.
I'd go back to a more normal 150ms, use the ! in the complete transfer and see how that goes.
If it works with a phone then it should work in the same way with the Analog board so if its still not working please take a network trace as well as a SDK trace so we can see what is happening - use teh Diva Diagnostics tool for the network trace.
Well to be fair I did put the ! in complete call transfer and ran tests at 50ms, 100ms, 150ms, 200ms, and 300ms. The only one that actually transferred the call was the 300ms, and then only with the above weird behaviour.
I'll try to get you the network trace soon.
Ok here are the logs exactly as you asked. I set the hook flash to 150ms and added the ! to complete transfer.
I've included the results from two different attempts. One attempt had suppserve return true and one false. Both were done the exact same way and I'm not sure what the difference is. Neither of the transfers actually connected.
Hi,
the defTraceFile logs do not contain debug data. But they show the installed driver is 2 years old. An update would be advisable -> http://www.dialogic.com/support/software.aspx
In your first post you wrote the transfer works with the Line Test tool but not with your application. Is that still the case? Just asking in case anything got broken with the last few configuration changes.If it still works with Line Test tool but not with your code - I would suggest to activate SDK logging in the Config Tool and repeat the Line Test test. The tool is developed using a different SDK version than your application and it uses static libraries - so there is a change your problem is caused by the API and not your code. Nevertheless the log should tell you what functions /settings the Line Test tool uses. Thus using the same with your application should result in the same behaviour given no API bug is present.
Hope it helps.
Alex.
