| Author |
|
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: March 07 2008 at 3:18pm | IP Logged
|
|
|
Hi,
We have been testing mixing audio with the new conference API methods instead of Transmit IVR channels. But have currently hit an early snag. When we enable the conference of a line, we get two SipInCall messages. Here is the line state recorded messages;
SipIncomingCallStart
SipSendTrying
SipSendRinging
SipStartIncomingRing
SipOkToAnswerCall
SipAnsweringCall
SipSend200OkSipReceived
InviteAck
SipIncomingCallConnected
SipInCall
SipInConferenceOn
SipInConference
SipByeReceived
SipSendByeAck
SipInConferenceOff
SipInCall
SipCallComplete
SipOnHook
Is that normal? We didn't see that behavior until we call the Conference API methods. Perhaps we are calling it wrong, but currently after the call goes off hook, we call:
setConferenceGroupIds(mSipEngine, line, 1, confId);
ConferenceLine(mSipEngine, line, TRUE);
Where line is phone line and confId is array with 1 entry of a guid string. After that, we don't disable the ConferenceLine, we simply let the phone hang up (which doc's appear to state will end the conference normally).
The double SipInCall was not expected in this case and messes with our view of the call flow.
Thanks
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: March 11 2008 at 11:25am | IP Logged
|
|
|
Currently, we've worked around the double SIP IN Call messages, but would be best if it didn't happen.
One other issue we have noticed after enabling Conference bridging results reduced line capacity. When we try to enable all the lines of our media engine, we end up with SipMemoryFailure at startup. We already reduced Stack size and transmit buffer amounts previously to get maximum amount of lines possible. But, reducing the stack size again (in half to 200k from 500k) has no significant impact on decreasing memory use with conference enabled. Is it possible to reach a high amount of lines with conference enabled?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 11 2008 at 12:17pm | IP Logged
|
|
|
Hi Juice,
We are waiting for a response from your boss regarding entering into a support agreement with your group. If we get that taken care of, we can move forward unincumbered.
If you are satisfied with the operation of v5.12.8.1, we need to cut you new official product images before tackling further issues.
Thanks,
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: March 11 2008 at 7:06pm | IP Logged
|
|
|
Sorry, wasn't aware this was a new issue, but something with the test release you sent us.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 12 2008 at 9:14am | IP Logged
|
|
|
Hi Juice,
Sorry for the delay.
1)
Let us know when we can get you your official v5.12.8.1 product image.
2)
Please see your boss regarding how we will be handling your future support. Continue to post any bug/enhancement information you require to this forum.
Thanks,
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: March 28 2008 at 11:25am | IP Logged
|
|
|
We are ready for final release as soon as possible.
Thanks.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 31 2008 at 8:31am | IP Logged
|
|
|
Hi juice,
We will get this out to you this week.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: April 08 2008 at 12:07pm | IP Logged
|
|
|
Hi Support
We have checked the FTP area to see if the update was released. However, we cannot currently access the FTP area. Any update?
Thanks
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 08 2008 at 12:42pm | IP Logged
|
|
|
Hi Juice,
The FTP account disabled after a few days. You should be OK now.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: April 08 2008 at 4:11pm | IP Logged
|
|
|
Release was there for downloading. Thanks.
Unfortunately, we ran into one very serious issue with conference, not sure if related to this Double Sip In Call with conference enabled. But, there seems to be a similar issue with conference as with previous problem (dead locks). We have read and examined you Voip Application Design and docs about deadlocks. But nothing there seems to be applying to this situation. The scenario is as follows, receiving invites/byes around the same time, causes one of two things to happen (only when Conference Enabled is TRUE during startup parameters):
1) Lanscape stops responding entirely to BYE's from UA. Lanscape does not send ACK to UA, and Lanscape does not funtion very well after this (cannot shutdown for instance)
or
2) (This seems most common) Lanscape API method ConferenceLine just locks up and does not return.
Is there some other thread lock scenario we should be aware of when this call is made? Since ftp is back up, we uploaded a demo (which includes sample SIPp test scenario:
Code:
sipp.exe -s test -sf test_invites.xml -r 3 host:port
|
|
|
which demonstrates this issue. Perhaps this latest release has a fix for this? Also note, the same dead lock appears with/without (commented out) any mutex's in call session of demo.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 09 2008 at 7:07am | IP Logged
|
|
|
Juice,
We will take a look. Good job uploading an example that experiences the issue. Hang on...
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 09 2008 at 8:32am | IP Logged
|
|
|
What version of SIPp are you using?
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: April 09 2008 at 11:23am | IP Logged
|
|
|
Hi Support,
We are using SIPp:
SIPp v2.0.1-TLS-PCAP, version 20070521, built May 22 2007, 12:49:03
We can try a more recent version if you think it may make a difference.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 09 2008 at 5:20pm | IP Logged
|
|
|
Juice,
We have your demo VOIP app running on a machine here in the lab. The test app is pretty simple as far as conferencing goes.
We see that when a phone line hits the “SipInCall” state, the app basically calls the SetConferenceGroupIds() and ConferenceLine() API procs for the phone line being answered. With any skill, we can isolate the issue quickly.
A few questions:
1)
Other than calling the two API procs noted above, is the app supposed to do anything else to experience the issue?
2)
Simply running the app and allowing SIPp to hammer on the app is enough to detect the problem?
Once again, good work getting this test app together with the SIPp driver scenario. We will post as soon as we discover something. Post with any other info that may shed additional light on the issue.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: April 10 2008 at 10:45am | IP Logged
|
|
|
1) Demo should be enough to show issue. Just answering calls and putting in conference bridge was enough to show the issue here.
2) However, it also seems to involve processing calls at a moderate rate (some where between 3-6 calls a second). And, after a few minutes or less, it would start to act up. Also, it might be related to running out of lines, seems to happen a bit faster when there are no more lines left. It might be session count, but it seems to only show itself when under multiple sessions coming/going - if left at slow rate of 1-2 calls, it seem to perform well over a long time.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 16 2008 at 8:58am | IP Logged
|
|
|
Juice,
We see it. Please hang on as we isolate the problem and get a fix...
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: April 28 2008 at 2:41pm | IP Logged
|
|
|
Hi Support,
We are just checking back for any updates on this issue. We can offer more information if needed to help resolve the issue.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 29 2008 at 7:46am | IP Logged
|
|
|
Hi Juice,
No other info should be needed. We performed testing and see the issue you identified. We just have to isolate the time to get it fixed. It seems to be a pretty stupid error on our part.
We are closing work out on another project for a different customer. We need to get this conferencing deadlock issue out of the way as soon as we can (this week?). Just need to find a block of time to spend on fixing this. When we do, we will have to update you.
Post with any other questions or info as needed,
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: April 29 2008 at 11:54am | IP Logged
|
|
|
Ok, looking forward to having the issue resolved than :)
Thanks.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 01 2008 at 9:53am | IP Logged
|
|
|
Juice,
A quick heads up….
We have a resolution for this conference deadlock issue. We are going to test further over this weekend to make sure the changes are completely solid but at this moment, it looks good.
We’re a bit pissed at our self. I can’t believe our internal testing procedures did not catch this issue. Chalk it up for “plain old human error”. It’s absolutely amazing how a very, very small logic error can throw the whole lot right into the crapper. You’ve got to love (and hate) software. We have now added further QA test procedures to our checkout test plan so that we don’t do this one again.
Here is information from engineering that will be included in upcoming release notes:
------------------------------------------------------------ ------------------------
LanScape Engineering Report
Customer Test Application
Date: 4-29-08
This file contains engineering notes recorded while debugging a customer app thought to exhibit a VOIP Media Engine deadlock situation during conference call operations. Here are the basic findings.
This version of the media engine fixes a particularly nasty thread deadlock issue that was associated with placing phone lines into conference mode. It was possible for the media engine to experience a deadlock situation under the following scenario:
1)
An application worker thread detects an incoming phone call and goes off hook to answer the call.
2)
The application then calls the ConferenceLine() API procedure to place the phone line into a conference session during the processing of the SipInCall state.
3)
At the same time the internal ConferenceLine() API logic is executing, the far end of the call terminates the call. If the execution of the internal conferencing logic and the call terminate logic are “just right”, one of two situations could occur. Either internal call thread logic would start to deadlock or the application thread that called the ConferenceLine() API procedure could deadlock. The internal condition that caused the deadlock to occur was associated with two sections of internal logic waiting on the same completion event.
This dead lock issue has now been resolved.
------------------------------------------------------------ ------------------------
Obtaining new code:
Because we do not have a support contract between our groups, we can’t just update you to the upcoming v6 product image as we would like. We also do not want to apply these latest changes to the v5 code base seeing that branch of the product will no longer be deployed when v6 is officially released.
If your group can re-license your product images (your 4 line and 512 line media engine licenses) using our current media engine prices, then we can get you the updates now. Also, we will get you official v6 product images when they are released.
For current media engine pricing, you can take a look at these two links:
LanScape VOIP Media Engine™ - Supports up to 4 concurrent network phone lines
LanScape VOIP Media Engine™ - Supports up to 512 concurrent network phone lines
The “big item” in the upcoming v6 product is that it has vastly improved DTMF support. It supports the legacy stand alone in-band generation and decoder functions in addition to fully integrated in-band and RFC2833 DTMF generation and detection. Its pretty nice. In addition to that, in-band DTMF detection characteristics (forward and reverse twist, signal threshold, minimum digit ON time, etc) can be changed via the API. No need to request from us special DTMF detector tuning tables anymore. Nice.
An updated Developer Reference that will be the v6 dev ref can be found here:
http://www.lanscapecorp.com/DevResources/LanScape_Software_D evelopers_Reference_v6.zip
Also, at the time of this post, the release notes for v5.12.8.2 and v5.12.8.3 can be found here:
http://www.lanscapecorp.com/DevResources/VOIP Media Engine - Engineering Release Notes.htm
v5.12.8.3 will most likely become the v6 product image – barring any further interim bug fixes that may be completed before the v6 release.
Seeing we have had a good working situation between us, we will then offer other updates to you as needed throughout 2008 for any further bug fixing if required.
Thanks Juice,
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 01 2008 at 10:39am | IP Logged
|
|
|
Juice,
Forgot something…
Regarding the following call states and conferencing:
Code:
SipIncomingCallStart
SipSendTrying
SipSendRinging
SipStartIncomingRing
SipOkToAnswerCall
SipAnsweringCall
SipSend200OkSipReceived
InviteAck
SipIncomingCallConnected
SipInCall
SipInConferenceOn
SipInConference
SipByeReceived
SipSendByeAck
SipInConferenceOff
SipInCall
SipCallComplete
SipOnHook
|
|
|
The two events (SipInConferenceOff and SipInCall) at the end of the call sequence is normal at this time but you may be correct in questioning this state sequence.
What the media engine does just prior to terminating a call (that is in conference) is to remove the call from the conference session (it performs internal phone line “wiring” adjustments, etc) and then places the call state from “conferencing” to “in call”. Once the line is back to the “in call” state, the normal line termination logic is executed to finally get us to the “on hook” state.
This is similar to how the state transitions behave for Hold/UnHold operations too. For example, here are the state transitions for a call that is “In call”, gets placed on hold, and then gets taken off hold:
Code:
For Hold/UnHold:
--> At this point, the call is in state SipInCall
--> Now we command a hold operation and then an un-hold via the API
SipCallHoldOn
SipCallHold
SipCallHoldOff
SipInCall
At this point we are back to the normal "in call" state.
|
|
|
… and here are the state transitions for Conference/UnConference:
Code:
--> At this point, the call is in state SipInCall
--> Now we command a conference operation and then an un-conference via the API
SipInConferenceOn
SipInConference
SipInConferenceOff
SipInCall
At this point we are back to the normal "in call" state.
|
|
|
Now, something interesting… for a far end call termination when the incoming call line is “on hold”:
Code:
SipIncomingCallStart
SipSendTrying
SipSendRinging
SipStartIncomingRing
SipOkToAnswerCall
SipAnsweringCall
SipSend200Ok
SipReceivedInviteAck
SipIncomingCallConnected
SipInCall
SipCallHoldOn
SipCallHold
SipByeReceived
SipSendByeAck
SipCallComplete
SipOnHook
|
|
|
There is no SipCallHoldOff and SipInCall inserted just before the final SipCallComplete and SipOnHook states.
So for consistency with how Hold/UnHold functions, we may want to completely remove the final SipInConferenceOff and SipInCall events as below:
Code:
SipIncomingCallStart
SipSendTrying
SipSendRinging
SipStartIncomingRing
SipOkToAnswerCall
SipAnsweringCall
SipSend200Ok
SipReceivedInviteAck
SipIncomingCallConnected
SipInCall
SipInConferenceOn
SipInConference
SipByeReceived
SipSendByeAck
SipCallComplete
SipOnHook
|
|
|
Any additional thoughts?
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: May 07 2008 at 12:40pm | IP Logged
|
|
|
Hmm, not sure about removing the conference off event. Since, we are taking call out of conference manually (not just letting terminate call doing it). Though, we are also not tracking the conferenceon/off events anyway. It's really up to you what you think the best way is.
In regards to the deadlock issue. Yes, we are most definitely planning to get an updated license/engine. How did the test results this weekend go? Is the problem corrected and if yes, how do we get this new build (purchase new license first)?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 07 2008 at 2:44pm | IP Logged
|
|
|
Hi Juice,
Thanks for your post.
Testing the conferencing deadlock fix went OK this weekend. The conferencing dead lock issue seems OK at this point. We will continue to perform additional longer term testing.
As the result of reviewing the conferencing logic, we found another interesting artifact in the code that we also do not want to deal with long term. This additional modification really only applies to high line density deployments (like yours) and the speed at which many lines can be transitioned to/from the conferencing state and the “in-call” state. We wanted to be a bit proactive and remove as many conferencing problems as possible at this point so we are also tackling this additional issue. The new conferencing checkout tests we added pointed to this secondary issue.
We are at the point where we believe we can release an image soon. It may go into next week though. Just have to see how final testing looks.
I think what we will do is cut you a temp image that has everything. We can treat it as a v6 preview. If everything looks good, then we can re-up your licenses anytime after you work with it for a bit. No worries.
We will repost to this thread when we can cut a new product image.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: May 16 2008 at 3:21pm | IP Logged
|
|
|
Hi Support,
Excellent, a v6 preview would be a good thing to test with. Any chance we can get a release today :) Been a little over a week. Anyway, we look forward to testing new version.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 16 2008 at 5:28pm | IP Logged
|
|
|
Hi Juice,
Your post is right on time. We were working on updating you and a few other customers with the preview v6 product image before today ended. You can download the temp development image from your support FTP account. See the “DLL Only v5.12.8.3” directory of your support FTP account. Note that this distribution only contains minimal content so that you can preview the new changes and continue with your development.
Please read the release notes that accompany the product image for the latest changes and news.
The changes that were made to the conferencing capabilities look pretty good. Especially the time it takes to pop lines in and out of conference sessions. Also, the deadlock issue should be completely gone. Your test app code runs well with this image.
If you want to enable new v6 integrated DTMF related functionality, you will have to use the temp licenses that come with the image. The trial licenses are good for a couple of months.
Repost with any questions feedback.
Thanks,
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Double SipInCall messages
