[Home]

Summary:ASTERISK-10243: SIP (re)INVITE after Channel Hangup
Reporter:Kai Moeller (snafu)Labels:
Date Opened:2007-09-05 08:05:42Date Closed:2011-06-07 14:08:19
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-CLI.txt
( 1) callfile.txt
( 2) extensions.conf
( 3) ngrep-trace.txt
( 4) sip.conf
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


****** STEPS TO REPRODUCE ******

Enable reinvite for the peers who are getting involved.
Initiate a CallBack via Callfile.
Let Asterisk Bridge these Channels.
Do a Hangup on one of these Channels.

Take a Look @ your Sniffer. - And see after hangup many re-invites.


Comments:By: Joshua C. Colp (jcolp) 2007-09-05 08:12:27

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.