Summary:ASTERISK-17929: Attended transfer broken - 481 Call/Transaction Does Not Exist
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2011-05-26 09:49:30Date Closed:2012-01-20 16:33:53.000-0600
Versions:1.8.4 Frequency of
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.


 == 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@ 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 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.

"..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.