RTPManager.addTarget() - takes few sec (2-3)

[zdenko961]

Hi all,

I use AVTransmit2 as base for my test. When call is answered at CTI port I call

AV2Transmit.start().

It takes 2-3 second to open session.

(RTPManager.addTarget() )

If I call AV2Transmit.stop() and after it AV2Transmit.start() again, it starts streaming imediately.

What takes so long and how to avoid these delays?

Cisco phone, Call manager and PC are in the same subnet.

Zdenko

[stephan.steiner]

I can't tell you why, but I've seen this before and the only solution that people have come up with was to launch the process once when you launch the application, immediately stop again, then when you actually need to stream, you are up and running in no time. I guess the JMF source code could yield some more explanation, but generally a lot of network stuff has this sort of behavior: http, soap, rmi/remoting/rpc, etc. The first call just takes longer because the connection has to be brought up.

[zdenko961]

It does not help. When new call is received, in terminalChangedEvent handler I read IP and port from CiscoRTPOutputStartedEv. Those are unique values for every call.

If I make a test call and start streaming it takes few sec to hear something. If call is not disconnected and streaming is initialized again, there are no network delays.

When call is disconnected and CTIPort dialed again, there is network delay at first play.

I am testing possibilities to change current implementation that uses TAPI wave driver with JTAPI. If I am not able to solve this problem, I have to continue to use wave driver (this delay is not acceptable in production).

Cisco TAPI wave driver also uses RTP but there are no delays.

[stephan.steiner]

If you have a development support contract, demand that Cisco implements the media capabilities to their JTAPI implementation. I would except that I filled out the approval for development support ages ago (twice actually) and these things just get lost in transit somewhere :(

I guess we should start organizing and put some pressure on Cisco. AXL is a nightmare, the JTAP implementation is incomplete, you need to pay 500 bucks just to be allowed to point out one of their APIs has a flaw.

[ckatene]

For what its worth, I'm with you on this one. not sure what we can do - cisco seems to have become one of those multinational giants that can't (or just doesn't) listen. its a pity, because the developer interfaces allow third parties to create really valuable add-ons that differentiate the cisco solution from their competitors. its a shame cisco can't be more quality-focused in this area.

[ckatene]

it's not a DNS query, is it?

[yuriykh]

Here is a solution to addTarget() problem I first posted on JMF forum on Nov 4, 2005

http://forum.java.sun.com/thread.jspa?threadID=247408

This is a quote from my post:

To resolve addTarget delay problem do this trick for the first target:

String ipadr = [target ip address];

int port=[target port];

InetAddress adr = InetAddress.getByName(ipadr);

byte[] badr = adr.getAddress();

InetAddress nadr = InetAddress.getByAddress( InetAddress.getLocalHost().getHostName(), badr );

[Or even simpler: InetAddress nadr = InetAddress.getByAddress( “localhost”, badr );]

Now addTarget (new SessionAddress(nadr, port)) takes no time at all.

Again it's enough to do this only for the first target.

[kpharris]

Hi,

when I answer the call from the cti port, the call drops.

I use the standard codec G711.

What do you think it is? a codec problem?

Should an app be receiving the RTP stream before the call is answered?

thank you!

please, reply to this email:

albuquerque@ua.pt