G.711 u-Law over RTP

[lordnk]

Hi everyone,

I am having a bit of an issue with getting G.711 to stream in the way I need. The intention is to replace the RTP stream output of a Cisco Call Manager's hold music with our own RTP stream.

The RTP stream coming from CCM contains one stream which reports it is ulaw 8000hz, as does my stream, however the phones refuse to play more than a few frames of audio from the VLC stream.

Looking on the wire, Cisco looks something like this:

Code: Select all

Data: 80002CB92597E5800000067ED4CECAC2C0BEBDBCBCBDBDBF... Data: 80002CBA2597E6200000067E5A5C5D5D5E656E7EF0EEE9E8... Data: 80002CBB2597E6C00000067ED5D2CECCCAC7C6C4C2C2C3C5... Data: 80002CBC2597E7600000067E403F3F3F3F404143464B525E... Data: 80002CBD2597E8000000067ED1D8E0F273665F5D5C5E6471... Data: 80002CBE2597E8A00000067EB9B9BABABBBDBEC1C5C9CCCE...

with each packet equalling exactly 172 bytes of data. Additionally there is no seperate RTCP stream present on the network, so one would assume the control messages are muxed in here.

The VLC output looks like this:

Code: Select all

Data: 808045EA196C1DD7C6697351C3CAC8BBBACCC8B4AEADADA8... Data: 800045EB196C1F67C6697351B2B2BCBDBDC4EF5CCDC0D4E9... Data: 800045EC196C1F67C6697351CAD2C1BABBC6C7B6B4BAB1AA... Data: 808045ED196C1F67C6697351B1AFB0AFAFADA9AAACA8A5A7... Data: 800045EE196C20F7C6697351BFD4BEB8C6D3C4BCBFC9BEB2... Data: 800045EF196C20F7C6697351B5AEADB0AFACABACACA8A6AB...

