[asterisk-bugs] [Asterisk 0013878]: [patch] Can't record early media after sending a "183 Session Progress".

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Nov 18 16:47:53 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13878 
====================================================================== 
Reported By:                nahuelgreco
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   13878
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Asterisk Version:           1.4.22 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-11-11 14:40 CST
Last Modified:              2008-11-18 16:47 CST
====================================================================== 
Summary:                    [patch] Can't record early media after sending a
"183 Session Progress".
Description: 

Suposse you have the following extension defined in extensions.conf:

    exten => 7,1,Playback(beep,noanswer)
    exten => 7,2,Record(test.wav,0,10,n)
    exten => 7,3,Playback(beep,noanswer)

And you have "progressinband" set to "yes" in sip.conf. Asterisk will send
a
"183 Session Progress" with an SDP and then it will send the RTP audio
for
the first beep. The calling party will hear it correctly, and then the
Record
application will be executed (note the "n" parameter used to not answer
the
call, similar to the "noanswer" one in the Playback app). 

In Asterisk 1.2.x, the Record line works ok, the calling party records to
test.wav successfully, but in 1.4.x and 1.6.x, the Record app will always
generate a 44 bytes .wav file, that is, a void wav (44 bytes are for the
header). This problem also happens if you use the Monitor application.

I think the incoming audio is "silenced" in the sip_read() function at
chan_sip.c, in 1.4.x this code was added at the end of the function:

   /* Only allow audio through if they sent progress with SDP, or if the
channel is actually answered */
   if (fr && fr->frametype == AST_FRAME_VOICE && p->invitestate !=
INV_EARLY_MEDIA && ast->_state != AST_STATE_UP) {
              fr = &ast_null_frame;
   }

The "183 Session Progress" packet can be sent from two functions, from a
couple
of points in sip_write() like in:

   if ((ast->_state != AST_STATE_UP) &&
       !ast_test_flag(&p->flags[0], SIP_PROGRESS_SENT) &&
       !ast_test_flag(&p->flags[0], SIP_OUTGOING)) {
            ast_rtp_new_source(p->rtp);
            transmit_response_with_sdp(p, "183 Session Progress",
&p->initreq, XMIT_UNRELIABLE);
            ast_set_flag(&p->flags[0], SIP_PROGRESS_SENT);
    }

and from sip_indicate(): 

    if ((ast->_state != AST_STATE_UP) &&
        !ast_test_flag(&p->flags[0], SIP_PROGRESS_SENT) &&
        !ast_test_flag(&p->flags[0], SIP_OUTGOING)) {
            p->invitestate = INV_EARLY_MEDIA;
            transmit_response_with_sdp(p, "183 Session Progress",
&p->initreq, XMIT_UNRELIABLE);
            ast_set_flag(&p->flags[0], SIP_PROGRESS_SENT);
            break;
    }


As you can note, p->invitestate is not set to INV_EARLY_MEDIA in
sip_write(),
so if the 183 is sent from that point, then sip_read() will silence any
incoming audio. Because this, Record will not record anything. This can
be
fixed by setting the p->invitestate variable to INV_EARLY_MEDIA in all the
183
sending points. I'm attaching a patch for 1.4.22 and another for 1.6.0.1
doing
that, but I'm not sure if this is a bug or there is a rationale behind
not
setting that variable in these points. At first look it seems an oversight
when
adding the invitestate variable from 1.2.x to 1.4.x, and by only affecting
a rare case like this (recording early media) it becomed unnoticed. 


====================================================================== 

---------------------------------------------------------------------- 
 (0095027) svnbot (reporter) - 2008-11-18 16:47
 http://bugs.digium.com/view.php?id=13878#c95027 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 157503

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r157503 | mmichelson | 2008-11-18 16:47:52 -0600 (Tue, 18 Nov 2008) | 13
lines

Add some missing invite state changes necessary in the sip_write
function. Not setting the invite state correctly on the call was
resulting in the Record application leaving empty files. I also
have updated the doxygen comment next to the declaration of the
INV_EARLY_MEDIA constant to reflect that we also use this state
when we *send* a 18X response to an INVITE.

(closes issue http://bugs.digium.com/view.php?id=13878)
Reported by: nahuelgreco
Patches:
      sip-early-media-recording-1.4.22.patch uploaded by nahuelgreco
(license 162)
	  Tested by: putnopvut

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=157503 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-18 16:47 svnbot         Checkin                                      
2008-11-18 16:47 svnbot         Note Added: 0095027                          
======================================================================




More information about the asterisk-bugs mailing list