0

I want to make a custom sipdroid client by using reverse byte order. I think that makes other Voip clients cannot decode these data.

So I read the code of the SipDroid. I found RTP data goes this way: 1. AudioRecord.read(originalPCM) 2. encode(originalPCM, encodedData) 3. rtp_socket.send(rtp_packet) //the encodeData is rtp_packet's data part

And the other side is: 1. rtp_receive(rtp_packet) 2. decode(encodeData, PCMData) //the encodeData is rtp_packet's data part 3. AudioTrack.write(PCMData)

So I modified the SipdroidSocket class. In send method, I add the following code at the beginning.

byte[] b = pack.getData();
reverse(b);
pack.setData(b);

And add the following code at the end of the receive method.

    byte[] b = pack.getData();
    reverse(b);
    pack.setData(b);

I think in this way, the two client can work as usual. But it failed. And I don't know the reason. Please help me to find out why. Thanks.

Fakebear
  • 449
  • 6
  • 15
  • It sounds like you want your data to be encrypted when being sent, but reversing the byte order will not provide such protection. The code you are showing should not have any problems. Have you tried to run this without your modification? In that case, did it work? – Flipbed May 14 '13 at 09:00
  • I know the reversing way will not give the data enough protection. I just use this as a try. If it works, I will change the reverse() method to some useful way to encrypt data. – Fakebear May 14 '13 at 09:02
  • And if I remove the modification. The two client is working fine. But with my modification, there is only noise. I print a log in these two method. I found the send method only called once, there must be some data check in the process. so the send not success. – Fakebear May 14 '13 at 09:05
  • 1
    Then you need to check why send is not sending your data. There is probably some kind of validation, maybe a local checksum control used with the RTP. – Flipbed May 14 '13 at 10:50
  • Yes, I found it. The RtpPacket looks like a byte array. But actually is a struct with some byte as header. So I change the reverse process to keep the head part. The send is OK. – Fakebear May 17 '13 at 08:36
  • I am working on to change the reverse method to encrypt process. Thanks Flipbed, you comments give me a lot of hint. – Fakebear May 17 '13 at 08:38
  • Hi @Fakebear.. as i am working on the same code. For me it's getting some noisy sound. can you help in encrypting & decrypting SIPDROID calls...? – code_finder Jul 26 '13 at 07:00

1 Answers1

0

You should not reverse the hole buffer unless you receive 2,4,8 bytes at a time. You should treat the data as elements of 2,4,8 bytes depending on how the data were stored. The code i see here will not work. suppose you have a buffer of data bytes 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 stored as 4 byte elements of 0x04030201-0x08070605. Reversing the hole buffer will produce 0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01 which is wrong because you will end up with 0x05060708-0x04030201 If you reverse one element(4 bytes) at a time. Keep in mind that the size of an element depends on how the values were stored

Spyros
  • 1