Hi!
When I run sercmd to test dispatcher.list I get a nice output
sercmd> dispatcher.list
{
SET_NO: 2
SET: {
SET_ID: 1
DEST: {
URI: sip:pstn1.astritech.org;transport=udp2
FLAGS: AX
PRIORITY: 0
ATTRS:
}
DEST: {
URI: sip:pstn2.astritech.org;transport=udp
FLAGS: AX
PRIORITY: 0
ATTRS:
}
SET_ID: 2
DEST: {
URI: sip:127.0.0.1:5080
FLAGS: AX
PRIORITY: 200
ATTRS:
}
DEST: {
URI: sip:127.0.0.1:5084
FLAGS: AX
PRIORITY: 50
ATTRS:
}
DEST: {
URI: sip:127.0.0.1:5082
FLAGS: IX
PRIORITY: 10
ATTRS:
}
}
}
When trying to use the same over XMLrpc I get this response
HTTP/1.0 200 OK
Via: SIP/2.0/TCP 212.3.14.204:48603
Server: Alvondo Core - Bbtele, Sweden
Content-Length: 220
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><struct><member><name>SET_NO</name><value><int>2</int></value></member><member><name>SET</name><value></struct>
</value>
</param>
</params>
</methodResponse>
Seems like the structure of the data in the dispacther list fails to be propagated in the xmlrpc interface. Is this possibly because of the structure of the data?
The XMLRPC docs say
"1.3.4. Limitations
SER xmlrpc modules does not implement all data types allowed in XML-RPC. As well it does not implement arrays and nested structures. "
Maybe we could implement a dispatcher.listflat that just publishes a flat list..
/O
make of tls module still complains about calls of this macro:
#define TLS_ERR(s) \
do { \
int ret; \
TLS_ERR_RET(ret, s); \
} while(0)
the reason is that none of the calls use ret variable. does anyone know
how to easily fix this?
-- juha