Summary:	ASTERISK-02111: [post-1.0] [request] MGCP Support As MG/SG, not CA/MG/SG
Reporter:	jayson (jayson)	Labels:
Date Opened:	2004-07-26 14:24:57	Date Closed:	2011-06-07 14:04:47
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Currently, chan_mgcp attempts to be a minimal Call Agent so that it can manage and talk to MGCP phones. I'm currently developing a Call Agent to exploit some of the more advanced features of certain MGCP screenphones. After some consideration, I believe that * is probably not the best place to implement this.  Most MGCP devices have advanced features that we are not going to want to implement in chan_mgcp and we also don't have the ability to properly manage the more exotic MGCP MGs.  More importantly, MGCP purposely decomposes the MG, SG, and CA.  As such, * reintegrating them kind of defeats the purpose of MGCP. Therefore, I think MGCP would be better implemented as a MG/SG capable of slaving to another CA.  I'm not suggesting dumping the existing support (it's very useful), only modifying it to provide a client MGCP mode. More specifically, a full MGCP implementation is redudant and requires nothing but connection logic on the CA.  With the current implementation, we would have to make * capable of having some kind of shared state and failover between servers to have the same kind of functionality.  I imagine that would be much more work. ****** ADDITIONAL INFORMATION ****** Definitions: MG=Media Gateway SG=Signalling Gateway CA=Call Agent Other Comments: MGCP allows to have multiple, redundant CAs manage many VoIP Media Gateways.  Implicit in its design is that it acts to mediate between, say, a phone and a PSTN-trunk MG to set up a VoIP session between them.  This is interesting because, with a proper CA, there is no single point of failure in the system.  CAs can disappear.  MGs can go down.  Phones MGs can disconnect.  As long as your network is also redundant, your system runs flawlessly.  This is not currently possible with *.  It's not really currently possible with anything (even the Cisco stuff rarely deploys in a way that makes this work). I don't think that people need to look much further than the predictive dialer work and some of the queueing stuff to see that * has a long way to go in the dialing logic department.  However, the protocol and transcoding support is top notch.  MGCP abstracts these two pieces in a very flexible way.  While I wish that we could do the same to *, I doubt it will happen.  Instead, this would be a stopgap measure that would allow * to act as a simple transcoder, IVR, and announcer (all of the things it does best) while leaving the redundant, transparent phone routing to something more suited to the job.  I mean no disrespect to the current state of *, but I have a hunch that we will probably end up doing this around version 3.0 anyway.  By then, who will want a monolithic PBX when decomposed, redundant VoIP solutions are available?  Put another way, I'd like for our appeal to go beyond "it's cheap" to "it's better". By separating the CA out into a separate beast, * can do the heavy lifting that will make a truly open source, dynamic, redundant telephony infrastructure. I understand that this is definitely post-1.0 work.
Comments:	By: jayson (jayson) 2004-07-30 13:00:43 Minor update.  Above I put SG == Session Gateway.  SG == Signalling Gateway. By: Russell Bryant (russell) 2004-10-05 14:38:36 Updates?  Do you have a patch?  If not, I'm not totally sure this is appropriate for the bugtracker.  You will probably get more feedback on this topic if you take it to IRC and the mailing lists. Thanks, Housekeeping By: jayson (jayson) 2004-10-05 17:14:11 Well, it's a feature request more than anything.  After beating on it a while, I'm pretty certain that making Asterisk into a full CA would be a serious undertaking (that could make it more difficult for people who use Asterisk in "shoehorn" situations right now). I've been taking an angle on using a combination of the management interface and the outgoing call queue to make a sort of "strapped on" media gateway program that uses Asterisk for the heavy lifting (by remote control) but handles the protocol itself. Until we have some sort of plugin capability for the core decision logic (most of pbx.c), I suspect we can't really play nice as a call agent, so I still think MG is the way to go.  I'm trying to avoid patching the source because I've had negative experiences getting working improvements merged in the past (the result of which may plague users of the management interface for a long time).  So my interaction will hopefully be mostly external to the source if I can make it so. I will probably take this up on IRC and on list, I've just been letting it wait until things die down post-1.0 (list activity is still pretty brisk). edited on: 10-05-04 17:15 By: Russell Bryant (russell) 2004-10-05 21:22:37 It appears as if you're not going to get much feedback here on your ideas.  I wish you the best of luck with getting what you want out of Asterisk.  You will get much more feedback on IRC and the mailing lists so I encourage you to continue your efforts there. For now, I am going to close this out.  Feel free to re-open this if you come up with something later on. Thanks!