Summary:	ASTERISK-03626: [patch] Consultative transfers between asterisk servers
Reporter:	Terry Wilson (twilson)	Labels:
Date Opened:	2005-03-03 12:19:12.000-0600	Date Closed:	2011-06-07 14:10:32
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) segfault.txt ( 1) sip_debug_from_Veraz.txt ( 2) sip_refer_replaces_rev2.diff
Description:	We currently have a setup with SER acting as a load balancer/registrar for a couple of asterisk boxes.  Both asterisk boxes share the same dialplan/sip configs.  Everything works great, except one very important scenario--consultative transfers where legs of the call are on different asterisk servers. ****** STEPS TO REPRODUCE ****** 1) Transferee calls the transferer via asterisk box 1 2) Transferer puts transferee on hold and begins   consultative transfer to the Transfer target with an   invite that gets forwarded through asterisk box 2. 4) Transferer initiates native SIP transfer with a REFER   that is sent to the Transfer target on asterisk box 2   with an embedded Replaces header containing the Call-ID   of the call between the transferer and the transferee (on   asterisk box 1) in the Refer-To.  The Refer-To also   contains the uri to connect the Transferee at asterisk   box 1. 5) Since asterisk doesn't check the host portion of the   Refer-To, it looks for the Call-ID locally.  It doesn't   find it, so it sends a 404 and the transfer fails. ****** ADDITIONAL INFORMATION ****** What I think should happen: 5) Asterisk checks the host portion of the Refer-To in the REFER and determines that is non-local.  And sends an INVITE containing a Replaces header containing the Call-ID to asterisk box 1. 6) Asterisk box 1 recieves an INVITE with the Replaces header and looks up the sip call associated with it. 7) Asterisk box 1 then sends a BYE to the transferer and asterisk box 2 sends the NOTIFY that the transfer succeeded to the transferer. 8) The transferer will then send a BYE to asterisk box 2 9) Everything is happy. For more information on how this should work, see http://www.ietf.org/proceedings/02nov/I-D/draft-ietf-sip-cc-transfer-05.txt I did the best I could to adapt it to the way that asterisk would work in this situation.  Attached is an ngrep of the SIP traffic as seen from the SER box (since all traffic is Record-Routed through it).  I made this a feature request instead of a bug since I don't know if a "draft violation" is quite the same as a "protocol violation"--even if asterisk does have limited support for the draft already.
Comments:	By: Anthony Minessale (anthm) 2005-03-14 18:13:58.000-0600 Here is stage1, I translated get_refer_info() into something I could comprehend.  This is a step in the right direction at least.  The next step is to make the handling of an invite look for and react to the Replaces: header. Disclaimer on file. edited on: 03-14-05 18:15 By: Mark Spencer (markster) 2005-03-14 23:55:07.000-0600 Refactoring added to CVS with the following changes: 1) Actually lock iflock in "get_sip_pvt_byid_locked" 2) Minor formatting adjustments to opening braces / function beginnings 3) Make comments consistent with the rest of the code where appropriate and more accurate. 4) In attempt transfer, !p1->owner || !p2->owner is not the failure of having them on different machines.  If that's the case, we would either not have p1 or not have p2. Thanks! By: Anthony Minessale (anthm) 2005-03-15 15:37:38.000-0600 This next one tries to react properly to a Replaces header but I need some feedback on it . By: Anthony Minessale (anthm) 2005-03-24 17:20:22.000-0600 latest attempt to handle replaces By: Anthony Minessale (anthm) 2005-03-25 08:46:15.000-0600 Closest incarnation to date to actually performing the task please test/analyze By: Anthony Minessale (anthm) 2005-03-25 08:48:49.000-0600 <opinion type=arrogant objectivity=slanted content=true>SIP IS EVIL!</opinion> By: Terry Wilson (twilson) 2005-03-25 08:53:17.000-0600 :-)  I will test when I get to work this morning.  Thanks! <opinion type=humble objectivity=slanted content=true> SIP isn't evil in itself (although a bit complex), but trying to apply its model to "The Asterisk Way(TM)" is a royal PITA... :-) </opinion> By: Anthony Minessale (anthm) 2005-03-26 18:54:59.000-0600 doh forgot some of the code added the real patch. By: nirsim (nirsim) 2005-04-06 14:11:58 I'm not entirely sure if it relates to this bug or not, but this is the closest thing that I could find in here that looks like the issue I'm seeing. I'm experiencing issues with a VERAZ interop from Asterisk. I've got an Asterisk box that on one side receives calls via IAX2 and then sends them into a VERAZ SoftSwitch via SIP, utilizing ulaw as the codec. Call setup appears to be negotiated correctly, however, after a period of 69-70 seconds exactly, the call disconnects. It appears as if the VERAZ is sending the SIP BYE directive. However, when I connect a cisco in stead of the Asterisk, utilizing the same IP number, all seems to work fine. I've gone over the bugs in SIP here, and this bug (3710) looked like it relates. I applied the patch, but the behaviour still remains. I've uploaded a file called sip_debug_from_Veraz.txt which is a 'sip debug' and 'logger debug' from Asterisk, before and after applying the patch. I hope someone can take a wiff at this, as it is currently blocking some project on my side. By: Terry Wilson (twilson) 2005-04-07 14:04:13 Have talked to anthm directly about this, but thought I'd go ahead and update the bug.  Most recent patch is definitely closer, but isn't quite there.  The INVITE that is sent witht the replaces header has no Contact: or From: set so it won't get routed into the correct context on the remote box.  We're closer, but just not quite there yet.  Even if we worked around it some way Caller-ID would be off. By: Anthony Minessale (anthm) 2005-04-08 19:15:03 WOOHOO! rev2 works!!! it may have some oversights in it though, sip being mind numbing and all,  so sip gurus please examine the code! =D edited on: 04-08-05 19:16 By: Terry Wilson (twilson) 2005-04-08 23:32:06 It seems to work if I am doing the transfer from a Cisco phone, but not if I am doing the transfer from a Polycom phone.  I will attach dumps to show the differences when I get back into the office. By: Daniele Gallina (gallysoft) 2005-04-09 03:28:36 I tryed rev2 on Asterisk CVS-HEAD-04/09/05-09:27:15 and when I try to transfer a call with Grandstream, Asterisk tell me:    -- Executing Dial("SIP/20012-7c4b", "SIP/3487996384@messagenet") in new stack    -- Called 3487996384@messagenet    -- SIP/messagenet-c174 is making progress passing it to SIP/20012-7c4b    -- SIP/messagenet-c174 answered SIP/20012-7c4b    -- Attempting native bridge of SIP/20012-7c4b and SIP/messagenet-c174    -- Started music on hold, class 'default', on SIP/messagenet-c174    -- Executing SetCallerID("SIP/20012-12ee", ""Gallina Daniele" <20012>") in new stack    -- Executing Dial("SIP/20012-12ee", "SIP/20011|120|tT") in new stack    -- Called 20011    -- SIP/20011-88a1 is ringing    -- SIP/20011-88a1 answered SIP/20012-12ee    -- Attempting native bridge of SIP/20012-12ee and SIP/20011-88a1    -- Started music on hold, class 'default', on SIP/20011-88a1 Apr  9 10:25:25 NOTICE[28367]: chan_sip.c:3172 copy_header: No field 'Call-ID' present to copy Apr  9 10:25:25 WARNING[28367]: chan_sip.c:9399 restart_monitor: Cannot kill myself Segmentation fault Before the patch it say me: Supervised transfer requested, but unable to find callid '48b5cce3d8e0d84f@192.168.0.53' By: Anthony Minessale (anthm) 2005-04-10 13:58:17 Dont bother with attached console output unless debug log is on too and please attach a gdb output (I'm gonna be gone all week, oej or someone PLEASE look at this it's SO close to being done!) edited on: 04-10-05 13:59 By: Daniele Gallina (gallysoft) 2005-04-11 01:43:35 anthm, I don't understand you. Have I to do anything??? By: Russell Bryant (russell) 2005-04-11 02:06:54 gallysoft - What anthm is asking from you is to turn on "sip debug" for the console output.  Also, after the seg fault, you need to get a backtrace from the core dump with gdb. gdb /path/to/asterisk /path/to/core.<pid> Once gdb has started, type "bt" and "bt full" and provide the output. Thanks By: Daniele Gallina (gallysoft) 2005-04-11 02:28:21 Ah, ok. Sorry but I am not a Linux Guru ;-) I have attached segfault.txt that contains the sip debug. But, if i do: gdb /usr/sbin/asterisk /var/run/asterisk.pid it say me: "/var/run/asterisk.pid" is not a core dump: File format not recognized What's wrong? By: Anthony Minessale (anthm) 2005-04-11 07:49:29 also edit /etc/asterisk/logger.conf to say console => notice,warning,error,debug and the gdb command is not gdb /usr/sbin/asterisk /var/run/asterisk.pid it's gdb /usr/sbin/asterisk /tmp/core.xyz where core.xyz is the most recently created core file in /tmp By: Anthony Minessale (anthm) 2005-04-11 07:57:35 All i can tell so far from looking at segfault.txt is the transmit_notify_with_sipfrag is being called with blank headers. The same transcript with the debug turned on in the console as well as the bt would make things a little better, you also may want to include a list of what ip/hostname represents what device in your scenerio... ------------ From: ;tag=as2bed9bc1 To: Contact: ------------ By: Daniele Gallina (gallysoft) 2005-04-11 08:12:41 Sorry, but there aren't nothing about core or asterisk in /tmp. There is only something about mysql etc. By: Anthony Minessale (anthm) 2005-04-11 08:28:05 start asterisk with -g flag to create cores By: Daniele Gallina (gallysoft) 2005-04-11 08:41:33 Sorry, but it don't produce NOTHING!!! By: Anthony Minessale (anthm) 2005-04-11 08:53:14 ???? If you are using the -g flag by hand and not via safe_asterisk, please look in the same directory where you started asterisk from for the core file... If you want explicit instructions here they are 1) execute "script" this will start a new shell and record all your console activity 2) in this new shell: execute asterisk -nvcg and wait for a CLI> prompt 3) at the CLI> do the following commands CLI>set verbose 10 CLI>set debug 10 CLI>sip debug 3) reproduce the segfault 4) issue the ls command and look for the most recent core.* file 5) run gdb /usr/sbin/asterisk core.xyz (assuming xyz is a series of numbers) 6) issue bt full in gdb 7) exit gdb then exit the shell it will say "Script done, file is typescript" typescript is the caputre file. 8) issue the command cat typescript | col > trace.txt 9) upload trace.txt to the bug. oh yeah, and in anticipation, if you dont have the script command either go install it or pick some other way to capture the text edited on: 04-11-05 08:54 By: Terry Wilson (twilson) 2005-04-11 19:57:29 I just had to modify SER to grab the call-id in the Replaces and distribute the call according to the same algorithm that I am already using to direct INVITEs by hashing off of the call-id and it seems to work with both my polycom and cisco phones. Still have trouble with the Attended transfer with Early completion (start an attended transfer and finish the transfer while the transfer target is still ringing--getting a 482 Loop Detected from SER <sigh>).  Other than that it seems to work for me.  Haven't hit the segfault with my equipment/setup. By: Kevin P. Fleming (kpfleming) 2005-04-27 00:33:31 The patch has been placed into the 'patches' subdirectory of CVS HEAD, and I'm about to post a request to asterisk-dev to get some more testers involved. By: Olle Johansson (oej) 2005-05-03 14:52:08 Seems like we're getting no feedback on the patch. I'll stop hiding and start test ing this code together with twilson. By: Olle Johansson (oej) 2005-05-20 17:26:56 Patch in ASTERISK-4248 is a first step towards proper Replaces support. Will try to add patches in small parts to make it easier to digest, since this will require quite a lot of changes. By: Michael Jerris (mikej) 2005-07-12 16:41:40 ASTERISK-4248 got commited, what's next on this one? By: Olle Johansson (oej) 2005-07-20 07:42:21 Next up is the SIP domains patch. By: Olle Johansson (oej) 2005-07-23 13:31:24 ...still working on this... By: Olle Johansson (oej) 2005-09-05 12:56:00 We now have a working patch. Will split it up in several parts and submit them. A large patch will be committed in this bug report when I've cleaned it up. By: Serge Vecher (serge-v) 2005-09-13 17:33:21 olle, which order should are the related open patches (4466, 5124, 5122)-- which I pressume make up a fully working patch you've mentioned -- should be applied in order to test this? By: Olle Johansson (oej) 2005-09-14 03:44:30 There is no fully working patch uploaded, it is still under testing and code clean-up before I submit it. Testing it at SIPit this week. By: Serge Vecher (serge-v) 2005-11-08 12:16:57.000-0600 Just a ping here, saw kpflemming's note in another bug that 1.2 is due next week -- would like to help with testing to get this in prior, hopefully. By: Olle Johansson (oej) 2005-11-08 14:20:46.000-0600 Seems like we have a working patch now after *a lot* of testing. It will take time to clean up for a clean patch for CVS HEAD though. The patch * Rewrites the handling of local transfers (REFER) * Makes Asterisk send INVITE/REPLACES if we get a replace header in the  refer-to (attended transfer) and the replaced call is not local * Adds handling of incoming INVITE/REPLACES  - This creates support of attended transfer with legs of the    call being on two different servers * Supports attended transfer of ringing calls * Supports attended transfer of one-legged calls (no bridge) It even works with pedantic mode turned on, as an extra benefit. By: Serge Vecher (serge-v) 2005-11-08 16:06:54.000-0600 Sounds good! We just have to see it now ... Go Olle By: Guenther Starnberger (gst) 2005-11-18 06:13:26.000-0600 oej: is there any chance of getting this into a subsequent 1.2.x release or will the patch be for 1.4 only? By: Matt O'Gorman (mogorman) 2006-01-08 10:09:56.000-0600 oej are all patches merged where they need to be or are there still cases where this is not all fixed? please provide update or close bug thanks By: Olle Johansson (oej) 2006-01-09 01:22:53.000-0600 No patch is submitted yet, matt. By: Toto (dd) 2006-02-28 10:51:39.000-0600 I use asterisk 1.2.4 and the patch rev2 doesn't work with this version. What have I to do ? use the cvs version ? thanks, Thomas By: Olle Johansson (oej) 2006-02-28 13:08:07.000-0600 The patch in this bug report is broken. By: Toto (dd) 2006-03-01 02:29:55.000-0600 ok, but I don't have exactly this problem. I don't use two Asterisk but an Asterisk and a Ser server. Do you know if there is a solution to solve this using ser fonctions ? By: Olle Johansson (oej) 2006-03-02 02:01:56.000-0600 DD: Please use the mailing lists for discussions, thank you. By: Olle Johansson (oej) 2006-03-02 15:37:48.000-0600 The discussion will continue in bug report ASTERISK-6460 for the new "siptransfer" branch. Thank you for following me over there :-) By: Olle Johansson (oej) 2006-05-17 14:54:04 Moved to ASTERISK-6460 By: Digium Subversion (svnbot) 2008-01-15 15:27:29.000-0600 Repository: asterisk Revision: 5179 U   trunk/channels/chan_sip.c ------------------------------------------------------------------------ r5179 | markster | 2008-01-15 15:27:29 -0600 (Tue, 15 Jan 2008) | 2 lines Merge tony's refactoring code with small mods (bug ASTERISK-3626) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5179 By: Digium Subversion (svnbot) 2008-01-15 15:32:23.000-0600 Repository: asterisk Revision: 5516 A   trunk/patches/bug_3710_sip_refer.patch ------------------------------------------------------------------------ r5516 | kpfleming | 2008-01-15 15:32:22 -0600 (Tue, 15 Jan 2008) | 2 lines add patch from bug ASTERISK-3626 so it can get wider testing ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5516