Asterisk blocking RTP H264 packets

1
votes

I have a network set up with 2 UACs behind a NAT (one is Jitsi and the other is my own UA coded in C with SIP support). Asterisk is set up on a public IP.

In sip.conf I have the following for both UACs: nat=yes directmedia=no

I then execute my code which calls the Jitsi client. I answer via Jitsi and everything seems great. Asterisk provides each UAC an RTP host/port to send video to via an SDP packet which I've parsed appropriately (audio is not included in this session). Each user agent begins transmitting RTP packets.

Here's where the problem occurs: Asterisks starts printing out

"Got RTP packet from XX.XXX.XX.XXX:XXXXX (type XX, seq XXXXX, ts XXXXXx, len XXXXXX)"

repeatedly from both UACs but never actually sends any of the RTP packets anywhere (I would expect "Send RTP ....").

I've tested my H264 RTP code through a QuickTime Broadcasting Server and the packets properly decode on the local network through various media players. My SIP call seems to have no problems connecting and Asterisk never prints out any Warnings or Errors in the console.

I cannot for the life of me figure out why Asterisk is not forwarding the RTP packets. Any help would be appreciated.

2
sipblockingh.264asteriskrtp
Have you upped the verbosity of the Asterisk logging to see if it gives any hints? It used to be something like core set verbose 5 and/or core set debug 5. It's been a while since I've used Asterisk though so the command format could have changed. – sipsorcery
I run asterisk via asteriks -rvvvvvvvvvvv. I've scoured the debug output and as far as I can tell there are no problems with how the call is being established. – Awesome-o
There also used to be an rtp debug console command that blurted out log messages for every RTP packet that traversed the server. – sipsorcery
Yup, it's rtp set debug on/off/ip. That's how I'm getting the "Got RTP packet from ...." console message. – Awesome-o

2 Answers

1
votes

First, Asterisk doesn't "hold onto" RTP packets. There are three ways in which two SIP UAs can be bridged:

  1. Local bridge - the RTP traffic flows through Asterisk, but is not interpreted by Asterisk. In this case, each UA directs its RTP to Asterisk, and Asterisk retransmits the RTP to each UA. A minimal amount of decoding is done.
  2. Remote bridge - in this case, signalling is still handled between each UA and Asterisk, but Asterisk renegotiates the destination of the RTP with each UA to be the other corresponding UA. In the end, each UA sends its RTP to the other UA directly, while sending the SIP signalling information to Asterisk. This minimizes the load on Asterisk, as no RTP traffic directly goes through it.
  3. Native bridge - similar to a local bridge, the RTP traffic from a UA flows into Asterisk. Asterisk fully decodes the RTP into audio frames and manages the transmission of the audio frames. This occurs when Asterisk has to "understand" the contents of the RTP traffic, such as when using features.conf for DTMF transfers.

The directmedia setting informs Asterisk that the UAs optimally want to send their media between each other, and bypass Asterisk. It will attempt to send the necessary re-INVITEs to set that scenario up, once the call has been established by both UAs.

Since you have directmedia enabled for both of your UAs, Asterisk will attempt to place them in a remote bridge. It may not succeed, depending on a number of factors, but in general, it will expect that it is not "in the loop" with respect to RTP being sent back and forth between the UAs. This would explain why it isn't forwarding the RTP traffic it receives from one of its UAs.

I would suspect, since Jitsi handles this setting well, that the UA you wrote is not honoring the new destination IP address in the SDP of the re-INVITE Asterisk sent to it, and is instead continuing to send the RTP to Asterisk when it should instead be sending it directly to the Jitsi UA.

0
votes

It seems I needed to use STUN in order to find my public IP address.

  1. I switched from Asterisk to FreeSWITCH. Though this did not solve my problem, I found FreeSWITCH much easier to configure and debug which helped in my search.

  2. Turns out that neither FreeSWITCH nor Asterisk really care what IP address you provide them during a SIP session, they'll simply use the IP address/port that a packet is received on (via the IP header) for communication. This confused me because I could make a call between 2 UACs but after a call was answered the audio/video media would never arrive at the correct destination. Turns out RTP implementations will use the IP address provided in the SDP message when setting up a media stream, regardless of what IP address SIP was using for its communication.

In the end, I used STUN to discover the public IP/port for the calling UAC and inserted this correct IP/port combo into the SDP message. Subsequently when the answering UAC (Jitsi) set up its media stream it now had the correct IP/port combo to send/receive media from.