401 Unauthorized after too many tables in AXL SQL Query

Unanswered Question
May 22nd, 2008


I have an app that sends several AXL calls. All work fine with the exception of one accessing MGCP data via the AXL SQL QUERY command. I have found that if I only do a couple of tables it works fine, but if I had in more than 3 I get a 401 unauthorized return. Now, I know the commands are built correctly becuase its working for every other command in the set and like I said if I only do 3 or less tables the query works. Also, if I SSH into the CM locally and do run sql with the full command, it returns all tables fine, which leads me to believe this is a restriction in the return of the axl soap call...


I am using CM 6.0. The full query being passed in that returns 401 unauthorized is:

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"

Again, this works locally on the CM machine, it works if I pull back some of the tables... The AXL trace logs do not have errors, they just stop (with a return soap call that isnt passed back because 401 is recieved).


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
risiprekel Thu, 05/22/2008 - 06:04

Here is the trace log. The return is there! It just never gets recieved.

2008-05-22 09:50:23,458 INFO [http-8443-Processor23] axl.AXLRouter - <?xml version="1.0" encoding="UTF-8"?>http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">http://www.cisco.com/AXL/API/6.0" xmlns:xsi="http://www.cisco.com/AXL/API/6.0" sequence="1">67a5af3c-878b-8dd3-2865-ca3ca007d2c22811-Test-VG1Cisco 2811Sub-Pub0NM-4VWIC-MBRD0VWIC2-1MFT-T1E1-T111209133478-fb3741a3-bb70-4013-90fa-734bea80f77267a5af3c-878b-8dd3-2865-ca3ca007d2c22811-Test-VG1Cisco 2811Sub-Pub0NM-4VWIC-MBRD1VWIC2-1MFT-T1E1-T111209133478-fb3741a3-bb70-4013-90fa-734bea80f77267a5af3c-878b-8dd3-2865-ca3ca007d2c22811-Test-VG1Cisco 2811Sub-Pub0NM-4VWIC-MBRD2VIC2-4FXO41209133478-fb3741a3-bb70-4013-90fa-734bea80f77267a5af3c-878b-8dd3-2865-ca3ca007d2c22811-Test-VG1Cisco 2811Sub-Pub0NM-4VWIC-MBRD3VIC-4FXS41209133478-fb3741a3-bb70-4013-90fa-734bea80f77243187db4-aa08-2141-a7eb-c865f45c5996Router.atrion.internalCisco 2811Pub-Sub0NM-4VWIC-MBRD0VWIC-2MFT-T121207845753-f4497a98-4ee7-42e7-9770-090898a52ca9eb492b1e-f238-ace9-3ffe-0a7b8765f364test-3845Cisco 3845Pub-Sub0NM-4VWIC-MBRD0VIC2-2MFT-T1E1-E121210884106-fa04b172-efe5-4ca0-9e44-1934af3fa7c6eb492b1e-f238-ace9-3ffe-0a7b8765f364test-3845Cisco 3845Pub-Sub0NM-4VWIC-MBRD1VIC2-2MFT-T1E1-E121210884106-fa04b172-efe5-4ca0-9e44-1934af3fa7c6

2008-05-22 09:50:23,461 INFO [http-8443-Processor23] axl.AXLRouter - Request 1211393338927 was process in 30ms

risiprekel Thu, 05/22/2008 - 10:38

Found out what the issue is...

The executeSQLQuery AXL command does NOT properly encode illegal unicode XML characters in a soap response, therefore causing the soap response to get destroyed and then forcing a 'random' 401 unauthorized error.

This has been confirmed because the query works on the server (confirming the SQL works), soap post works (because the other sets of commands in my sequence are fine) and after removing gateways with modules or subunits that contain illegal characters (for xml) and running the same call without changing the programming, the axl call works flawlessly and returns the result of my original executesqlquery...

This may or may not be a bug at the AXL level.

Either way, the getMGCP call apparently does having encoding, as I can get most of the same information for the gateways that have illegal characters, however I am unable to get ALL of the info I want... (and in the format I want it)... oh well.


This Discussion