From the report you can see that the command line outputs some information about opening the input file then “freezes” after
“[udp @ 0000002c748241e0] end receive buffer size reported is 65536”.
The command line will stay that way indefinitely until I enter ctrl+c (q doesn’t work), after which FFmpeg says there were 0 bytes read/encoded, and the output file produced is empty/unplayable.
Using Wireshark, I have confirmed that there is traffic coming through port 32760 — packets using the RTP protocol and g.711U payload type, as expected. I right-clicked on one, did “Decode As” RTP, then Analyzed and Saved the data as a "synchronized forward stream audio” in the .raw format. Using the above command with the audio file as the input instead of an RTP stream, I am able to output an mp3 that sounds pretty good.
I’m very new to FFmpeg/working with audio streams and I don’t know why the command works with the saved audio from Wireshark but not with the live stream. I also used gdb  and a debug version of FFmpeg  to provide a backtrace  of the command in case the output is helpful to anyone.
I would appreciate any light that can be shed on this problem!
Thanks very much,
 ffmpeg version "N-86996-g931c0ac95c-Reino" cross-compiled for Windows 64 w/ pthreads and debug=3 enabled (can share file/give more info if needed)
 “live-rtp-g711-toMP3-REPORT.log” & “live-rtp-g711-toMP3.mp3” (attached)
 I can supply the .raw audio from Wireshark if needed
 gdb version 7.1.9 for Windows 32 & 64 (can share file/give more info if needed)
 ffmpeg_g version "N-86996-g931c0ac95c-Reino" cross-compiled for Windows 64 w/ pthreads and debug=3 enabled (can share file/give more info if needed)
 “live-rtp-g711-toMP3-BACKTRACE.txt” (attached)