| Author |
|
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 24 2012 at 9:00am | IP Logged
|
|
|
Sometimes after the Media Engine has received a SIP INVITE packet, the application will not receive a SipIncomingCallAssignPhoneLine event.
I'll get an immediate notification with a SipModifySipMessage for every INVITE packet sent, but nothing else.
What I'm expecting is more like an immediate notification of a SipModifySipMessage, followed by a SipIncomingCallAssignPhoneLine. And then a phone line notification of SipIncomingCallStart.
Does anyone know of a condition that will cause the media engine to ignore invite packets? Or cause it to fail to assign a line to an incomming call?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 24 2012 at 10:29am | IP Logged
|
|
|
Cris,
Post the received SIP for the call. I can feed your SIP into the media engine here and see what is occurring. Will most likely look into this next week…
Thanks,
RJ
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 24 2012 at 10:37am | IP Logged
|
|
|
The SIP Invite sent to the media engine is as follows
Code:
INVITE sip:gallinet@192.168.10.57:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.57:5230;rport;branch=z9hG4bK4111584
To: <sip:gallinet@192.168.10.57:5060>
From: "3536767406" <sip:3536767406@192.168.10.57:5230>;tag=8560
Call-ID: 1345800276-11584-G-DEV01@192.168.10.57
CSeq: 997 INVITE
Max-Forwards: 20
User-Agent: NCH Software Express Talk 4.23
Contact: <sip:3536767406@192.168.10.57:5230>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 334
v=0
o=NCHSoftware-Talk 1345800249 1345800276 IN IP4 192.168.10.57
s=Express Talk Call
c=IN IP4 192.168.10.57
t=0 0
m=audio 8000 RTP/AVP 0 8 96 3 13 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
|
|
|
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 24 2012 at 10:39am | IP Logged
|
|
|
As I said in my opening post, the problem is intermittent.
Sometimes when I start the media engine, it processes calls
just fine. Other times it doesn't.
The way I've been dealing with it so far is stopping and
restarting my application and just hoping that it will
work.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 24 2012 at 10:55am | IP Logged
|
|
|
Are you developing using C or C++?
Sounds like a possible memory corruption issue... Check your code for "wild" pointers.
We will verify here that the INVITE gets processed 100% of the time by the media enigne...
RJ
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 27 2012 at 9:36am | IP Logged
|
|
|
Are you using C/C++ (native code) or some .NET language like C#?
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 28 2012 at 3:11am | IP Logged
|
|
|
I'm using the managed C# .net implementation.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 28 2012 at 6:14am | IP Logged
|
|
|
Do your INVITEs for failed calls use the same CallId and From header tags as a previous call that succeeded?
If the answer is Yes, then what you are seeing is normal behavior for the media engine SDK.
Solution 1:
Make sure your SIP client is capable of issuing a different ”From:” header tag for each new SIP INVITE.
From: "3536767406" <sip:3536767406@192.168.10.57:5230>;tag=8560
OR…
Solution 2:
An alternate solution is to make sure your SIP client is able to use a different call ID for each new SIP call:
Call-ID: 1345800276-11584-G-DEV01@192.168.10.57
Using either solution above will allow all of your INVITES from the NCHSoftware-Talk to be processed.
To look into this further, we need (in this order):
1) The INVITE for the last call that succeeded.
2) The INVITE for the very next call that was ignored.
Thanks,
RJ
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 28 2012 at 6:17am | IP Logged
|
|
|
One other item, this SIP interoperability behavior exits for both native C/C++ and Managed code SDKs. The Call-Id and From header tags should be different for new INVITEs.
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 28 2012 at 6:33am | IP Logged
|
|
|
RJ. I don't believe that I've made myself clear in my opening post.
The behaviours I've seen so far are consistant during a single execution of the application. Details of the two scenarios follows:
Scenario 1:
Application starts.
Any attempt to place a call from the test phone to the application is met with a SipModifySipMessage event. No calls are taken.
Scenario 2:
Application starts.
Calls are handled as expected. Calls placed immediately raise a SipModifySipMessage event followed by a SipIncomingCallAssignPhoneLine event.
No changes have been made between the two scenarios. What I'd like is for scenario 2 to happen every time.
The applications that I'm using to create test calls are :
Express Talk Business Edition
XLite
SIPp
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 28 2012 at 6:43am | IP Logged
|
|
|
Sip Invite that succeeded:
Code:
INVITE sip:gallinet@192.168.10.57:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.57:5230;rport;branch=z9hG4bK4311584
To: <sip:gallinet@192.168.10.57:5060>
From: "3536767406" <sip:3536767406@192.168.10.57:5230>;tag=8562
Call-ID: 1345800278-11584-G-DEV01@192.168.10.57
CSeq: 240 INVITE
Max-Forwards: 20
User-Agent: NCH Software Express Talk 4.23
Contact: <sip:3536767406@192.168.10.57:5230>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 334
v=0
o=NCHSoftware-Talk 1345800249 1345800278 IN IP4 192.168.10.57
s=Express Talk Call
c=IN IP4 192.168.10.57
t=0 0
m=audio 8000 RTP/AVP 0 8 96 3 13 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
|
|
|
Application restarted.
Next Sip Invite that failed :
Code:
INVITE sip:gallinet@192.168.10.57:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.57:5230;rport;branch=z9hG4bK4611584
To: <sip:gallinet@192.168.10.57:5060>
From: "3536767406" <sip:3536767406@192.168.10.57:5230>;tag=8563
Call-ID: 1345800279-11584-G-DEV01@192.168.10.57
CSeq: 625 INVITE
Max-Forwards: 20
User-Agent: NCH Software Express Talk 4.23
Contact: <sip:3536767406@192.168.10.57:5230>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 334
v=0
o=NCHSoftware-Talk 1345800249 1345800279 IN IP4 192.168.10.57
s=Express Talk Call
c=IN IP4 192.168.10.57
t=0 0
m=audio 8000 RTP/AVP 0 8 96 3 13 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
|
|
|
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 28 2012 at 7:34am | IP Logged
|
|
|
Ok, I see what you are saying…
So your C# code processes the SipModifySipMessage immediate event, Yes?
Please verify that your C# application code is not setting the “IgnoreSipMessage” value in the VoipMediaEngine.SIP_MESSAGE_IMMEDIATE_DATA structure that gets returned back to the media engine when you process the SipModifySipMessage immediate event. If this value is non zero, the received INVITE will be completely ignored.
Test code form you (a small Visual studio C# project) that exhibits the condition would also help.
If you purchase our SDK, we will make sure this current situation is not an issue for you.
The effort required to exactly pin down the cause of this situation really falls under paid support…
RJ
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 28 2012 at 7:37am | IP Logged
|
|
|
Also, I do not see anything glaringly obvious in the 2nd SIP INVITE you posted that would cause the media engine to ignore the SIP.
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 29 2012 at 3:58am | IP Logged
|
|
|
Ok, here's an update.
I put together a little test program with the media
engine, just getting it to answer calls, hold the line
open and then terminate.
I was kind of disappointed when I managed to replicate
the bug. I was hoping that there was something wrong
with my implementation.
Then I tried changing the SIP port from 5060 to 5070. I
get the expected behaviour every time. The Media Engine
picks up the call and does everything it's supposed to.
Which is weird. Because changing that setting should
make no practical difference. Talking to the media
engine on port 5070 should be functionally the same as
talking to it on port 5060.
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: August 29 2012 at 6:26am | IP Logged
|
|
|
Nope, looks like I just got lucky. I can replicate the bug
on different ports.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 29 2012 at 7:28am | IP Logged
|
|
|
Cris,
Good job attempting to isolate/test this further.
I would like to get a ZIP archive of your test program (source code so I can build it) and the soft phone you are using that causes the issue. Need to test the exact same scenario you used and determine what is going on. If you can upload these via FTP, I will be able to track this down. I will delete the soft phone when I am done so there are no licensing issues.
Let me know what you want to do. I will create a support FTP account for you when needed.
When are you going to purchase our SDK?
RJ
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 10 2012 at 6:17am | IP Logged
|
|
|
Thanks a lot RJ
I can supply you with a test program that exhibits the behaviour I reported. Let me know the FTP account details by email and I'll upload it for you.
We'll be purchasing your SDK as soon as we have a working IVR up and running. Upgrading our IVR has become a real business priority now.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 10 2012 at 10:21am | IP Logged
|
|
|
I will email you FTP account information.
Please upload your test app project and an installable image of a soft phone that is used to generate the issue.
RJ
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 11 2012 at 4:07am | IP Logged
|
|
|
You can download a copy of the softphone image I'm using
from http://www.nch.com.au/talk/index.html
As far as notes goes there's not much to tell. There's a
lot of fluff in the test app that I sent you, but
essentially what it does is this:
The application determines the IP address of the machine
it's on and sets up the media engine start up parameters
and setting the Sip Port to 5065.
The media engine is then initialised with the
redistribution string given in the license details sent
to me. Then Sip Telephony is started with the parameters
previously set up, and then the telephony is enabled.
At this point, a static SipCallBackProc handles messages
from the Media Engine. All events are ignored except for
the SipCallComplete event and the SipOkToAnswerCall
event. A brief trace of the event type and phone line
concerned are written to the textbox on the GUI.
Expected Behaviour:
A call is made from the softphone to the application
using the address 6001@nnn.nnn.nnn.nnn:5065. The
application should then pick up the call and hold the
line until it receives a Sip Bye message.
Actual Behaviour:
A call is made from the softphone to the application
using the address given above. The application receives
the Sip Invite message, but the incoming call fails to
progress past the SipModifyMessage event.
Please let me know if you come across anything that I
haven't covered.
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 11 2012 at 4:46am | IP Logged
|
|
|
Deployment Environment:
In order to further facilitate testing, I deployed a copy
of the test program onto our Windows 2008 staging server.
The server is running .Net 2.0, Microsoft Visual C++ 2008
Redistributable Package and the LanScape license manager.
Same results as my development machine.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 11 2012 at 9:38am | IP Logged
|
|
|
Is your trial software past its 30 day evaluation?
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 11 2012 at 9:42am | IP Logged
|
|
|
Ah yes. I acquired my trial license on the 9th August, so
it would have run out last Saturday.
Is this expected behaviour for a Media Engine that is being
used past its license date?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 11 2012 at 10:27am | IP Logged
|
|
|
The Media Engine will not run past its 30 day license. I can’t remember the specifics but trying to use an expired license won’t work at all.
Which leads me to the questions:
1) Did your evaluation test app work at some time in the past?
2) Did you just start seeing these problems recently?
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 11 2012 at 10:32am | IP Logged
|
|
|
1) Yes it did. But like I said in my original post, the
problem was intermittent.
2) No, I've seen these problems since I started using your
product.
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 11 2012 at 10:36am | IP Logged
|
|
|
I'm seeing the "actual behaviour" that I described in my
post dated 11/09/2012 04:07 every time now.
Unlike before when it would display that behaviour intermittently.
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: Problem with INVITE SIP messages
