Summary:	ASTERISK-13614: [patch] SIP Forking Feature
Reporter:	Shivaprakash Dasihally Mallikarjunaiah (shivaprakash)	Labels:
Date Opened:	2009-02-20 00:32:00.000-0600	Date Closed:	2009-07-02 14:59:55
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) channel_changes.patch ( 1) sip_changes.patch ( 2) sip.conf
Description:	This feature enables a user to register from multiple locations and there by allows forking of a SIP call. Registration entries are maintained as a list in peers. Registration refreshes of the same user are checked and updated accordingly. New registrations of the same user from different location will be added as a list in sip_peer structure. An outgoing call is checked against the number of peers registered from peer list and the invite is forked to all the location from where the user is registered. Only the fisrst successful 2xx will establish a call, and other forked calls will be terminated. ****** STEPS TO REPRODUCE ****** In sip.conf, add a new configuration parameter allowforking=yes (yes/no), By default forking is disabled ****** ADDITIONAL INFORMATION ****** Design Idea of this implementation ------------------------------------- The forked private channels (sip_pvt) will be having a common single owner. private channels state handling is done to maintain consistancy, wherein we wait for the first successful response to update the owner channel state. TODOs -------- 1) Per peer configuration of allowforking. Currently it is general setting 2) Need to delete the older peers from the list when allowforking is changed from yes to no on reconfiguration 3) Forking for other SIP requests Note: ------- We appreciate your valuable comments and inputs to improve or modify the existing design on this. We will soon update the complete forking features with above mentioned TODOs.
Comments:	By: Shivaprakash Dasihally Mallikarjunaiah (shivaprakash) 2009-02-20 03:19:43.000-0600 My Contributor Licence is pending Submitted patch will not be seen until my contributor Licence is approved By: Leif Madsen (lmadsen) 2009-02-23 11:19:38.000-0600 You license was rejected for some reason. You'll need to re-submit with the missing/erroneous information, and re-upload your patches. Thanks! By: Shivaprakash Dasihally Mallikarjunaiah (shivaprakash) 2009-02-24 10:18:26.000-0600 The approval of my contributor license is getting delayed, because of some mistakes or something in my real name. I have applied again for contributor licence and the patch will be visible once its approved. By: Leif Madsen (lmadsen) 2009-02-24 11:23:56.000-0600 Thanks for the update Shivaprakash! Looking forward to your contribution. Thank you for taking the time to make Asterisk better! By: Leif Madsen (lmadsen) 2009-02-24 11:29:27.000-0600 I think I may have gotten this fixed now, but I'm not 100% sure. Can you try uploading your patches again? Also, feel free to come find me on IRC as lmadsen in #asterisk-bugs on irc.freenode.net, and we'll work through this to get your license fixed up. Thanks! Leif. By: Shivaprakash Dasihally Mallikarjunaiah (shivaprakash) 2009-02-27 07:16:57.000-0600 The bug status is still "needs license". Do i need to do any other thing for that status to change? By: Michiel van Baak (mvanbaak) 2009-02-27 07:20:52.000-0600 You are right. Changing to new. By: Leif Madsen (lmadsen) 2009-02-27 10:43:13.000-0600 The status update is a manual thing. Sorry I didn't notice it until after the comments came up :) By: Olle Johansson (oej) 2009-03-10 04:36:03 To allow the channel driver to fork is the wrong way to solve this issue. We can't have forking on two layers. Asterisk is a multiprotocol PBX that forks in the PBX layer. While I appreciate that you contribute to Asterisk and I understand that this patch solves your issue, I don't approve of it. We can't have two PBX layers. The correct way is to create another peer, and have the core PBX being aware of two different sip peers and implement a variable - maybe reuse the hint structure - that holds all the names of SIP peers to call, like sip/olle#01, sip/olle#02 for a peer name sip/olle. By: Russell Bryant (russell) 2009-03-10 08:32:33 I am in complete agreement with oej, here. I _really_ appreciate the hard work put in to this, but this functionality has come up in discussion a number of times, and it always ends with exactly what oej has said.  We handle forking in the dialplan, and there does not seem to be a good enough reason to also implement it in the channel driver. By: Shivaprakash Dasihally Mallikarjunaiah (shivaprakash) 2009-03-10 10:13:32 Thanks for the update. My idea was from SIP point of view, as this is specific to SIP (dont know whether other channels drivers support it) and also as the forking needs to be done for a 'single' user registered from multiple locations, unlike wherein PBX layer the call is forked to 'different' users, i thought it would be better to handle at SIP channel driver But these are valuable comments and let me see how best it can be implemented at pbx layer By: pj (pj) 2009-03-10 11:40:48 I will be happy, if exist some possibility to register device from same account name multiple times and that asterisk will automatically start call forking. It will be very usefull feature for service providers, because customers often wants to have multiple phones at home, and creating multiple accounts for one real user isn't good solution for both, users and providers. By: Olle Johansson (oej) 2009-03-10 12:23:53 pj: I definitely understand the requirements. We just need to implement it in a correct way. Read my notes. So far, I haven't found any provider interested in funding this work. By: Shivaprakash Dasihally Mallikarjunaiah (shivaprakash) 2009-03-24 08:58:35 I am exploring the option of implementing forking from PBX layer and found two approaches. One was to use custom functions and the other to use hints. In both the cases we thought of getting a string containing peers using custom functions or hints callbacks ("SIP/1000#01&SIP/1000#02&SIP/1000#03"). Here #01, #02 and #03 are the indexes of peer entries in the peer table list. This string will be passed to the application where the state handling will be done there. Although the PBX creates separate channels for forking, in the chan_sip.c we should still map the above peer names (SIP/1000#01) to the correct entry in the peer table and then proceed. So chan_sip is not completely unaware about forking. oej: is this approach the correct way to proceed? By: Leif Madsen (lmadsen) 2009-05-22 12:32:05 Just pinging the original reporter to determine if he was able to make any headway with this issue? Thanks! By: Russell Bryant (russell) 2009-07-02 14:59:54 As we alluded to before, this is really not a feature that we desire to have in Asterisk.  We support forking calls from the dialplan today.  Adding forking directly into chan_sip is not something we're willing to add or support directly in chan_sip.