[SR-Users] Kamailio accepts and stores XCAP XML document from jitsi but rejects it on retrieval

Alex Villací­s Lasso a_villacis at palosanto.com
Fri May 30 22:02:17 CEST 2014


El 30/05/14 12:42, Alex Villací­s Lasso escribió:
> El 30/05/14 11:02, Alex Villací­s Lasso escribió:
>> El 29/05/14 12:15, Alex Villací­s Lasso escribió:
>>> El 29/05/14 07:51, Daniel-Constantin Mierla escribió:
>>>> Hello,
>>>>
>>>> the error message is printed in case of an invalid xml document.
>>>>
>>>> Can you edit modules/xcap_server/xcap_misc.c  and add inside function:
>>>>
>>>> int xcaps_check_doc_validity(str *doc)
>>>>
>>>> the log:
>>>>
>>>> LM_ERR("xmld document is: [[%.*s]]\n", doc->len, doc->s);
>>>>
>>>> before the line with:
>>>>
>>>> docxml = xmlParseMemory(doc->s, doc->len);
>>>>
>>>> Re-compile and re-install. Then run a test and send here the output of this line.
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17556]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/xcap-caps/global/index
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17556]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/xcap-caps/global/index
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17556]: ALERT: <script>: ===== xhttp: xcap-caps : <null>
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/resource-lists/users/sip:avillacisIM at pbx.elastix.com/index
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/resource-lists/users/sip:avillacisIM at pbx.elastix.com/index
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ALERT: <script>: ===== xhttp: resource-lists : sip:avillacisIM at pbx.elastix.com
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ERROR: xcap_server [xcap_misc.c:690]: xcaps_check_doc_validity(): xmld document is: 
>>> [[3C3F786D6C2076657273696F6E3D22312E302220656E636F64696E673D225554462D3822207374616E64616C6F6E653D226E6F223F3E3C7265736F757263652D6C6973747320786D6C6E733D2275726E3A696574663A706172616D733A786D6C3A6E733A7265736F757263652D6C69737473223E3C6C697374206E616D653D22526F6F7447726F7570223E3C656E747279207572693D227369703A626D6163696173407062782E656C61737469782E636F6D223E3C646973706C61792D6E616D653E626D61636961733C2F646973706C61792D6E616D653E3C2F656E7472793E3C2F6C6973743E3C2F7265736F757263652D6C697374733E]]
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ERROR: xcap_server [xcap_server.c:758]: xcaps_get_db_doc(): invalid xml doc retrieved from database
>>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ERROR: xcap_server [xcap_server.c:1171]: w_xcaps_get(): could not fetch xcap document
>>>
>>>
>>> Huh....?
>>>
>>> The hex string happens to be an hex dump of the following:
>>>
>>> <?xml version="1.0" encoding="UTF-8" standalone="no"?><resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"><list name="RootGroup"><entry uri="sip:bmacias at pbx.elastix.com"><display-name>bmacias</display-name></entry></list></resource-lists>
>>
>> Looks like a SQL_C_BINARY is required somewhere. Right now I am trying to figure out where.
> I worked this around by changing the column type to MEDIUMTEXT from the original MEDIUMBLOB:
>
> ALTER TABLE xcap CHANGE COLUMN doc doc mediumtext not null;
>
> Is this an acceptable solution? Could this cause issues with truly binary data stored there?
>
> Now the table looks like this:
>
> CREATE TABLE `xcap` (
>   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
>   `username` varchar(64) NOT NULL,
>   `domain` varchar(64) NOT NULL,
>   `doc` mediumtext NOT NULL,
>   `doc_type` int(11) NOT NULL,
>   `etag` varchar(64) NOT NULL,
>   `source` int(11) NOT NULL,
>   `doc_uri` varchar(255) NOT NULL,
>   `port` int(11) NOT NULL,
>   PRIMARY KEY (`id`),
>   UNIQUE KEY `doc_uri_idx` (`doc_uri`),
>   KEY `account_doc_type_idx` (`username`,`domain`,`doc_type`),
>   KEY `account_doc_type_uri_idx` (`username`,`domain`,`doc_type`,`doc_uri`),
>   KEY `account_doc_uri_idx` (`username`,`domain`,`doc_uri`)
> ) ENGINE=MyISAM AUTO_INCREMENT=7 DEFAULT CHARSET=latin1
The xml document retrieval is failing again. Now it is because retrieval is truncating the MEDIUMTEXT field at 1024 characters:

May 30 14:54:52 elx /usr/sbin/kamailio[18984]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/resource-lists/users/sip:avillacisIM at pbx.elastix.com/index
May 30 14:54:52 elx /usr/sbin/kamailio[18984]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/resource-lists/users/sip:avillacisIM at pbx.elastix.com/index
May 30 14:54:52 elx /usr/sbin/kamailio[18984]: ALERT: <script>: ===== xhttp: resource-lists : sip:avillacisIM at pbx.elastix.com
May 30 14:54:52 elx /usr/sbin/kamailio[18984]: ERROR: xcap_server [xcap_misc.c:690]: xcaps_check_doc_validity(): xmld document is: [[<?xml version="1.0" encoding="UTF-8" standalone="no"?><resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"><list 
name="Trabajo"><entry uri="sip:bmaciasIM at pbx.elastix.com"><display-name>Bruno Macias (IM)</display-name></entry><entry uri="sip:admin at pbx.elastix.com"><display-name>ADMIN (telefono)</display-name></entry><entry 
uri="sip:elandivar at pbx.elastix.com"><display-name>elandivar</display-name></entry><entry uri="sip:bmacias at pbx.elastix.com"><display-name>Bruno Macias (telefono)</display-name></entry><entry uri="sip:jgutierrez at pbx.elastix.com"><display-name>Jorge Gutierrez 
(telefono)</display-name></entry></list><list name="Palosanto Quito"><entry uri="sip:2711 at pbx.elastix.com"><display-name>Jorge Fonseca</display-name></entry><entry uri="sip:2712 at pbx.elastix.com"><display-name>Jose Almeida</display-name></entry></list><list 
name="RootGroup"><entry uri="sip:0015148805346 at pbx.elastix.com"><display-name>Elvita Crespo en Canada</display-name></entry><entry uri="sip:00593992764890 at pbx.elastix.com"><dis]]
May 30 14:54:52 elx /usr/sbin/kamailio[18984]: ERROR: xcap_server [xcap_server.c:758]: xcaps_get_db_doc(): invalid xml doc retrieved from database
May 30 14:54:52 elx /usr/sbin/kamailio[18984]: ERROR: xcap_server [xcap_server.c:1171]: w_xcaps_get(): could not fetch xcap document




More information about the sr-users mailing list