ALSA end device can not hear early media (outgoing via PJSIP)

[reasonlin0512]

Hi everyone,
Now I’m trying to use PJSIP protocol with ALSA end device.
My environment is:

Both Device A and B are registered on an outbound SIP server, and the ALSA device is using FAX line to connected on both Device (linux system).

The extensions.conf on device B is configured as:
[incoming]
exten => s,1,Dial(Console/dsp, ${INCOMING_TIMEOUT}, m(${MOH_CLASS}))
same => n,Hangup()

When I make an outgoing call from device A to device B, B start the MOH because the definition in extensions.conf. And device A received 183 Progress information.

I can see the early media is under transmit from device B by capture the network packet using Wireshark, and device A has received RTP packet from device B (same using Wireshark), but Asterisk on device A do not parsing the packet, cause the ALSA device A cannot hear any early media.
Until I answered the call on device B, and Asterisk will bridge two channel via simple_bridge technology.
(this is because I try to play the tt-monkeys.gsm by using PLAYBACK function, and this function will auto answer the call in default, when I add the " noanswer" option, ALSA device A can’t hear any audio from PLAYBACK).

I checked the code (app_dial.c, channel.c, chan_pjsip.c, chan_alsa.c …),
I thought that is because chan_alsa only handle the PCM device read and write, it do not handle any RTP packet from incoming packet.

Does anyone have any suggestion for my situation?

[EkFudrek]

You need to post your dialplan, a meaningful SIP trace and possibly a console log. Another problem could be that chan_alsa is deprecated, i.e. hardly anybody remembers the details.

[cable]

Check that your outbound “Dial” command is not using the “r” flag.

[david551]

I’ve always assumed that the sound card drivers were proof of concept drivers rather than intended for production use.

chan_also doesn’t call snd_pcm_start() until it leaves early media state.

Also you haven’t said anything about your, so called, Outbound SIP server (it is really a back to back user agent or a proxy), although you do say you have captured the early media RTP down stream of it, so it is unlikely to be the cause in this case.