Unable to build about rtpdump HOT 4 CLOSED

Hi anon, when I said "Linux should be straightforward" I meant to refer to libpcap dependency 😛

I actually did not compile this on Linux or even cloned it to another PC to check the build process, sorry about that.

Right now I tried on a Ubuntu 12.04 and go 1.1.1 and got some build errors on gopacket and so on... I think I will not be able to check this today, but I did not get the errors you mentioned. (When I get some time I will check a current enviroment)

Could you try this:

mkdir ~/gopath
cd ~/gopath
export GOPATH=~/gopath
go get github.com/hdiniz/rtpdump
go build github.com/hdiniz/rtpdump

It should download the dependencies and solve your path issue.
Then build as you are to.

Honestly, I don't get a lot of time to work around with golang, so I don't know the build conventions.
If you manage to get it working, please contribute, it helps a lot.

And if you find it useful, let me know how it can be improved. (I am sure a lot 😄)

Henrique

from rtpdump.

Those instructions worked fine to build the binary. Now I'm getting a different error, which I believe is unrelated to the build or the dependencies. I'm starting VLC and listening on rtp://:1234 and when run $GOPATH/rtpdump play phone_call_test-7.pcap it detects the streams and seems to be playing the one I selected and VLC pops up the following error:

A description in SDP format is required to receive the RTP stream. Note that rtp:// URIs cannot work with dynamic RTP payload format (111).

So I'm not sure if this is a case of the app which transmitted the data not using the proper format and the software on the other end being hacked up to not expect them or if it's something rtpdump is doing to transform the data.

I'm also unclear on why rtpdump codecs list exists. Shouldn't all the decoding be done by VLC (or whatever is being used to view the replayed the stream)? Why would rtpdump need to know about the codecs? It seems like it should be able to just blindly stream the data and let VLC sort it out.

My next steps are going to be to start digging into the code to answer these questions, but it's probably going to be a while before I get time to do that so I figured I'd just ask here first. If this is the case of a missing header in my data, I'll probably just hack something up to use a hard-coded header to make this work as a PoC, and then go back and add a flag and try to make sure the header is actually constructed properly (e.g. based off the stream data).

from rtpdump.

The RTP protocol on its own does not contain enough codec information to decode its payload. All we get is a Payload Type Field in the RTP header.

While many values of this field are defined by IANA to match specific (legacy) codecs, many (more recent and common codecs) fall in the "Dynamic Payload Type Range" (96-127). (Also looks like you case - 111).

You can find these values here: IANA RTP Payload Types

To find out what codec 111 represents, an actual application needs out-of-band information (like a SIP/SDP file describing it). So that is why rtpdump has to understand different codecs and allow you to input some values for it (that would be transmitted to the actual application via SDP).

rtpdump codecs list exists just to print the codecs and the parameters that have being implemented in rtpdump.

When you use rtpdump play, and again sorry about lack of detailed documentation, you need to tell VLC (or other player) exactly what is the codec (and its parameters) that you are using. Like I said, it cannot infer that information from RTP stream alone if the payload type is in the dynamic range.

So as VLC complained, you cannot use VLC rtp://:1234 with a dynamic payload type:

A description in SDP format is required to receive the RTP stream. Note that rtp:// URIs cannot work with dynamic RTP payload format (111).

What you should to instead is create a SDP file that describes your SDP stream, for example:

amr_stream.sdp

v=0
c=IN IP4 127.0.0.1
m=audio 1234 RTP/AVP 111
a=rtpmap:111 AMR/8000

Above I described a RTP stream of dynamic payload type 111 located at localhost:1234. Then I specified that the 111 codec is AMR Narrow Band (8000) with bandwidth-efficient format. (For octet-aligned format, add line a=fmtp:111 octet-align=1)
AMR has a few other parameters which is crucial to proper decoding of the stream, so you need to know
more about that. If you are working with AMR, most important is NB vs WB and octet-aligned vs bandwidth-efficient.

Checkout: AMR Payload Format Parameters

Then you just open the SDP file in VLC. If you need help setting it up and don't mind sharing the pcap I will gladly check it with you.

Best regards,
Henrique

from rtpdump.

Awesome explanation, thanks! I was able to get the audio to play, but I suspect it may be encrypted because it was not the audio expected, but instead just some awful screeching/glitching noises. However, this confirms the build issues are resolved, so this ticket can be closed out (hopefully after adding the build instructions from earlier to the README). I'll continue to look into my specific .pcap and rtpstream to see if I can make some progress in playing this audio file. If I find any issues with rtpdump, I'll be sure to open another issue inquiring.

from rtpdump.