AXL 6 does not properly encode responses.

Unanswered Question
May 28th, 2008

Ok, I'm trying to confirm that this is a bug. I run for example a getMGCP AXL command against CM 6. The command works, I can view the trace log on the CM 6 server and the request is recieved and processed. The response is then generated on the server however it is killed and a 401 unauthorized error (random) is returned after the point it is processed on the server and before it gets back to me.

Now normally I'd think this is me, but this ONLY happens in cases (like getMGCP) where the response contains illegal characters (@, /, etc.) (such as in the domain name - e.g.([email protected]). I can replicate this with other calls e.g. executesqlquery (where I can get the mgcp gateways because it doesnt create the domainnames with @, but it dies when I include the units or subunits (that have @ or / in the unit or subunit name).

The rest of my calls in the same sequence using the same credentials work (I'm getting partitions, CSS, Route Lists, Route Groups, etc.) So I know its not a true 401. I also know it is working as I can see the response packet on the server (via the trace log) and it has all of the data (in the getmgcp call and executesqlquery call instances).

The same application works against 4 with all calls.



This seems to be the case... and there is nothing I can do. This will happen with the following: MGCP, Route Patterns, Trans Patterns, etc. Anything that has special characters in its generated response soap message.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
stephan.steiner Thu, 05/29/2008 - 01:42

Why would @ or / be illegal characters?

Last time I checked there are a few characters that need encoding (<, >, &, \, ') but that's it.

That's not saying it's a bug (and when you file a case with developer support make sure you include debug level axl and dbl traces.. that way you won't have to wait until the engineer gets back to you and asks for those traces) nor that these characters could be the cause of the problem but illegal suggest something that isn't the case.

And by the way.. I think I recall somebody posting about problems with the @ pattern so I did a test myself and it worked here. I don't recall any of the details but the post should be somewhere in this forum.

risiprekel Thu, 05/29/2008 - 04:44

I have opened a tac case and included all traces.

You say you where able to complete a getmgcp against CM 6?

In the example you recall, was it against 4 or 6? Everything is great in 4 (all of these calls work). These issues are from 6... and its not the code, the code works for all other calls (to server and back) in the sequence (CSS, Route Partition, Route List, Route Group, etc). It works (to server) for the calls having issues (I can see the response package generated in the trace, its just never passed back) its only the autogenerated server response that fails for responses with these types of characters (its generated but dies before it reaches me and returns a 401 unauthorized - which is IMPOSSIBLE because its using the same credentials from the 5 calls before it in the same code sequence (The user only enters in a password and username once then requests the calls be made) AND I can see the request made it to the server as the request is processed and a response IS generated... its not dying from me, its dying to me.

I'm just posting what I'm seeing for ideas, if you have proof of getmgcp returning fine, against 6, please post, I'd like to see it.

Also, an executeSQLQuery of:

SELECT MGCP.pkid, MGCP.DomainName, TypeProduct.Name AS GatewayProduct, CallManagerGroup.Name AS CallManagerGroup, MGCPSlotConfig.Slot, TypeMGCPSlotModule.Name AS UnitModule, MGCPSlotConfig.Subunit AS SubUnitIndex, TypeMGCPVic.Name AS SubUnitProduct, TypeMGCPVic.MaxNumPorts, MGCP.VersionStamp, MGCP.SpecialLoadInformation FROM TypeMGCPVic RIGHT OUTER JOIN MGCPSlotConfig ON TypeMGCPVic.Enum = MGCPSlotConfig.tkMGCPVic LEFT OUTER JOIN CallManagerGroup RIGHT OUTER JOIN MGCP ON CallManagerGroup.pkid = MGCP.fkCallManagerGroup LEFT OUTER JOIN TypeProduct ON MGCP.tkProduct = TypeProduct.Enum ON MGCPSlotConfig.fkMGCP = MGCP.pkid LEFT OUTER JOIN TypeMGCPSlotModule ON MGCPSlotConfig.tkMGCPSlotModule = TypeMGCPSlotModule.Enum ORDER BY MGCP.DomainName, MGCPSlotConfig.Slot, UnitModule DESC, MGCPSlotConfig.Subunit

As the unit and subunit information (in cases where there are slashes or parentheses characters) causes this return to fail.

With that executeSQLQuery call, funny thing is if you take out the sql in the request that asks for unit and subunit info (e.g. remove the unit and subunit portions of the query above) the return is fine -- again, maybe because at that time no special characters are being returned...?

I'm not saying its a bug, I'm saying I'm having problems and this is where these different tests are pointing too... just looking for more information.

stephan.steiner Thu, 05/29/2008 - 22:39

I don't have any MGCP but I was able to load the @ pattern (on ccm 6 iirc.. if you want the details look up the old thread on this board).

We're using less and less MGCP because H.323 GWs offer more flexibility that we need in terms of number translation and outgoing number signaling.

I hope TAC helps you.. they don't have to because this issue falls under developer support .

risiprekel Fri, 05/30/2008 - 04:17

Thanks for your comment Stephan. I am able to pull Route Patterns... which includes @... using the same code. Like I said, the issue is on the server side return... weird, I know.

Anyway I'll post what comes back, if anything.

risiprekel Mon, 06/16/2008 - 12:13

As a follow up...

It went through TAC and was passed to Developer services, they are treating it as a bug.

To work around this, I am only pulling MGCP NAME and DESCRIPTION information... which isnt as good as I would like, but is the least of what is available.


This Discussion