| Author |
|
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 25 2012 at 10:40am | IP Logged
|
|
|
Hello again Support!
It's been a couple of weeks since you sorted me out with
a working trial, so I thought I'd let you know how I got
on.
I had some problems getting the Media Engine to register
with a registrar and/or a proxy. This turned out to be
due to my not calling EnableSipDomain() first.
I've finally got what appears to be a fully working IVR
application. I've tested it on my development machine
and I've got good audio and perfect DTMF recognition.
Tests with a softphone and HP's Sipp test application
(http://sipp.sourceforge.net/) have gone great.
When it comes to putting the application in our live
environment, I have problems receiving DTMF tones from
our VoIP providers SIP trunk. Audio is not a problem.
IVR prompts from the application come across loud and
clear. I've also seen one case (repeatable) where a SIP
Session Description is negotiated on an inbound call,
valid codecs and telephony events are agreed upon, and
then the User-Agent: Cisco-SIPGateway/IOS-12.x terminates
the call with a Reason: Q.850;cause=65. This is
confusing since as far as I can tell, both devices
support the same capability.
Also, I've noticed that I can only run one instance of
the Media Engine in an application. Is this intended
behaviour, or am I able to run multiple instances of the
Media Engine to cover more than one SIP port?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 25 2012 at 11:02am | IP Logged
|
|
|
Cris,
That is good information. Remember – that “engineering release” of the SDK will also stop functioning at some point so don’t deploy that version!!!
The single instance per process is by design. We can remove that characteristic for an additional licensing fee. We should discuss this later if it is necessary.
If you need help debugging the DTMF issue associated with your SIP trunk provider, we can help. We would work with you under a short term support agreement. We can discuss support pricing off-line via email.
Sounds like you made good progress…
RJ
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: September 26 2012 at 3:44am | IP Logged
|
|
|
We've no intention to deploy the engineering release as a
permanent solution. This is purely to test
interoperability with our VoIP suppliers.
I totally understand about the single instance per process.
Depending on the licence cost, we might like to have the
convenience of monitoring several of our lower traffic
lines from one application.
And thank you for your offer of a short term support
agreement to resolve our provider issues. Feel free to
email me with prices.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 26 2012 at 8:16am | IP Logged
|
|
|
You are using RFC2833 out of band DTMF? Yes?
RJ
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: October 02 2012 at 9:37am | IP Logged
|
|
|
support wrote:
You are using RFC2833 out of band DTMF? Yes?
|
|
|
Yes we are.
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: October 02 2012 at 9:43am | IP Logged
|
|
|
I'm also seeing some odd behaviour when the VoIP Media
Engine comes to negotiate Session Media. I see lines
like:
m=audio 0 RTP/AVP 8 0 18 101
m=audio 0 RTP/AVP 8 101
m=audio 0 RTP/AVP 8
Where the port is always specified as 0. This doesn't
happen in the development environment. When I tested the
Media Engine with a soft phone in the development
environment I got media descriptions like this:
m=audio 8640 RTP/AVP 8
Is this intended behavior or another license issue?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 02 2012 at 10:21am | IP Logged
|
|
|
It should not be a trial license issue. Your current trial will be OK until October 10, 2012.
I assume these are media descriptors for a “200 OK” response for an incoming call. It’s most likely some sort of SIP interoperability issue with the incoming SIP.
RJ
|
| Back to Top |
|
| |
Cwilson
Intermediate
Joined: August 10 2012
Location: United Kingdom
Posts: 25
|
| Posted: October 02 2012 at 10:30am | IP Logged
|
|
|
The first one:
m=audio 0 RTP/AVP 8 0 18 101
Is actually from an outbound INVITE.
The rest are from SIP 200 OK packets.
It looks like the Media Engine isn't assigning a port when it negotiates the media description.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: December 17 2012 at 9:39am | IP Logged
|
|
|
Update:
After working with this customer, we found that using alternate media engine SDK configuration settings solved the above issues. This thread is now closed.
From Cwilson:
I downloaded the engineering release and dropped it into my application and I’m pleased to report that it is behaving as expected on both inbound and outbound lines. DTMF digit detection is good and audio quality is fine.
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: Live Environment Issues
