Return to LanScape's home page Go back a page...       Active TopicsActive Topics   Display List of Forum MembersMember List   Knowledge Base SearchSearch   HelpHelp  RegisterRegister  LoginLogin

LanScape VOIP Media Engine™ - Pre-Sales Technical Support
 LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Subject Topic: Live Environment Issues Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
Cwilson
Intermediate
Intermediate


Joined: August 10 2012
Location: United Kingdom
Posts: 25
Posted: September 25 2012 at 10:40am | IP Logged Quote Cwilson

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 View Cwilson's Profile Search for other posts by Cwilson
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: September 25 2012 at 11:02am | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
Cwilson
Intermediate
Intermediate


Joined: August 10 2012
Location: United Kingdom
Posts: 25
Posted: September 26 2012 at 3:44am | IP Logged Quote Cwilson

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 View Cwilson's Profile Search for other posts by Cwilson
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: September 26 2012 at 8:16am | IP Logged Quote support


You are using RFC2833 out of band DTMF? Yes?

RJ
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
Cwilson
Intermediate
Intermediate


Joined: August 10 2012
Location: United Kingdom
Posts: 25
Posted: October 02 2012 at 9:37am | IP Logged Quote Cwilson

support wrote:

You are using RFC2833 out of band DTMF? Yes?


Yes we are.
Back to Top View Cwilson's Profile Search for other posts by Cwilson
 
Cwilson
Intermediate
Intermediate


Joined: August 10 2012
Location: United Kingdom
Posts: 25
Posted: October 02 2012 at 9:43am | IP Logged Quote Cwilson

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 View Cwilson's Profile Search for other posts by Cwilson
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: October 02 2012 at 10:21am | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
Cwilson
Intermediate
Intermediate


Joined: August 10 2012
Location: United Kingdom
Posts: 25
Posted: October 02 2012 at 10:30am | IP Logged Quote Cwilson

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 View Cwilson's Profile Search for other posts by Cwilson
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: December 17 2012 at 9:39am | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum






Contact LanScape Hear what the Lawyers have to say How youm may use this site Read your privacy rights