asterisk

Commit Graph

Author	SHA1	Message	Date
Terry Wilson	b42c6cab17	Revert early destruction of RTP sessions Some code improperly assumes that the sessions are still there, so revert the change until I can find all of them and fix them. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276206 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	cb160a12b0	Destroy RTP fds when we schedule final dialog destruction Since we are only keeping the dialog around for retransmissions at this point and there is no possibility that we are still handling RTP, go ahead and destroy the RTP sessions. Keeping them alive for 32 past when they are used is unnecessary and can lead to problems with having too many open file descriptors, etc. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275998 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	cd4ebd336f	Add IPv6 to Asterisk. This adds a generic API for accommodating IPv6 and IPv4 addresses within Asterisk. While many files have been updated to make use of the API, chan_sip and the RTP code are the files which actually support IPv6 addresses at the time of this commit. The way has been paved for easier upgrading for other files in the near future, though. Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne for their hard work on this. (closes issue #17565) Reported by: russell Patches: asteriskv6-test-report.pdf uploaded by russell (license 2) Review: https://reviewboard.asterisk.org/r/743 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	a1fe641a38	retransmit response to BYE requests until timer J expires According to RFC 3261 section 17.2.2, which describes non-INVITE server transaction, when a dialog enters the Completed state it must destroy the dialog after Timer J (T164) fires. For a BYE transaction Asterisk terminates the dialog immediately during sip_hangup() when it should be waiting T164 ms. This results in some odd behavior. For instance if Asterisk receives a BYE and transmits a 200ok in response, if the endpoint never receives the 200ok it will retransmit the BYE to which Asterisk responds with a "481 Call leg/transaction does not exist" because the dialog is already gone. To resolve this I made a function called sip_scheddestroy_final(). This differs slightly from sip_schedestroy() in that it enables a flag that will prevent the destruction from ever being rescheduled or canceled afterwards. It also prevents the pvt's needdestroy flag from being set which triggers the destruction of the dialog within the do_monitor thread(). By using this function we are guaranteed destruction will not occur until the scheduled time. This allows Asterisk to respond to any possible retransmits for a dialog after we process the initial BYE request for T1*64 ms. Other changes: I removed two instances where sip_cancel_destroy is used right before calling sip_scheddestroy. sip_scheddestroy always calls sip_cancel_destroy before scheduling the new destruction so it is completely unnecessary. Review: https://reviewboard.asterisk.org/r/694/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271262 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	e7a5fb5459	Make all of the various rtpqos parameters in this branch available from the CHANNEL function. Also includes a test for retrieving rtpqos parameters, including a NULL RTP driver. Additionally, some further separation of the SIP internal API into headers was necessary. (closes issue #16652) Reported by: kkm Patches: 20100204__issue16652.diff.txt uploaded by tilghman (license 14) Review: https://reviewboard.asterisk.org/r/501/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247124 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago

5 Commits (283f63c594d0c4327c51fdae0587a6a9f1cb15d3)