Configuring Asterisk to Send Early Media (RTP Audio) Before Call Answer for VoIP Compliance Testing


2 views

In VoIP compliance testing scenarios, we often encounter a specific requirement where the called party's audio stream must be transmitted before the final SIP 200 OK response. This creates a technical challenge in Asterisk where by default, RTP streams are only established after call answer.

The commonly suggested parameters like directmediasetup=yes, progressinband=yes, and prematuremedia=yes don't fully solve this because:

  • They typically only work for in-band progress tones
  • Don't force immediate RTP media streaming
  • Often depend on the remote endpoint's behavior

For Asterisk 1.8.x, we need to implement a custom dialplan solution that forces early media streaming. Here's a working example:

[outbound-trunk]
exten => _X.,1,NoOp(Starting outbound call with forced early media)
same => n,Progress()
same => n,Set(SIP_HEADERS(add)=P-Early-Media: sendrecv)
same => n,Dial(SIP/trunk/${EXTEN},60,M(setup_early_media))
same => n,Hangup()

[macro-setup_early_media]
exten => s,1,NoOp(Setting up early media channel)
same => n,Set(CHANNEL(hangup_handler_push)=early_media_hangup,s,1)
same => n,Set(FAX_DETECT=off)
same => n,Set(__SIPCHANINFO=yes)
same => n,Return()

[early_media_hangup]
exten => s,1,NoOp(Cleaning up early media resources)
same => n,UserEvent(MediaCleanup,Channel: ${CHANNEL})
same => n,Return()

In your sip.conf for the trunk, add these critical parameters:

[trunk]
type=peer
host=your.provider.com
context=outbound-trunk
directmediasetup=yes
progressinband=yes
prematuremedia=yes
ice_support=no
media_encryption=no
aggregate_mwi=no

To verify if early media is working:

  1. Run asterisk -rvvvvv for debug output
  2. Check SIP packets with Wireshark for early INVITE with SDP
  3. Monitor RTP streams with rtp debug ip port

When dealing with test simulators:

  • They often expect immediate media without 183 Session Progress
  • May require specific codec negotiation first
  • Sometimes need custom SDP attributes in the initial INVITE

For these cases, you might need additional dialplan modifications:

exten => _X.,n,Set(SIP_HEADERS(add)=P-Early-Media: sendrecv)
exten => _X.,n,Set(SIP_HEADERS(add)=Allow-Events: telephone-event)
exten => _X.,n,Set(SIP_CODEC=ulaw)

If you can upgrade to Asterisk 13+, the solution becomes simpler with the send_early_media dialplan function:

exten => _X.,n,Set(SEND_EARLY_MEDIA=yes)
exten => _X.,n,Dial(SIP/trunk/${EXTEN},,M(setup_early_media))

During VoIP compliance testing, some test systems (especially simulators) require audio transmission before the remote party sends a 200 OK response. In standard SIP calls, RTP streams typically start only after call establishment. This creates a one-way audio scenario where:

  • The called party can hear audio from the caller
  • The caller cannot hear anything until answer

For Asterisk 1.8.11 (and newer versions), several parameters interact with early media behavior:

; sip.conf settings that affect early media
[general]
prematuremedia = yes
progressinband = yes

[your_trunk]
directmediasetup = no
canreinvite = no

The prematuremedia setting controls whether Asterisk will:

  1. Process early media from the far end
  2. Allow sending audio before call answer

Example dialplan implementation:

exten => _X.,1,Progress()
same => n,Playback(demo-congrats)
same => n,Dial(SIP/trunk/${EXTEN},,T)

When enabling pre-answer media, ensure your network:

  • Allows UDP packets before SIP dialog establishment
  • Has proper QoS markings for early media packets
  • Firewalls don't block "orphaned" RTP streams

Use these Asterisk CLI commands to verify early media:

sip set debug on
rtp set debug on
core set verbose 5

Look for these key indicators in logs:

RTP Transmission started before SIP 200 OK
Early audio packet detected from 192.168.1.100:1234

In newer versions (13+), consider using the sendrpid and trustrpid parameters with early media:

; Improved early media handling
[your_trunk]
sendrpid = pai
trustrpid = yes
earlymedia = allow

Verify your configuration works by:

  1. Calling a test number that answers without 200 OK
  2. Using tcpdump to confirm RTP flows both ways
  3. Checking packet timing in Wireshark