Summary:	ASTERISK-02872: [patch] Incoming SIP "Distinctive Ring" detection using Alert-Info header
Reporter:	Tim Stewart (applsplatz)	Labels:
Date Opened:	2004-11-23 03:48:27.000-0600	Date Closed:	2011-06-07 14:05:19
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip_dring-1.0.2.diff ( 1) sip_dring-1.0.2.txt ( 2) sip_dring-CVS-20041123.diff
Description:	This patch allows you to detect distinctive rings provided by a voip provider using the Alert-Info header. ****** ADDITIONAL INFORMATION ****** The configuration is similar to zaptel's, except that you specify the content of the header in the 'dring#' config option rather than the ring cadence.  For example, in sip.conf: [peername] ... dring1=<http://127.0.0.1/Bellcore-dr3> dring1context=broadvoice-dring ... You can set dring1 through dring3, and you can also provide defaults for all SIP peers/users in the global section.  This code has been tested with the BroadVoice service.  I have provided patches against CVS and 1.0.2. I have already signed the disclaimer form.
Comments:	By: Olle Johansson (oej) 2004-11-23 04:52:52.000-0600 Shouldn't you set the _ALERT_INFO variable? By: Tim Stewart (applsplatz) 2004-11-23 05:05:06.000-0600 I guess you tell me :)  I knew you could set ALERT_INFO to affect the Alert-Info header in your outgoing calls, but should I also set it here?  I suppose there is no harm in doing so, and somebody might find it useful.  Honestly, that was how I initially implemented this feature (by checking for it in the dialplan). By: khb (khb) 2004-11-26 22:54:53.000-0600 This patch parses the distinctive ringing info from an incoming call and matches it against three choices configured in sip.conf?  do I understand this correctly? Why the three choices? for three outgoing lines? What does it do with the info after receiving?  I don't see anything where it passes it on to an outgoing call or where it sets the channel variable?  Am I wrong? Do you have a call flow or trace that shows exactly what this does? (or is supposed to do) By: Brian West (bkw918) 2004-11-27 02:04:02.000-0600 patch not needed you can set the var _ALERT_INFO and you're all set. in cvs-head you can do: [peername] setvar=_ALERT_INFO=blah bkw edited on: 11-27-04 02:05 By: Tim Stewart (applsplatz) 2004-11-27 22:18:46.000-0600 The point of this patch is not to set the Alert-Info header on outgoing calls.  It is intended to make the call start in an alternate context on incoming calls, if your provider sets the Alert-Info header.  For example, when somebody calls my alternate number for BroadVoice, the incoming INVITE to my Asterisk box has the header: Alert-Info: <http://127.0.0.1/Bellcore-dr3> This patch is designed so that an incoming call that contains this text will originate in a different context than normal calls.  After looking extensively through chan_sip.c, I saw nothing else that provided this functionality. By: Brian West (bkw918) 2004-11-27 22:23:49.000-0600 find_peer is how you could/would do it.   bkw By: petersv (petersv) 2004-11-28 02:45:19.000-0600 Could this be accomplished with the patch ASTERISK-2789? It is a generic way of reading sip headers in the dialplan. By: khb (khb) 2004-11-28 03:21:59.000-0600 skeeziks:  why didn't you explain the purpose acurately right away instead of waisting everybody's time? This is a kind of request for very specific handling type for a specific customer configuration.  Someone else might want to come along and would want something else to happen.  Do we want to support all those specific wishes? I think we should seek features that let users configure the channel with general methods that combine to accomplish the same task. For examples, in my sip channels I have an application 'SIPSetContext' that let's me change the context for a peer in the dialplan, in essense what you want to do. That feature, combined with the recently proposed 'sipgetheader' patch to fetch  a header from the sip message would accomplish this in the dial plan. You can probably do that with just the sipgetheader patch, this is what petersv just suggested. I think that is the better implementation, providing individual tools that can be combined for more powerful applications (i.e. the Unix model) By: petersv (petersv) 2004-11-28 03:30:47.000-0600 khb: In fairness the original description etc was quite clear, I think. The harsh remark was a bit uncalled for. The original posters way of handling the distinctive ring makes the data available similar to the zap cahnnels. It is not a totally unresonable approach. Personally I favour the generic way of using SIPGetHeader in the dialplan since it is more versatile. Which means we need to get that application into Asterisk. :-) By: khb (khb) 2004-11-28 22:49:46.000-0600 I am sorry, didn't mean to be harsh. But it was so easy to explain when he did, so why not do it right away. This is time consuming enough and no one needs to spend more time guessing what the intent was. I am not the only one that seems to have missed the point. From the comments so far I seem to have been the only one trying to figure out what the real purpose was. As for implementation, I found it very strange to have a struct of two vectors of strings, rather than a vector of structs with two strings, when the atomic data structure is the two strings. Even when not in use, the implementation copies half a kilobyte around memory (several times?) on every call creation. At some point we need to stop with all this memory copying in Asterisk.  That's another reason why I think the implementation with  header extraction and a dialplan implementation is preferable. By: Tim Stewart (applsplatz) 2004-11-29 00:19:35.000-0600 Personally, I thought my original description to be quite clear, but I suppose I was wrong.  I figured that looking up how zaptel handles distinctive rings was quite easy.  Regardless, I was not aware of the SIPGetHeader application, and the first version of this patch did just that: It set a variable with the contents of the Alert-Info header.  Since I imagine that many people would use this functionality in a way that is familiar (i.e. the way legacy phone providers use distinctive ring), I decided to implement it in the same way that zaptel did it.  Also, entering a different context because of some condition seems to be a common theme in Asterisk configuration, but that is just my observation. I would have preferred to do this in a dynamic way with no limits on the number of strings you could match, but I don't yet fully understand the lifecycle of a channel and don't want to risk dynamic memory allocation.  Also, the style in which I coded this is consistent with the rest of chan_sip.c. Take it or leave it I suppose.  I guess this is what I get for trying too hard not to rock the boat. :) By: Olle Johansson (oej) 2004-12-12 03:59:16.000-0600 Seems like the consensus is that the sipgetheader solved this problem.