@umesh: Are you transferring a text file with rtpsend or an RTP one? rtpsend requires a text file such as sample.txt while rtpplay expects an ascii RTP dump file. What kind of file is file.rtp in your post above?
Here are three files that you can use to test your rtpsend, rtpplay and rtpdump routines - sample.inp, sample.rtp and sample.hex. The file sample.inp is just a text file but the .txt extension gives problems with yousendit.
http://www.yousendit.com/download/bVlETkFpeFVIcWRjR0E9PQ
http://www.yousendit.com/download/bVlETkF2YWJKV00wTVE9PQ
http://www.yousendit.com/download/bVlETkF2YWIwZ2xFQlE9PQ
The file sample.rtp was captured from sample.inp using rtpdump as follows. rtpdump -F dump -o sample.rtp 192.168.1.103/5004 (use your own IP address / RTP port etc.)
rtpsend -f sample.inp 192.168.1.103/5004
Rtpdump must be running in the background before executing the rtpsend command - use Ctrl C to end the rtpdump session. The G.729 data comprises the packed ITU test.bit file.
I think that you do need to include the column of time values that you referred to above otherwise the rtpsend program may terminate with an error - the format appears to be very specific i.e. no extra space at the beginning of new lines or before and after =, no missing data, alignment problems etc.
You really need to get all three utilities working correctly. I'm not sure whether your error is being caused by a source problem or as a result of an incompatible text file format. Try to run rtpsend with the sample.inp file as this format is correct.
If you can't get rtpsend to work you can also use rtpplay. rtpplay requires a file in the rtpdump format i.e. sample.rtp. You need to enter the command -
rtpplay -f sample.rtp 192.168.1.103/5004 etc.
You could also try to capture an RTP stream from a phone conversation using your softphone. You need to have rtpdump running in the background before initiating a call as above (rtpdump -F dump -o phone.rtp 192.168.1.103/5004). You can then compare the rtpdump file that is produced by the softphone with sample.rtp to see if you need to make any changes such as to the ssrc (0x059c72). You might need to change this before the softphone will replay your rtp stream as this number may be chosen randomly for each conversation. You would probably have to change the string during a phone conversation and then send the rtp stream to the softphone to achieve playback.
Here are the first 3 packets of sample.rtp in rtpplay dump format (shown in hex).
31 36 38 2E 31 2E 31 30 30 2F 33 36 31 31 35 0A 48 BD C0 32 00 09 00 B7 C0 A8 01 64 13 8D 89 33 (preamble)
00 1E 00 16 00 00 BC F4 80 12 01 F4 00 00 11 CC 00 05 9C 72 78 52 80 A0 00 FA C2 00 07 D6
00 1E 00 16 00 00 BD 55 80 12 01 F5 00 00 12 1C 00 05 9C 72 57 39 84 5F EF FA DD 00 00 FC
00 1E 00 16 00 00 BD DF 80 12 01 F6 00 00 12 6C 00 05 9C 72 E0 64 0B 9D C6 E3 5D 8C 0A 56
See here for more details about the RTP header format -
http://www.geocities.com/intro_to_multimedia/RTP/header.html
The rtpplay dump format includes additional information such as the column of time values that you mentioned above. The format consists of a 32 byte preamble (ignore this) followed by a variable number of packets (hex values have been included for the first packet of sample.rtp for illustration purposes) -
2 byte size (00 1E=22+8 bytes), 2 byte len (00 16=12+10 bytes), 4 byte time (00 00 BC F4=48372ms), 1 byte (80 -> v=2 (2 bits), p=0 (1 bit) x=0 (1 bit), cc=0 (4 bits)), 1 byte (12 -> m=0 (1 bit), pt=18 (7 bits)), 2 byte ssn (01 F4=500), 4 byte ts (00 00 11 CC=4556), 4 byte ssrc (00 05 9C 72=0x059c72), 10 byte G.729 payload (78 52 80 A0 00 FA C2 00 07 D6) etc. The rtpplay dump format inserts an extra 8 bytes in front of the standard 22 byte RTP packet.
See the note above for bark.rtp for details on how to use rtpdump to translate the dump format into the hex rtpsend type format (sample.hex). The column of time values in sample.hex does not increase regularly by 10ms for each packet - I'm not sure why not but this shouldn't affect the RTP file as they aren't required as you mentioned above. I think rtpsend and rtpplay strip out this information before sending the RTP packets.