Summary:	ASTERISK-01525: MGCP Compatibility Issues
Reporter:	philipp2 (philipp2)	Labels:
Date Opened:	2004-05-03 13:58:18	Date Closed:	2004-09-25 02:45:06
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Taken from asterisk-users: I have a MTA from Terayon that I try to make run with asterisk using MGCPchannel. The device is running with MGCP 1.0 NCS 1.0 Each time Asterisk try to send a Request (Request Notify, Audit Endpoint....) the device returns error 510 "Protocol Error" Does anybody have already meet this problem and provide me support to make run it ?! (I have already try to change header into the chan_mgcp.c from "MGCP 1.0" to 'MGCP 1.0 NCS 1.0" but always the same result) Thanks in advance Ignace CARIA ****** ADDITIONAL INFORMATION ****** Also from asterisk-users: > For me recent CVS has made using MGCP completely > impossible (with Swissvoice ip10 having been upgraded > to newer firmware) So do I, I've got cisco ata 186 with MGCP. Last versions of asterisk are very unusable with MGCP! --Diego Ercolani
Comments:	By: Mark Spencer (markster) 2004-05-03 14:39:59 If you want action on this, you need to be specific about the problem.  There's nothing I can do with a "it's broken" bug report. By: philipp2 (philipp2) 2004-05-03 15:20:54 Yes, I know. I opened this in order to request/provoke more feedback (also mailed the two posters on asterisk-users for more info). And then there is the issue described in 881. So far I cannot exactly tell which of the recent MGCP fixes/patches introduced the problem. By: Brian West (bkw918) 2004-05-03 18:58:41 philipp do this.. cd /usr/src cvs status asterisk/channels/chan_mgcp.c then do something like this cvs checkout -D "50 days ago" asterisk/channels/chan_mgcp.c Then step forward a few days .. and keep doing that.. 50, 45 days, 35 days ago and so on till you find the exact point when it breaks. Also do cvs status asterisk/channels/chan_mgcp.c before each step forward or back and record the verstion numbers.  When you find the exact day or point it was broken report that and we can get a closer idea of when it broke and what broke it. bkw By: Mark Spencer (markster) 2004-05-03 19:15:33 More importantly than that, I need a *specific" description of what is wrong.  What is it that we send that is somehow in violation of the spec, etc. By: alric (alric) 2004-05-04 09:21:50 Have you attempted to narrow down where the problem was added via the cvs checkout -D option bkw pointed out, or do you have any further information on this issue? By: Brian West (bkw918) 2004-05-04 10:50:26 phillip, You're going to have to repsond to this bug faster.  This and two others stand in the way of RC1 and we need to try to fix this before that. Thanks, Brian By: philipp2 (philipp2) 2004-05-04 11:48:59 I try to be as fast as possible, but I *do* have a busy schedule that doesn't permit me to fully focus on Asterisk. I'll see if I can get some more data in here within the next 6 hours though... By: philipp2 (philipp2) 2004-05-04 12:17:03 Again smth from asterisk-users: For the moment I'll post this here, but I guess a separate bug report would be more appropriate: http://lists.digium.com/pipermail/asterisk-users/2004-March/041615.html Hello, I am working on making chan_mgcp work properly with IP10S from SwissVoice. I have patched chan_mgcp from asterisk 0.7.2 and it seems to work pretty well but not in all cases. I give the patch with this message and wait for all feedback. Best regards, Daniel ANDRE -- Daniel ANDRE (mailto:daniel.andre@iris-tech.fr) IRIS Technologies - http://www.iris-tech.com Serveur kwartz - http://www.kwartz.com --------------040101010508020603080706 Content-Type: text/plain; name="chan_mgcp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="chan_mgcp.diff" 1d0 < 375d373 < 766,767c764 < //For IP10S < if ((sub) && !( sub->cxmode == MGCP_CX_MUTE)) { --- > if (sub) { 1389d1385 < 1640d1635 < 1643d1637 < 2228,2229d2221 < // for MGCP IP10S < #if 0 2234d2225 < #endif 2239,2240c2230 <                     // threewaycalling = conf capability? <                     if ((!sub->outgoing) && (!sub->next->outgoing) && (p->threewaycalling)) { --- >                     if ((!sub->outgoing) && (!sub->next->outgoing)) { 2265c2255 < // IP10S                   transmit_modify_request(sub); --- >                         transmit_modify_request(sub); 2272,2273c2262,2263 < // IP10S                handle_hd_hf(sub->next, ev); <                         --- >                         handle_hd_hf(sub->next, ev); > #if 0 2280a2271 > #endif 2298d2288 < By: philipp2 (philipp2) 2004-05-05 03:08:03 Ok, afer a lot of headaches (not related to Asterisk) I can state that basic MGCP functionality is working ok in current HEAD CVS here. Didn't get to testing 3-way-calling and other advanced features. So it seems that the most recent MGCP patches fixed my most urgent issue. By: philipp2 (philipp2) 2004-05-05 05:37:35 update on the Terayon issue above (from asterisk-users): I'm not advanced in voip but what I could tell you is that MGCP channel in asterisk is build on rfc2705 MGCP. MTAs are working in PacketCable 1.0 MGCP which is not that one above, it is something like NCS/TGCP. There are few differences between them so that's why mtas won't work with asterisk. I've had the same problem with Arris mtas recently. Although I've heard somewhere you can configure Terayon mtas to work with rfc2705 MGCP. Regards, Arek Murzyn Technical Support HALDON Sp. z o.o. Warsaw, Poland By: Mark Spencer (markster) 2004-05-21 01:58:49 So is there any point leaving this open still? By: philipp2 (philipp2) 2004-05-21 03:45:55 I suggest to close this, although CVS is repeatedly crashing one or both of the ip10 phones in use. Since there is no traffic in that case I don't really know how to diagnose this because I don't have a pattern that'd allow me to reliable reprodruce the problem. CVS of one month ago did have these problems. By: Mark Spencer (markster) 2004-05-23 19:36:41 Believed to be fixed in CVS whatever it was.