Bug #5693
openno progress tones in yate
0%
Description
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.
Updated by laforge about 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.
libs/ysig/q931.cpp¶
- both the
ISDNQ931Call::sendProgressandISDNQ931Call::sendAlertingmethod add the in-band-info flag of the progress IE if eitherm_inbandAvailableis set or theearlymediaparameter of the respective outboundSignallingMessageis setm_inbandAvailableacts as a cache; it is set whenever thein-band-infoflag is set in inbound Q.931 ALERTING or PROGRESS - or theearlymediais set in outbound ALERTING or PROGRESS
- inversely the receive-message-handlers
ISDNQ931Call::processMsgAlertingandISDNQ931Call::processMsgProgressare setting theearlymediaparameter totrue.
So we can conclude that the Q.931 library code looks rather sound.
modules/server/ysigchan.ccp¶
- contains a
SigChannel::msgProgressmethod which can be used to send PROGRESS via the underlying Q.931/ISUP library- there are conditions upon which the
earlymediaparameter in the generated Progress or Ringing message is set:- if getPeer()->getSource() returns something (we alreay have a peer?)
- if
m_rtpForwardis set and both thertp_forwardandmediaparameters are set
- there are conditions upon which the
Updated by laforge about 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;
$m->Dispatch();
+
+ $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 :/
Updated by laforge about 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 :/
