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

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
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:                     resolved
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
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. 


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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-18 16:47 svnbot         Status                   confirmed => resolved
2008-11-18 16:47 svnbot         Resolution               open => fixed       
======================================================================