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/[EMAIL PROTECTED],,) 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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
