SIP Question – Early Audio One-way Or 2-way?

Home » Asterisk Users » SIP Question – Early Audio One-way Or 2-way?
Asterisk Users 7 Comments

Hi SIP Gurus,

I’ve tried to find the relevant RFCs, but am struggling. I can find the odd opinion online, but was wondering if anyone could give a definitive answer.

If a SIP call is initiated (INVITE) and receives either a “180 with SDP”, or a “183 with SDP”, then the remote party will start to send audio for the inband-ringing. Asterisk then passes this audio, and it is correctly heard by the caller.

At present, Asterisk will also start to pass back any handset audio in return, in theory allowing a conversation to occur on an unanswered channel if an endpoint were designed to allow this (free phonecalls here we come!).

My question:

1) Asterisk block outbound audio between the 183 Progress and the 200
OK packets?
2) Replace any outbound audio with silence?
3) Replace outbound audio with a special NULL RTP of some sort? Does that exist?
4) Allow any audio to be sent regardless?

I have implemented 1) at present on our test rig, but the lack of outbound RTP causes issues with firewall state not being set-up to allow the inbound audio. I am not sure how hard/easy it would be to do
2) as you’d need to create silence of the correct duration to replace each audio frame.

Thoughts please?

Many thanks, Steve

7 thoughts on - SIP Question – Early Audio One-way Or 2-way?

  • hi,

    you can simply avoid this by using local ring r option in dial command. azterisk pass local ring voice to caller and will not bridge b leg audio until b leg is answered.iin Regards,

    Faisal Hanif
    (sent from phone)

    Steve Davies wrote:

  • Nice thought, but what if there is a useful reason for the progress audio? If it is sent we want to hono[u]r it, and if it is not, we expect a “180 ringing”, and let the SIP device generate the tone, rather than send an unwanted audio stream to use up bandwidth 🙂

    For example, some UK ISDN services will give a useful call failure message by sending a progress-frame, followed by some audio. DAHDI and SIP handle this nicely with a 183 progress message, and pass on the message on the un-answered SIP channel.

    Regards, Steve

  • You can create trunk/route specific dial command parameters.


    Faisal Hanif

    —–Original Message—

  • 24 aug 2012 kl. 16:18 skrev Steve Davies :

    First, because of Asterisk’s RTP implementation we have to send some RTP packets at this point. You could mute the calling channel before calling and unmute the channel at answer if needed, but normally sending audio won’t hurt. A normal user should not be able to send early media on a pstn-like installation where you bill the calls, so there should be little risc of two-way conversations before an answer.

    In some cases you have to let the caller send DTMF (the famous fed ex example) in early media, so we can’t block any media by default in Asterisk.

    Using the “r” option in dial causes a lot of issues, since you can still get busy or congestion when you have early media, so that is not a good solution.


    * The New Edvina SIP Masterclass – Stockholm and Miami this fall!

  • Excellent information as always Olle. Many thanks.

    My intention is to make the early-audio prevention in SIP a little more harsh, such that if SIP receives audio before a 183 or 200 is received, it is dropped.

    This fixes the case where “useless” early-audio is received from a non-SIP (eg ISDN) technology, and can cause an onward node to auto-enable early audio mode, causing silent ringing and other broken behaviours.

    Cheers, Steve

  • 31 aug 2012 kl. 13:13 skrev Steve Davies :

    This is one of my pet issues. THe problem today is that many gateway vendors ALWAYS send 183 with sdp, regardless if it’s a ring tone or a service provider message. If you kill the 183, service provider messages will disappear. My recommendation (which I’ve mentioned in tons of mails and blog entries) is to send
    180 ringing with SDP for ring tones and 183 for other messages. That way I could kill the 180 SDP in a Kamailio proxy before it hits the Asterisk server. In reality today, by killing 183 you will also block important information for the caller, like “this subscriber has a new number”.


    * The New Edvina SIP Masterclass – Stockholm and Miami this fall!

  • I have 2 similar scenarios. One like yours is a SIP provider who interchangeably uses 180 with sdp, 183 with sdp or 180 no sdp to indicate ringing. There seems to be no logic, so we have to honour all of those cases when they happen. Asterisk handles this already.

    The case I am now killing can be caused by a SIP to ISDN call where the ISDN provides a “RINGING” response which becomes 180 no sdp, but the ISDN then proceeds to send early audio regardless. Asterisk will currently pass that audio even though the SDP exchange is incomplete, by using the SDP in the initial INVITE to send one way audio. This is then propagated along the call chain and is most inconvenient.

    I think I have a solution, currently in 1.6.2 and 1.8, and if you think it is legitimate as a change to block that unexpected early audio, I can put the patch on jira.

    Regards, Steve