[asterisk-bugs] [Asterisk 0010653]: SIP (re)INVITE after Channel Hangup

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10653 
====================================================================== 
Reported By:                snafu
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10653
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             09-05-2007 08:05 CDT
Last Modified:              09-05-2007 08:12 CDT
====================================================================== 
Summary:                    SIP (re)INVITE after Channel Hangup
Description: 
Hi there,

i've got some issues with my callback solution in association with
re-invite.

Asterisk takes the callfile from the spooler and make the first Call. 
(definied in call.file). If this Channel is answered, Asterisk jumped into
the context [cb-callee] (also definied in the call.file).
After this (if this channel is also answered), Asterisk attempted a native
bridge between both channels, and send a re-invite to each peer.

That works and thats exactly what i want - BUT...

If one of both callers does hang up the channel, asterisk tried to fetch
back the rtp-stream and sends many (re)INVITEs to the peer who did NOT
hangup.
After 5-6 retries of INVITEs, Asterisk checked that this channel is no
longer needed, and send a BYE packet by itself.  

Even if no 'g' Options were used at die DIAL Command to go on the dialplan
after the destination channel hangup.

Is this behaviour normal, or just a bug? 

I checked out the newest version of your Releases (1.2.24 + 1.4.11 + SVN)
and got always the same behaviour.

Greetz
Kai Moeller

I attached the digest of my extension.conf and sip.conf.
And a detailed ngrep log of the whole call.
(This log is "man in the middle" from my openSER Proxy)

ASTERISK <-----> OpenSER <-------> PSTN Gateway

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

---------------------------------------------------------------------- 
 file - 09-05-07 08:12  
---------------------------------------------------------------------- 
This is expected behavior. The RTP stack does not know whether the channel
will continue or not, so to be safe it reinvites the audio back to Asterisk
in case the user wishes to continue doing things with the channel. If this
didn't happen then applications that deal with the audio would freak out
since the audio would not be coming in, and if audio was played out the
device may reject it since it isn't coming from an expected source. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-05-07 08:12  file           Note Added: 0069963                          
======================================================================