where the packets seem to be dynamically sized. Some packets will be contain 172 bytes of data (the ones with '8000' at the start, 00 offset?), other packets will contain 92 bytes of data (the ones with '8080' at the start', 80 offset?).

With VLC rtcp-mux turned off:

Code: Select all

Data: 808045EA197EABBEC6697351C3CAC8BBBACCC8B4AEADADA8... Data: 800045EB197EAD4EC6697351B2B2BCBDBDC4EF5CCDC0D4E9... Data: 800045EC197EAD4EC6697351CAD2C1BABBC6C7B6B4BAB1AA... Data: 808045ED197EAD4EC6697351B1AFB0AFAFADA9AAACA8A5A7... Data: 800045EE197EAEDEC6697351BFD4BEB8C6D3C4BCBFC9BEB2... Data: 800045EF197EAEDEC6697351B5AEADB0AFACABACACA8A6AB...

again, the packets seem to be dynamically sized - however, as we can see, the payload is exactly the same on these packets.


Additionally, the Cisco call manager sends out packets at intervals of exactly 20ms (or at least, they arrive with 20ms spacing on the client), but the VLC media player seems to be sending at dynamic intervals.

I have no issues listening to either stream with the VLC client, however the Cisco phone only wants to listen to the Cisco server properly. I am wondering if anyone has got any ideas about where to look and what to do.

Is the Cisco server sending a standard RTP/UDP stream of some sort?
Why does Cisco send all packets 172 bytes and VLC send some larger and some smaller?
Would my source file make a difference? To my understanding Cisco is playing directly from a ulaw source file, but VLC refuses to read any ulaw file, so I am forced to transcode to ulaw from a wav.

Any help appreciated!

[Rémi Denis-Courmont]

The problem here is that VLC lacks a real packetizer for G.711, such that it could actually send exactly 20ms frames always.

There is no way to fix this without writing some code...

[lordnk]

How difficult would such a thing be to write? I'm no programming expert, but it's very important that I can get VLC to send the 20ms packet size!

[Rémi Denis-Courmont]

It's probably relatively easy.

[lordnk]

Hmm.. Any pointers?

I've had a look at the source for the existing packetizers and, not being a C++ person, don't really understand it. However, I do have some experience in programming, and it looks pretty simple - I take it that's why you say probably.

What exactly does VLC pass to the packetizer function? From my understanding of g711 over RTP, we should take just a 20ms sample (160 bytes of g711), give it an RTP header (codec, sync source, etc) and send it out with timestamp+1 for each packet.

If VLC is connecting this function to an audio stream then the function should take 160 bytes of data then cap it with the RTP header, send it out and loop - at least, it seems that simple.

Is it possible to get any more information on how to write a packetizer for VLC?

[Rémi Denis-Courmont]

Yeah, basically you'd need to split the incoming elementary byte stream into chunks of 20 ms, but I don't think there is any documentation on that part of the source code.

[lordnk]

I've managed to write a packetizer which is skeletonned from the rtp_packetize_split function (I figured that was a good place to start). It takes 160 bytes or 20ms of g711 from the buffer, puts in in the payload & sends it to the rtp common packetizer.

I also made some tweaks to the common packetizer for ulaw (taking out marks, compact ssrc & proper timestamping; I am trying to integrate the VLC stream into a proprietary Cisco environment).

The result is that VLC now sends the formatted stream I want, 160 bytes every time - but still at 16.666ms intervals. Randomly messing with the i_dts value, I was able to tweak the timing a bit, but lacking proper documentation makes it a case of trial and error.

[lordnk]

Hey,

I was able to get VLC to stream g711 correctly using an sout chain of transcode:rtp. VLC does not seem to read ulaw from file correctly, so a new demux was needed. In fact, VLC demuxes ulaw as standard pcm, so it reads the file completely off-target.

Creation of a new FrameInfo type for ulaw at the demux stage allowed to control the incoming byte stream chunk size, which then in turn would then send packets to the sout module(s) in the correct size and with the correct timestamp. Creation of a new packetizer for g711 over RTP allowed control of the Source Identifier and Timestamp formats.

The end result on the wire is now:

Code: Select all

0.019982 192.168.1.73 -> 239.1.1.1 RTP PT=ITU-T G.711 PCMU, SSRC=0x852D, Seq=38586, Time=4941928 0.020000 192.168.1.73 -> 239.1.1.1 RTP PT=ITU-T G.711 PCMU, SSRC=0x852D, Seq=38587, Time=4942088 0.019986 192.168.1.73 -> 239.1.1.1 RTP PT=ITU-T G.711 PCMU, SSRC=0x852D, Seq=38588, Time=4942248 0.019990 192.168.1.73 -> 239.1.1.1 RTP PT=ITU-T G.711 PCMU, SSRC=0x852D, Seq=38589, Time=4942408

[niwa3836]

Hi, sounds like you have made some progress with the timing of the packets. i have the same problem.

Although the command:
"C:\Program Files\VideoLAN\VLC\vlc.exe" c:\audio\3.wav --sout "#transcode{acodec=ulaw,channels=1,ar=8000}:rtp{dst=172.30.1.26,port-audio=30000}"
... streams to the phone, and the phone hears it, the timing is all wrong. The delta times look like 0.016 and of course (as you say) should be 0.02.

I have tried a number of ways to overcome this, are you able to shed any more light please? e mail: videolan [at] nigelwarburton.co.uk
many thanks in advance for any suggestions

[niwa3836]

Hi Lordnk?

Are you still on the videolan board? Would be really useful if the fixes that you performed could be embedded into VLC as right now (and as you say) 16ms spacing etc isnt really that helpful. I am hoping that the other devel's at VLC will be able to ensure that it gets updated into the correct builds to benefit others moving forward.
J-B has had a quick look but either wasnt successful or I got the wrong version. If you are still around are you able to share with others the snippets of code changes required to fix?

Many thanks for your help.

[dparkinson]

Was there any resolution to this? I can' get any decent audio streaming to the Cisco phone. Ideally, I'd be able to take an audio feed, transcode it to the relevant format and send it to a Cisco IP Phone seamlessly. Should this work? Thanks in advance for any replies.

[rogerdpack]

0.016 is the default "low res timer" resolution in windows XP, if that helps...(maybe try windows 7?)

[Darr247]

I realize this is an older thread, but I'm having trouble getting VLC to play any u-Law files.

I have some I made from WAV files using http://www.znak.fi/user/pdonner/g711tool/G711Tool.zip which compresses them to .ulw files.
and I have a couple from a cisco VOIP phone system, which have a .raw extension.

VLC won't play any of them, even though it claims to support A-Law and u-Law format files.

So, what do any of you recommend for playing them?

Thanks!

[Rémi Denis-Courmont]

VLC supports the G.711 codecs, including in .WAV files or in RTP sessions. Nobody said it supported G.711 "files".