| Author |
|
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 20 2008 at 4:10pm | IP Logged
|
|
|
Thomas,
OK. We tested further. The INVITE request for the final call that sits in the SipStartOutgoingRing state does get transmitted to Asterisk with authentication information. We verified this with WireShark.
Also, from the above post, we stated that there was no response from Asterisk for the final call CANCEL that was sent by the media engine. The CANCEL responses and the INVITE responses were simply not logged by the call tester app. Asterisk sent them and WireShark captured them.
So it appears that Asterisk is indeed dropping or ignoring transmitted INVITE requests on occasion. We will look into adding retries to transmitted INVITE requests. This may help.
Support
|
| Back to Top |
|
| |
BMV_Thomas
Intermediate
Joined: December 26 2007
Location: Germany
Posts: 32
|
| Posted: June 20 2008 at 4:40pm | IP Logged
|
|
|
Hello Support
First, thank you to Randal for his friendly phone calls we have.
I agree that the problem you describe is the problem I have.
I will check this time some of my log files, but it seems that all my log files shows the same like your posts.
Now I try to see, why Asterisk send after some time the warning that the client will no answer and the media engine will nothing receive. Also must be there any other problem because, is there a slowly connection between asterisk and the media engine no calls will fail.
There will be no difference only the communication will be faster. And I will be not belief that this is the background that asterisk will not send or the engine will not receive any message.
Our staff said that he will be made some tests with asterisk 1.0 / 1.1 / 1.2 / 1.4 and the newest on 1.6 and I will have some try’s with the oldest DLL I have and let us see if there will be some news.
On the other hand I hope that you will find a solution for this Problem.
Regards
Thomas
|
| Back to Top |
|
| |
BMV_Thomas
Intermediate
Joined: December 26 2007
Location: Germany
Posts: 32
|
| Posted: June 20 2008 at 5:46pm | IP Logged
|
|
|
Hello Support
Some news after reading my sip log files form two different clients.
First please sorry if there will be an error in my declaration, because I am not a specialist of sip.
Following:
So I mean that the communication between the client and server about a job will be handled over the sequence number. The client have to made a number which is stored first time in the invite request. Now all requests and answers will use this number to identify the job.
What I mean is the sequence number (CSeq) in the sip messages.
Now I see that all call’s which will work fine use different numbers for the two invite request for ONE call. What I mean:
Engine send invite with first number
Asterisk send auth required with this number
Engine send ACK with this number
Engine send invite with second (new) number
.
.
.
Now all messages use this new number, because the first job (invite) is finished and the second invite is a new job. Works fine.
All call’s wich will be stay at outgoingcallring use for both invite requests the same CSeq number. So it will be OK that asterisk will send no response, because if you send the second invite (After ACK to the first invite) the job has ended and has no need for more response.
One more:
If I check the number for some call’s which are make over a slowly connection I see that there will be much more time between the messages and the numbers will be have big difference as the calls which will be make with a fast connection. There is really much less time and the difference between the numbers will be very small.
ALL calls which fails use the same number.
So I think if there is no time for the engine to generate a new number, the engine use the old one and the asterisk run in errors or has no need to answer.
So I am right????
Regards
Thomas
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 20 2008 at 7:03pm | IP Logged
|
|
|
Thomas,
This is Randal, I am still here. I have Asterisk under the debugger and have looked at why he is tossing out (ignoring) the INVITE messages.
You and I have converged on the same notion - The CSeq header value in the SIP may be the problem. I was just in the middle of testing a quick change that takes care of this. It appears to work here. We would like you to test if possible at your location in Germany.
Please download from your support FTP account the “Image - BMV - Temp v5.12.8.5.zip” file image. You can replace your current DLLs with the ones in this archive file.
Let us know your initial test results when you can. I know it is late where you are. If we do not hear back from you tonight, I will be here Saturday morning working.
By the way, please allow us to continue to access your SUSE/Asterisk box for test.
You are a great guy to work with. Thanks,
Randal
|
| Back to Top |
|
| |
BMV_Thomas
Intermediate
Joined: December 26 2007
Location: Germany
Posts: 32
|
| Posted: June 21 2008 at 1:21am | IP Logged
|
|
|
Hello Randal,
its now saturday morning here, and I am back on work, so I can start some test and will post the result shortly.
If you have a need to test our equipment, please feel free to use it today, because our office is closed today.
Regards
Thomas
|
| Back to Top |
|
| |
BMV_Thomas
Intermediate
Joined: December 26 2007
Location: Germany
Posts: 32
|
| Posted: June 21 2008 at 4:36am | IP Logged
|
|
|
Hello Support,
my tests are still running, but I have the first results for you. The first test I run is to use the engine via VPN / Internet.
The engine runs, but I have agree to you, I receive a lot of server errors, more as with the old engine.
Anyway, I run my app in the local LAN:
More than 2000 Calls! None (0, zero, kein, nada) call go stuck!
I think I made round about 2300 calls from the engine to a zap channel, and receive 5 or 6 server errors.
Do I make the same test like yesterday, (only 1 call to get a sip log) I see that the CSeq Number will be not the same, it will be exactly 1 higher (mostly).
So I can agree to you, yes we are right the problem was this number.
At this moment another 3000 calls are running and it looks like the same result.
But one other problem:
It seems that I do not receive the last SipOnHook message at the right time.
After hundreds or thousands of calls I make only one call. After ringing, I cancel this job.
Asterisk terminates this call right away, but the engine do not fire the siponhook event.
If I now start the next call, first the engine fires SipOnHook for the right line (Maybe 5)
And than SipOutgoingCallInitializing for the new call and line (Maybe 6)
So one line of the engine is every time “in use” but only for the engine, not for asterisk!
I think we have to make some more tests, but for me, it is the first time since I buy the engine that I can use my app. I will start some more tests local and via internet and will post again if there are some news.
I stay by side today, if you have a need of more information, Also I would be pleased if I can call you today again.
Regards
Thomas
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 21 2008 at 7:15am | IP Logged
|
|
|
Hi Thomas,
Good job testing. Your test results confirm our tests here. That is good.
Unfortunately, this type of behavior occurs from time to time with SIP and interfacing different VOIP systems. It’s just the way it is sometimes.
The issue is this: A call dialog (call leg) is defined by the Call-Id, To tag, From tag and CSeq values. We have tested the VOIP Media Engine and Asterisk for a long time and have not noticed this issue until you brought it to our attention. Somewhere in the version history of Asterisk, it appears that something has changed because the way the media engine uses and creates Call-Id, To tag, From tag and CSeq values has been the same for a very long time.
We will probably investigate more when (and if) we have more time to determine the exact version of Asterisk that is the cause for this behavior change. One interesting thing to try is to see if Asterisk’s “pedantic” setting would cure the CSeq issue without our latest media engine code change.
Anyway, we know it is not a perfect world so we are simply glad to have identified the issue and implement a change in our code so you can move forward. The temporary change for CSeq header values we added to the media engine yesterday is acceptable and will remain in the product moving forward.
The other issue you mention: We will have to take a look at that too. Please start a new support forum thread with new test information. This one is getting too long.
You can call anytime. We are here.
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 25 2008 at 1:21pm | IP Logged
|
|
|
Hi Thomas,
We were wondering how your progress has been going since we located the CSeq header issue.
How has your development and testing been going?
Any further issues that may hinder your progress?
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Lost Calls .Net
