This content has been marked as final. Show 6 replies
Andrew Thompson wrote:Before posting this queestion, I also read and searched some topics but no any related one. Moreover, I met your complain about the way of posting a question, so I decided to edit my post to avoid your asking.
..Edited by: 866652 on Jun 17, 2011 8:56 AM
I must correct something after reading several lovely complains of Andrew Thompson :-)
At the bottom of this document,
There is a list of RTP formats you can use JMF to create.
Of the three you listed specifically, JMF is capable of sending and receiving all three: ULAW_RTP, GSM_RTP, and G723_RTP (assuming the xxx was a placeholder for any numbers).
Thanks captfoss for your reply.
I tried to capture the packet from Android to PC and PC to Android, their payloadtype's value is the same, in this case is 0. But Android can not undersatnd it, and in addition, their ULAW packet's size is also different, from Android -> PC (PC can understand) is 172 but the one from PC->Android is 492 (???). I'm not sure that this problem is not entirely from JMF but I also ask another guys on Android area but have not received any answer about this.
hoangtuansu wrote:Things like sample rate, sample size, number of channels, etc will affect the packet size. Additionally, mobile devices may very well have a lower MTU than a normal machine, so that can affect it too.
their payloadtype's value is the same, in this case is 0. But Android can not undersatnd it, and in addition, their ULAW packet's size is also different, from Android -> PC (PC can understand) is 172 but the one from PC->Android is 492 (???).
Even then, there's nothing saying how big an RTP packet should be, how many encoded samples it should hold, etc. So it could be a simple as the PC packing more data per packet.
Most likelly the issue is that Android is 0-4 years old, whereas JMF is 12 years old... so it's almost definately using different versions of the RTP standard.