RTP messages whose payload type is AMR_WB(100) can not be decoded.

3 replies [Last post]
sunywin
Offline
Joined: 09/07/2012

I am using jnetpcap-1.4.r1380 to decode RTP messages whose payload type is AMR_WB(0xe4), but it can not be decoded, the raw datas are as below:

00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 b8
00 66 00 00 40 00 39 11 51 9f dc 67 dc d9 df 39
56 b5 de f2 1b 62 00 52 77 83 80 e4 00 01 00 00
3e 80 fb fb fd fd 80 44 50 46 00 33 ba ce 25 f1
59 30 10 a3 1f 84 d7 77 f3 6a 13 13 a0 93 e5 0c
29 21 72 f1 c3 83 ec 66 35 89 3e 80 e8 89 52 c0
25 b5 1c 6d e6 3c 07 bc 33 55 e9 c0 6d 2c af b3
af 43 31 d0

i change the "77 83 80 e4" to "77 83 80 1e", it can be decoded.
i Check the source code in packet_protocol.cpp:

if (rtp->rtp_ver != 2 ||
rtp->rtp_cc > 15 ||
rtp->rtp_type > 25 ||
rtp->rtp_seq == 0 ||
rtp->rtp_ts == 0 ||
rtp->rtp_ssrc == 0
) {
TRACE("INVALID header flad");
CALL(debug_rtp(rtp));
EXIT();
return INVALID;
}

if the "rtp->rtp_type > 25", this data will be considered as INVALID.
i do not know it is right or not. and this data can be decoded with Wireshark normally.

Thank you for your any information!

Mark Bednarczyk
Offline
Joined: 03/22/2008
I will take a look at this

I will take a look at this new payload type. This has be changed gradually, as it affects heuristics. If you open up the heuristics restrictions too much, then protocol may be chosen in many in appropriate cases. I have seen this happen before with Sip. Of course, if it needs to change then it needs to change.

Sly Technologies, Inc.
http://slytechs.com

sunywin
Offline
Joined: 09/07/2012
Thank you for replying!

Thank you for replying!

Viron
Offline
Joined: 10/15/2012
Hi, I already opened a Bug

Hi,

I already opened a Bug regarding this issue. I have the same problem with DTMF payload (101).

Bug: http://sourceforge.net/tracker/?func=detail&aid=3577325&group_id=164277&...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.