Support
2004-Oct-15 06:05 UTC
[Asterisk-Users] Transmit re-INVITE before BYE is sent - why?
I have a question concerning re-INVITEs and how/why Asterisks sends them. On SIP to SIP calls with asterisk set up with canreinvite=yes, after a call is setup, media ip address:ports are renegotiated, 2 way rtp is established, and then one of the parties hangs up by sending a BYE, Asterisk goes through a re-INVITE process before forwarding on the BYE to the other party. I've shown the last part of the call flow (after the first re-INVITE to renegotiate the media stream) below where party A calls party B and after 2 way rtp has been established. Party A Asterisk Party B 5551200 5551212 | | | |<-----2 way RTP Peer to Peer-----| | | | | |<-----BYE-------| | |-----200 OK---->| |<--INVITE-------| | |---TRYING------>| | |---200 OK------>| | |<----ACK--------| | |<----BYE--------| | |----200 OK----->| | In looking through the documentation, chan_sip.c file, associated web sites, configuration files, mailing lists, I have not been successful in finding out why it does this last re-INVITE but it appears that this may be performed as a clean up process allowing asterisk to possibly play a goodbye message or some other recording prior to hangup (rtp is transferred back to *). Is there something in the extensions.conf file that either turns on or turns off this activity. I have found that if you set canreinvite=no, this does not occur, but then * won't release rtp. My entry in extensions.conf is very simple: exten => _5551212,1,Dial(SIP/${EXTEN}@mydomain,,) exten => _5551212,2,Hangup ...and I've even tried taking out the Hangup step, but have not seen a difference. I was looking for a way to allow re-INIVITEs to renegotiate the rtp address:ports but not perform this last re-INVITE before a BYE. Any suggestions? Thanks. Tom Schroer