Ask Your Question
0

Decode TURN Traffic as RTP

asked 2018-05-25 09:20:23 +0000

Basti gravatar image

updated 2018-05-25 09:34:52 +0000

Hey Guys,

i dont find a stable solution to convert recorded TURN Traffic with Wireshark to a RTP Stream to analyze it. Hope you can help me :)

If I have a tcp dump with a Turn Session, I have the following Problem:

  • RTP is encapsulated in TURN | https://tools.ietf.org/rfc/rfc5766.txt

    11.4.  The ChannelData Message
    
    The ChannelData message is used to carry application data between the
    client and the server.  It has the following format:
    
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Channel Number        |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    /                       Application Data                        /
    /                                                               /
    |                                                               |
    |                               +-------------------------------+
    |                               |
    +-------------------------------+
    
  • The TURN Packte bring 4 bytes around the RTP Data and will be encoded as STUN packet image description

  • Use the "decode as" function does'nt help, because Wireshark then will interpret the TURN header as RTP header with it result in a wrong RTP Version. (RTP Version=1)

Is there any way to remove the enclosing 4bytes from the TURN header (without export manual search&replace) to decode the package as RTP?

The goal should be to see the RTP Header, and can work with the Stream in VoIP::RTP::RTP Stream

Thanks and best regards, Basti

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-05-25 20:20:38 +0000

Guy Harris gravatar image

updated 2018-05-25 20:35:34 +0000

The TURN Channel dissector has a table for heuristic dissectors for protocols running on top of TURN, but nothing is registered in that table - which is especially weird, as the change that introduced that dissector, complete with that table, didn't change anything to register in it, even though the RTP and RTCP dissectors were modified in that change.

This means that there is no mechanism in the UI to say "please dissect the TURN Channel payload as X", for any value of X, if the TURN Channel protocol is being dissected by the TURN Channel dissector.

Confusingly, there is, however, a separate dissector for the TURN Channel protocol, inside the STUN dissector. That one appears to be the one dissecting the protocol in your capture.

For that protocol, the RTP and RTCP dissectors are registered as heuristic dissectors, but the RTP heuristic dissector is disabled by default; you have to enable it manually, by going to Analyze -> Enabled Protocols and enabling the "rtp_stun" dissector.

I'll look at reducing the number of TURN Channel dissectors to 1, to make this less confusing.

edit flag offensive delete link more

Comments

Great! - Thanks for the fast response!

For that protocol, the RTP and RTCP dissectors are registered as heuristic dissectors, but the RTP heuristic dissector is disabled by default; you have to enable it manually, by going to Analyze -> Enabled Protocols and enabling the "rtp_stun" dissector.

This works, and is a fair solution for me - Thank you so much!

Basti gravatar imageBasti ( 2018-05-29 12:04:26 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-05-25 09:20:23 +0000

Seen: 6,499 times

Last updated: May 29 '18