Summary:	ASTERISK-15489: Asterisk manage forked calls as reinvite
Reporter:	orante (tucceri)	Labels:
Date Opened:	2010-01-22 09:56:49.000-0600	Date Closed:	2011-06-07 14:08:25
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) log_forkd_rejected_from_asterisk.txt
Description:	Forked calls by remote server are managed as reinvites -> 2nd is rejected. UAC -> Remote server     +--> to lagacy phone calls +-> Asterisk                     (without advanced   |                          |       services            |                          |       or gateway          |                          |       to PSTN features)   |                          |                           +----> voicemail to catch unanswered state
Comments:	By: Leif Madsen (lmadsen) 2010-01-22 10:59:19.000-0600 Please provide enough information that describes the call flow better along with configuration information in order to reproduce this issue. If you're describing an issue with how SIP is being handled, you must provide the sip trace and sip history along with console output showing the issue as per the bug guidelines. By: orante (tucceri) 2010-01-27 07:07:59.000-0600 Ok, the attached file "log_forkd_rejected_from_asterisk.txt" contains the detailed description and logs. By: orante (tucceri) 2010-01-27 07:17:46.000-0600 I add a note... [Jan 27 06:28:44] NOTICE[20781]: chan_sip.c:12817 handle_response_peerpoke: Peer 'called' is now Reachable. (32ms / 2000ms) mean that the UAC is now reachable; the tests are start here. I've called from SER the route with the forking and .. the informations attached. By: Leif Madsen (lmadsen) 2010-01-29 15:22:18.000-0600 I don't understand what the actual issue is here. This looks like its doing exactly what it should be doing. There is a timeout of 20 seconds after the ringing, and Asterisk is Declining the call because of that... Please explain further of what you think the issue is here. By: Leif Madsen (lmadsen) 2010-02-03 14:21:16.000-0600 This looks to be expected behaviour based on the way the dialplan is configured. Issue closed.