Summary:	ASTERISK-17929: Attended transfer broken - 481 Call/Transaction Does Not Exist
Reporter:	Maciej Krajewski (jamicque)	Labels:
Date Opened:	2011-05-26 09:49:30	Date Closed:	2012-01-20 16:33:53.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:	1.8.4	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) console.log ( 1) mk2.cap
Description:	After migrating from Asterisk 1.4 and 1.6 to 1.8 I've found that there is a problem with attended transfer, when asterisk gets INVITE (REPLACES) it answers 481, situation happens all the time. I've attached cap file and pasted logs. ****** ADDITIONAL INFORMATION ******  == Using SIP RTP CoS mark 5    -- Executing [500990990@inc:1] NoOp("SIP/tester1-00000004", "Polaczenie przychodzace 500990990,0508381197") in new stack    -- Executing [500990990@inc:2] Set("SIP/tester1-00000004", "GROUP(pstn)=inc") in new stack    -- Executing [500990990@inc:3] GotoIf("SIP/tester1-00000004", "0?40:4") in new stack    -- Goto (inc,500990990,4)    -- Executing [500990990@inc:4] Set("SIP/tester1-00000004", "RANDX=56") in new stack    -- Executing [500990990@inc:5] Set("SIP/tester1-00000004", "LOOPX=0") in new stack    -- Executing [500990990@inc:6] Set("SIP/tester1-00000004", "i=0") in new stack    -- Executing [500990990@inc:7] Set("SIP/tester1-00000004", "i=1") in new stack    -- Executing [500990990@inc:8] Set("SIP/tester1-00000004", "j=0") in new stack    -- Executing [500990990@inc:9] While("SIP/tester1-00000004", "1") in new stack    -- Executing [500990990@inc:10] Dial("SIP/tester1-00000004", "SIP/500990990@sip1,,,") in new stack  == Using SIP RTP CoS mark 5    -- Called 500990990@sip1    -- SIP/sip1-00000005 answered SIP/tester1-00000004    -- Locally bridging SIP/tester1-00000004 and SIP/sip1-00000005 [May 26 16:49:20] WARNING[25152]: chan_sip.c:3527 retrans_pkt: Retransmission timeout reached on transmission 2d63249273bad34d02dcd2256c950db6@10.10.10.181 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 31999ms with no response
Comments:	By: Leif Madsen (lmadsen) 2011-05-27 10:55:57 A SIP trace from the Asterisk console along with SIP history is already required when submitting SIP issues. By: Maciej Krajewski (jamicque) 2011-05-29 16:34:59 I've attached the requested log with SIP history. By: Maciej Krajewski (jamicque) 2011-11-09 18:42:00.583-0600 On newest 1.8.7.1 problem still exist. By: Maciej Krajewski (jamicque) 2011-11-11 10:18:40.765-0600 in 10-rc1 the same. By: David Woolley (davidw) 2011-12-19 09:36:56.337-0600 Does it happen for call ids in standard format, i.e. without the ":5060".  Whilst this is allowed by the RFC, it is sufficiently unusual that it might cause a mis-parse. By: Maciej Krajewski (jamicque) 2011-12-20 08:02:22.841-0600 Call-ID in "Replaces" header is Sent with ":5060" because asterisk send such call-id with first INVITE. You can see it in attached mk2.cap According to RFC, the proxy sends the replaces the right way - way the call-id was sent by Asterisk. RFC3261: "..The Call-ID header field acts as a unique identifier to group   together a series of messages.  It MUST be the same for all requests   and responses sent by either UA in a dialog.  It SHOULD be the same   in each registration from a UA..." "...Use of cryptographically random identifiers (RFC 1750 [12]) in the   generation of Call-IDs is RECOMMENDED.  Implementations MAY use the   form "localid@host".  Call-IDs are case-sensitive and are simply   compared byte-by-byte...." By: David Woolley (davidw) 2011-12-21 05:59:37.109-0600 The remote system generated the first invite, not Asterisk. I agree it is valid; I was just pointing out that this was the unusual feature about the call that might help in debugging it. By: David Cunningham (dcunningham) 2011-12-28 16:18:17.513-0600 We have a customer with what appears to be this issue. Is there anything we can do to help get it fixed? Thanks. By: Mark Michelson (mmichelson) 2012-01-10 12:00:55.638-0600 I've found the cause of this issue. In Asterisk 1.8, we changed the default setting for the "pedantic" option in sip.conf from false to true. Among other things, this means that we are very strict with how we match dialogs. The INVITE with Replaces header has a to-tag for some reason. Because of that, we interpret the INVITE with Replaces to be part of an existing dialog rather than starting a new one. The fault here is with the user agent sending the INVITE with Replaces (which unfortunately appears to be an older version of Asterisk, judging by the User-Agent header). It should not include a to-tag in the INVITE it sends. To remedy the issue, set "pedantic=false" in the general section of sip.conf and reload chan_sip. Let us know if this fixes the problem for you. I strongly suspect it will. By: Maciej Krajewski (jamicque) 2012-01-10 15:17:23.858-0600 thanks it helped! By: Richard Mudgett (rmudgett) 2012-01-20 16:33:53.407-0600 Reporter confirmed that changing the configuration fixed the issue.