Summary:	ASTERISK-24486: PJSIP contact rewriting fails to account for TCP timeout
Reporter:	Kinsey Moore (kmoore)	Labels:
Date Opened:	2014-11-03 13:41:38.000-0600	Date Closed:	2014-12-12 14:26:59.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_pjsip Resources/res_pjsip_nat
Versions:	12.6.1 13.0.0-beta3	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	This issue affects endpoints where contact rewriting is enabled and the transport being used is reliable (TCP or TLS). If these conditions are met, the call will operate properly until the underlying transport hits an inactivity timeout around 30 seconds at which point the reliable transport will be torn down. Once this happens, Asterisk is unable to send communications to the remote endpoint to tear down the call which can leave the call dangling on the remote server for an unspecified period of time.
Comments:	By: Kinsey Moore (kmoore) 2014-11-03 13:47:16.639-0600 Also of note is that this can only happen when the initiating connection is inbound. A partial mitigation is to "undo" the effects of contact rewriting once the underlying transport has been torn down so that Asterisk may attempt to communicate with the remote server using the original contact information. In the case where this was experienced, the original contact information was valid and accessible. This will not be true in all cases, but represents an improvement in functionality for a subset of cases. By: Matt Jordan (mjordan) 2014-12-12 14:26:59.518-0600 With the keep alive messages put into the PJSIP stack, this issue essentially no longer happens. Given the complexity of trying to figure out who a request should be sent to when a TCP connection breaks and a UDP transport is chosen, this issue is no longer really worth trying to "fix" (particularly when a different method already "fixed" it by preventing the TCP connection from breaking in the first place).