Bug #5693


no progress tones in yate

Added by laforge over 1 year ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:



We've never had call progress tones from yate in our network and had ignored that until now.

This is the case in
  • any outbound call setup from a phone, where there are no dial tones, alerting tones, etc.
  • calls routed to tone/*

The respective ToneSource() class instances are created and provide the respective quantity of samples. It works for SIP, but not for ISDN.

I think it's related to the Q.931 signaling side. It states:

5.4 In-band tones and announcements

When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS message contains the progress indicator No. 8, in-band information or appropriate pattern is now available.

When tones/announcements have to be provided together with a call state change, then the appropriate message [e.g. for ALERTING, DISCONNECT, etc., (see clause 3)] with progress indicator No. 8, in-band information or appropriate pattern is now available, is sent simultaneously with the application of the in-band tone/announcement.

Actions #1

Updated by laforge over 1 year ago

Indeed, a protocol trace shows no Progress indicator IE in the SETUP ACK, and no explicit PROGRESS message either. Not even the ALERTING contains it.


  • both the ISDNQ931Call::sendProgress and ISDNQ931Call::sendAlerting method add the in-band-info flag of the progress IE if either m_inbandAvailable is set or the earlymedia parameter of the respective outbound SignallingMessage is set
    • m_inbandAvailable acts as a cache; it is set whenever the in-band-info flag is set in inbound Q.931 ALERTING or PROGRESS - or the earlymedia is set in outbound ALERTING or PROGRESS
  • inversely the receive-message-handlers ISDNQ931Call::processMsgAlerting and ISDNQ931Call::processMsgProgress are setting the earlymedia parameter to true.

So we can conclude that the Q.931 library code looks rather sound.


  • contains a SigChannel::msgProgress method which can be used to send PROGRESS via the underlying Q.931/ISUP library
    • there are conditions upon which the earlymedia parameter in the generated Progress or Ringing message is set:
      • if getPeer()->getSource() returns something (we alreay have a peer?)
      • if m_rtpForward is set and both the rtp_forward and media parameters are set
Actions #2

Updated by laforge over 1 year ago

  • Status changed from New to In Progress

the following change in overlapped.php fixes the B-channel early audio durign dialing and also when dialing to tones of the tone/.... module.

 function setState($newstate)
     global $ourcallid;
+    global $partycallid;
     global $state;
     global $collect;
     global $routeOnly;
@@ -79,6 +80,13 @@
        $m->params["maxlen"] = 320000;
        $m->params["notify"] = $ourcallid;
+       $pg = new Yate("call.progress");
+       $pg->SetParam("id", $ourcallid);
+       $pg->SetParam("peerid", $partycallid);
+       $pg->SetParam("rtp_forward", true);
+       pg->Dispatch();

The rtp_forward parameter is a bit of a hack here, as this is what enables the earlymedia :/

Actions #3

Updated by laforge over 1 year ago

For conferencing the problem is that there never is any CONNECT in the call up to that point. Nobody is issuing the call.answered message :/

Actions #4

Updated by laforge about 1 year ago

  • Status changed from In Progress to Stalled
Actions #5

Updated by laforge 3 months ago

  • Assignee deleted (laforge)

adding sur5r to the watcher list as he might know a bit or two about yate.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)