[Home]

Summary:ASTERISK-00518: SIP Transfers - REFER & Replaces
Reporter:spr (spr)Labels:
Date Opened:2003-11-11 17:11:17.000-0600Date Closed:2011-06-07 14:05:17
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13-Nov-03-Call-1.eth
( 1) 13-Nov-_03-Debug-1.txt
( 2) SuperXFerTrace.eth
( 3) with_canreinvite_off.eth
Description:There appear to be two problems with the current way that Asterisk handles transfers. I am using the latest CVS version as of 11-11-2003.

I have attached an Ethereal trace and will refer to line numbers from that trace to demonstrate the issues.

Erroneous INVITE after REFER:

Line 41 is an INVITE to 2010 which is the phone that just placed sent the REFER. There is no reason to send an INVITE to this phone.
Line 42 is a BYE. It has the same call-id as the INVITE so I think that it should really be a CANCEL since the call has not been answered. If the above INVITE was not sent to begin with, this is moot.

Missing Replaces in transfer INVITE:

In a REFER message, there is always a Refer-To header.  In a supervised transfer, part of this header is a Replaces tag that specifies the Call-ID that the transfered call is to replace.  This Replaces tag must be replicated in the resulting INVITE to tell the receiving endpoint that the call is to replace the call that it is currently on rather than treating it like a new call and playing call waiting.

Line 43 show the REFER packet with the Refer-To with the Replaces.

Line 47 is the resulting INVITE.  The Replaces is not there.

****** ADDITIONAL INFORMATION ******

About the Trace:
192.168.201.39 - transfered to
192.168.201.40 - initial calling party
192.168.201.61 - transferring party
192.168.201.43 - Asterisk

Call Scenario:
40 calls 61
61 hookflashes and calls 39 (40 is now on hold)
39 is answered (61 and 40 can talk; 40 still on hold)
61 hangs up (Completes supervised transfer)
This should connect 40 to 39

Feel free to email me if further explainations are needed or if you need me to try any patches.
Comments:By: Mark Spencer (markster) 2003-11-11 17:49:02.000-0600

I think i found the bug, it had to do with native bridging.  Can you confirm (a) that this fix in cvs works and if not (b) that the problem goes away if canreinvite=no.
By: spr (spr) 2003-11-12 17:36:15.000-0600

I put another Ethereal trace up. It shows an INVITE (Line 44 of the trace) being sent from the Asterisk .43 to .39 which is the transfered-to phone after the REFER. .39 sees this as a new call and plays call waiting.  It does this becuase the Call-ID of the new INVITE is different from the Call-ID of the INVITE that started the call that it is on (Line 34 of the trace) call that is is currently on and because the Replaces is not in the new INVITE.

From what you have said, in canreinvite=no mode, this INVITE should not be sent; but rather, Asterisk should simply start sending the Audio from the .40 endpoint to the .39 endpoint.

With can reinvite=yes, I would think that you could either send the INVITE with the Replaces tag as the SIP rfc suggest, of send reinvites changing the audio path back to the Asterisk long enough to get complete the transfer and then reinvite again to send the audio point-to-point.

What do you think?
By: spr (spr) 2003-11-12 17:39:18.000-0600

Here are the relevant parts of my sip.conf:

[general]
port = 5060                     ; Port to bind to
bindaddr = 192.168.201.43       ; Address to bind to
reinvite = yes
canreinvite = yes
context = default               ; Default for incoming calls
disallow=all                    ; Disallow all codecs
allow=ulaw                      ; Allow codecs in order of preference

;IPDialog Phones
[2000]
type=friend
secret=1234
host=dynamic
mailbox=2000
reinvite = no
canreinvite = no

[2001]
type=friend
secret=1234
host=dynamic
mailbox=2001
reinvite = no
canreinvite = no

;Mediatrix 1102
[2010]
type=friend
secret=1234
host=dynamic
;mailbox=2010
reinvite = no
canreinvite = no

[2011]
type=friend
secret=1234
host=dynamic
;mailbox=2011
reinvite = no
canreinvite = no
By: Mark Spencer (markster) 2003-11-12 18:17:39.000-0600

It would appear they place a superfluous "%20" at the beginning which is an encoded space, so i've made it properly decode the % stuff, as well as ignore the whitespace that it thus creates at the beginning.  Hopefully now it will get it but if it doesn't i will need ssh access to your machine.  Might help to record debug by enabling debug to console in /etc/asterisk/logger.conf
By: spr (spr) 2003-11-13 09:36:01.000-0600

This gets it a lot closer.  I am attaching another Ethereal and some notes.
By: spr (spr) 2003-11-13 09:38:30.000-0600

Here are the notes that I have made based on the two file that I just uploaded:

Line 17 INVITE from .61 to .43 Destined for .39 Call-ID 05a9f1a08e39bc9d28aa288f6c31b435@192.168.201.43

Line 22 INVITE from .43 to .39 Sent by Asterisk Call-ID 5e884adc51ead36b2d517796580bd78f@192.168.201.43

Line 25 200 OK for the Line 22 INVITE Call-ID matches
Line 27 200 OK for the Line 17 INVITE Call-ID matches

Line 29 REFER from .61 to .43 Telling Asterisk to Relace call from Line 17 with a call from .40 Call-ID matched Line 17 INVITE

Line 30 404 Not found  The Asterisk debug log says:

NOTICE[49156]: File chan_sip.c, Line 3793 (get_refer_info): Supervised transfer requested, but unable to find callid '05a9f1a08e39bc9d28aa288f6c31b435'

Call-ID is ID from Line 17.

edited on: 11-13-03 09:34
By: Brian West (bkw918) 2004-01-26 21:53:31.000-0600

This has been fixed a few weeks back.  If otherwise please let me know.