Bug #5693
open
no progress tones in yate
Added by laforge over 1 year ago.
Updated 5 months ago.
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.
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::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.
modules/server/ysigchan.ccp¶
- 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
- 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 :/
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 :/
- Status changed from In Progress to Stalled
- Assignee deleted (
laforge)
adding sur5r to the watcher list as he might know a bit or two about yate.
Also available in: Atom
PDF
