Summary:	ASTERISK-15955: [patch] SetCallerpres not honored on SIP Redirect
Reporter:	dovid (dovid)	Labels:
Date Opened:	2010-04-14 04:30:03	Date Closed:	2011-07-26 15:20:04
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) forward_cid_pres.diff ( 1) new_forward_cid_pres_1.6.1branch.diff ( 2) sip_re-direct_2.log ( 3) sip_re-direct_3.log ( 4) sip_re-direct.log ( 5) sip.conf
Description:	Hi, If you set CallerPres to prohib_passed_screen on the initial invite it goes out with out CID. If the peer sends a 302 re-direct when Asterisk sends out the new invite it sends out the users CID when it should send nothing because we set CallerPres to prohib_passed_screen.
Comments:	By: Paul Belanger (pabelanger) 2010-04-14 08:47:07 This is a good start, but I would also like to see a debug output too. Could you reproduce your problem following these instructions: http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt Also, please attach your sip.conf file. By: dovid (dovid) 2010-04-14 11:07:03 1) Log file and SIP.conf uploaded. 2) I noticed on line 452 it has "[Apr 14 11:55:58] VERBOSE[29862] app_dial.c:     -- Now forwarding SIP/Wifi-0000008a to 'SIP/18005551212::::UDP@XX.XX.XX.XX:11060' (thanks to SIP/xconnect-0000008b)" Shouldn't that be "[Apr 14 11:55:58] VERBOSE[29862] app_dial.c:     -- Now forwarding SIP/Wifi-0000008a to 'SIP/18005551212@XX.XX.XX.XX:11060' (thanks to SIP/xconnect-0000008b)" It seems like it adds in "::::UDP". By: Paul Belanger (pabelanger) 2010-04-14 13:27:43 From what I see, this looks to be a bug. Asterisk is creating a new SIP channel and not preserving the previous defined channel variables. By: Paul Belanger (pabelanger) 2010-04-14 16:06:40 Dovid: Try this in your dialplan. Set(_CALLERPRES()=prohib_passed_screen) By: dovid (dovid) 2010-04-15 03:41:17 pabelanger: Adding in _ before CALLERPRES makes things worse. On the initial invite it also shows the CID. By: Paul Belanger (pabelanger) 2010-04-15 10:30:42 It is my understanding this is the correct way to pass Variables between channels.  Can you prefix your existing variables with "_" and generate a new debug log. By: dovid (dovid) 2010-04-16 04:39:54 afaik _ only works when one channel sends a call to another channel. It seems that Asterisk is creating a new one (and not sending the call from the first channel to a new one). By: Paul Belanger (pabelanger) 2010-04-19 09:22:02 Dovid: What about: Set(GLOBAL(_CALLERPRES()=prohib_passed_screen))) By: dovid (dovid) 2010-04-19 10:12:57 pabelanger: Both: Set(GLOBAL(_CALLERPRES()=prohib_passed_screen))) and Set(GLOBAL(CALLERPRES()=prohib_passed_screen))) did not work. On the initial invite the CID was not blocked as well. By: dovid (dovid) 2010-04-22 04:52:26 Sorry to be a PITA but PING !! By: David Woolley (davidw) 2010-04-22 06:08:32 CALLERPRES is a function.  _ and GLOBAL only work for true variables. CALLERPRES ends up doing:                  chan->cid.cid_pres = pres; and it is this field in the channel structure that would need copying, not a variable. By: dovid (dovid) 2010-04-22 10:37:11 davidw: That's what I thought. It seems to be like what pabelanger said that a new channel is being created and the callerpres is not being preserved. By: Paul Belanger (pabelanger) 2010-04-22 11:06:11 My initial comments about CALLERPRES() seem to be incorrect.  I _assumed_ functions we also copied from channel to channel when using Set(), not so. By: David Woolley (davidw) 2010-04-22 11:40:49 Note that the channel manipulation is done in app_dial.c, or above, so this effect will apply to any channel that is capable of doing caller presentation and passing up a call forward request. In fact, I think you can mix and match channel technologies. By: dovid (dovid) 2010-04-26 08:04:58 davidw: I do not understand what you are saying. By: David Woolley (davidw) 2010-04-26 08:32:23 1) it is not a SIP issue, even if it turns out that SIP is the only technology for which far end initiated redirects are supported (some sort of forward support exists for several channel technologies); 2) it doesn't even require that the bit before the / be the same for the original and the redirected channel; 3) the most likely source file that will require changing is app_dial.c (actually it looks like main_dial.c handles forwards, as well, and may be what has to change). All that the SIP 302 handler does is to set a field in the non-technology specific channel structure.  Higher level, non-channel driver, code detects that and initiates the redirected call. (Telling me precisely which point you did not understand would have helped me to give a better reply.) By: dovid (dovid) 2010-04-28 06:00:26 davidw: I didn't understand what you said in the first message. I understand that it is not related to the actual technology and that the issue is that when asterisk gets the 302 it constructs a new channel and in the new channel it does not pass to it that the CID should be blocked like it did in the first channel which seems to be a bug when asterisk creates the second channel just like pabelanger  stated. By: David Woolley (davidw) 2010-04-28 06:08:13 Can you quote the exact words you don't understand, as I'm not sure what you are referring to. I agree there is probably a bug, but it is not a chan_sip.c bug. pabelanger said: "Asterisk is creating a new SIP channel and not preserving the previous defined channel variables", but the indication not to present caller-ID is not a channel variable, it is an actual field in the channel data structure, that needs to be exlicitly copied, by name. By: frawd (frawd) 2010-05-04 08:50:16 Dovid: Can you try the uploaded diff? Might fail, it's just a testing thing. By: frawd (frawd) 2010-05-04 08:52:50 Ok, the first diff will surely fail, better try the second one. By: dovid (dovid) 2010-05-08 22:54:33 Patched against 1.6.2.6 and it's working like a charm. Anyone know if this would work against 1.4.21.1 and if not, how hard it would be to patch it ? By: frawd (frawd) 2010-05-11 03:52:54 The diff was just an idea of where I think the problem is located. Looks like it's the right spot, thanks to your testing! It would still need to get looked at by someone that knows a bit more how CID presentation works. The patch will not work against 1.4 versions but it should not be that hard to do something equivalent. By: dovid (dovid) 2010-06-10 04:51:08 PING !!! By: Paul Belanger (pabelanger) 2010-06-16 10:15:51 Dovid: Are you able to reproduce this in trunk?  I suspect this may have been already fixed there. By: dovid (dovid) 2010-06-17 07:55:04 pabelanger: Where can i grab trunk from ? By: David Woolley (davidw) 2010-06-17 07:56:49 svn co http://svn.digium.com/svn/asterisk/trunk trunk By: Leif Madsen (lmadsen) 2011-07-26 15:19:58.385-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!