12-17-2009 09:43 AM
There is no UDP problem relating to sending and receiving RTP packets. As for the buffering of the player, there are tricks can be used to manage the play back in real time. There are other issues which no one brought up so far. One of them is the network some times buffers the time delayed UDP packets and send all them in a very short time. However, there is no problem can't be solved. As far as the sip stack is concerned. Again, you are writing an agent app. It only requires simple sip handling and only the basic messages needed to be implemented.
BTW. I am coming up with a much watered down version of sip which can be written and debugged in a few days.
02-16-2010 09:17 AM
Aviator: "...As for the buffering of the player, there are tricks can be used to manage the play back in real time...."
Do you have any hints ?
I cannot play out a datastream without the buffer-caused delay
How can we 'skip' the buffer ?
03-04-2010 08:26 AM
Thanks for your comfirm.
It looks like the challenge is less than I thought.
There are already some VoIP clients for BB on the markts, so the mission is also possible.
Only there are so many things to be done on BB, compare the other mobile platforms, which support C/C++.
03-04-2010 09:36 PM
for the creation of RTP packets, what RTP stack did you use? did you create them manually?
It seems that the MMAPI for J2ME does not include RTP fonctionalities, am i right?
03-04-2010 11:38 PM
RTP is not complicated. Just headers. VoIP services don't rely on RTP info except for the application ID, a.k.a. stream/connection ID. Asterisk relies on not receiving RTP packets for a period of time to determine the lost of connection. Most people just make up the RTP header by hand.
03-05-2010 10:26 AM - edited 03-05-2010 10:31 AM
True, I implemented the RTP headers by myself, are just 12 Bytes, sequence number, audio length, and source id, that is a random identifier, a piece of cake, check its RFC http://tools.ietf.org/html/rfc3550.
However, *cough* bb sux *cough*, I advice you to implement in another platform if you can, the Java machine in this platform seems to me weak and immature, oh and inefficient. I'd rather working heavy load apps in C for efficiency, I know a softphone isn't that heavy for a desktop, but imagine this poor little device managing udp packets incoming and outgoing every 20ms, oh, and not by its native software, but by a virtual machine over it.
Nokia supports VoIP eons ago, IPhone ages ago, even Android years ago, why do you think we still talking about this for bb? *cough*, oh this cold...
Cya, have fun .
Hey Aviator, regards man.
note: edited typo.
03-05-2010 11:06 AM
The BB (85xx, 89xx, 9xxx) has no problem running VoIP under a virtual machine. I have one running except that it is not SIP. Don't know about Nokia. One problem with iPhone is that you can run any in the background. Android is good platform and sipdroid is free. There is either something with whole VoIP concept or some thing else is wrong with these platforms. Otherwise, people would just get a data only plan as cheap VoIP providers are all over the place.
03-05-2010 11:27 AM
true, and let me tell you that SIP is no such problem, I implemented my own stack, I would give it to the community, but I don't know if that would be a violation to the copyright of the company I was working for.
Nokia has full support of VoIP, in several ways and flavors, afaik, you can even use VPN and other fancy stuff in addition to it. I never used IPhone VoIP, but theres a lot of banning in several countries to VoIP software in the IPhone. I think that mobile carriers are not happy at all with VoIP, its against their business model, and thats why they obviously have preferences on the hardware they sell to their users.
I implemented a sip softphone, for the 89xx, but its pretty unstable, nearly unusable, maybe its because my bad implementation, maybe its because too heavy load of both rtp and sip, but I'm pretty sure that it would have worked better somewhere else.