Hi,
i use the XML-RPC-Client from the ZendFramework, at it works like a charm:
private function getCPEInfo($id) {
$xml_servers = array(
'http://127.0.0.1:5060/RPC',
);
try {
if (!$this->xml_client) {
// Choose random Server
$this->xml_client = new
Zend_XmlRpc_Client($xml_servers[rand(0,count($xml_servers)-1)]);
}
$result = array();
$cpe = array();
$query_result = $this->xml_client->call('mi',
array('ul_show_contact', 'location', $id.'@localhost'));
foreach($query_result as $line) {
$cpe = array();
list($cpe['contact'], $rest) =
explode('>', $line, 2);
$cpe['contact'] = substr($cpe['contact'], 11);
$contents = explode(';', $rest);
foreach($contents as $entry) {
list($key, $value) =
explode('=', $entry);
switch($key) {
case 'expires':
case 'cflags':
case 'user_agent':
case 'received':
$cpe[$key] = $value;
break;
default:
}
}
if (isset($cpe['user_agent']))
$cpe['user_agent'] = substr($cpe['user_agent'], 1, -1);
if (isset($cpe['received']))
$cpe['received'] = substr($cpe['received'], 1, -1);
$result[] = $cpe;
}
return $result;
} catch ( Exception $e ) {
return "Unable to connect (".$e->getMessage().")";
}
}
I definitely cannot explain, no matter how many entries i have per account:
1. Endgerät:
Kontakt-URI: sip:xxx@xxx:4099
Gültigkeit: noch 3392 Sekunden
NAT: kein NAT erkannt
Endgerät: Genexis OCG1018MX v1.7.1.1c
2. Endgerät:
Kontakt-URI: sip:xxx@xxx:5060
Gültigkeit: noch 3469 Sekunden
NAT: kein NAT erkannt
Endgerät: Patton SN-DTA 1BIS2V 00A0BA075803 R6.2 2012-07-13 H323 SIP
M5T SIP Stack/4.0.30.30
3. Endgerät:
Kontakt-URI: sip:xxx@xxx:5060
Gültigkeit: noch 954 Sekunden
NAT: kein NAT erkannt
Endgerät: Patton SN-DTA 1BIS2V 00A0BA0761CC R6.2 2012-07-13 H323 SIP
M5T SIP Stack/4.0.30.30
Kind regards,
Carsten
2012/11/13 Carlos Ruiz Díaz <[email protected]>
>
> Hello,
>
> I've been through this problem a few weeks ago with my module that exports
> nested structures through xmlrpc. Apparently, there's a limitation in the
> technology itself that makes the nested structures to be overwritten
> everytime the response XML is parsed, if you look closely, you will notice
> that this makes sense since the structures are indexed by the name of the
> field, which is the same for every record. That's the reason of only one row
> being displayed even though the whole recordset was sent out.
>
> I tried with three different php libraries, even with xmlrpc_decode() that is
> the official function for decoding xmlrpc responses in php.
>
> I didn't find a solution but I ended up using a workaround sending the values
> using CSV format which was later parsed by the PHP in charge of displaying
> the data.
>
> Regards.
>
> Carlos.
>
> On Mon, Nov 12, 2012 at 11:43 PM, Daniel-Constantin Mierla
> <[email protected]> wrote:
>>
>> Hello,
>>
>> I am not a python parameter, but seems a limitation of the xmlrpc_test2.py
>> tool, the tcp dump shows that the records are sent back in the xmlrpc
>> response.
>>
>> You will have to look inside/troubleshoot the xmlrpc_test2.py and see why it
>> fails.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 11/12/12 9:58 AM, Kristofer Signer wrote:
>>
>> Hello,
>>
>> running kamailio 3.3.2.
>>
>> On Mon, Nov 12, 2012 at 1:48 PM, Daniel-Constantin Mierla
>> <[email protected]> wrote:
>>>
>>> Hello,
>>>
>>>
>>> On 11/12/12 10:02 AM, Kristofer Signer wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm trying to dig in to the kamailio XMLRPC interfaces and the limitations
>>>> I read in
>>>> http://www.kamailio.org/docs/modules/stable/modules/xmlrpc.html#xmlrpc.implementation.limitations
>>>>
>>>> is really a no go for us.
>>>
>>> which one is a 'no go'? Nested structures are supported in the last
>>> version, iirc, the readme does not seem to be updated for this case.
>>
>> the 'no go' is the structure {AoR, HashID, Contact, AoR, HashID, Contacts,
>> ...}
>>>
>>>
>>>
>>>>
>>>> For example, when to retrieve user locations and list of dialogs we get a
>>>> xml document which is not so well formatted and we can not successfully
>>>> parse it in an xmlrpc-parser.
>>>>
>>>> Is there other options for xmlrpc module?
>>>
>>>
>>> If the body is not successfully parsed, it is a bug. The limitation is
>>> about not supporting all the data types, but when a reply is xmlrpc sent,
>>> it should be valid. Can you test it with 1-2 location records that fail and
>>> post the xmrpc here as well as the log error messages from the xml parser?
>>
>>
>> Actually, I don't get any errors. I'm using the python example provided in
>> kamailio src and that example will only parse out one record.
>>
>>
>> [krsi@vera examples]$ python xmlrpc_test2.py ul.dump foo
>> {'Domain': 'location', 'Stats': {'Records': 2, 'Max-Slots': 1}, 'AoRs':
>> {'HashID': 1731621673, 'AoR': 'jkp-01', 'Contacts': {'Contact': {'Ruid':
>> 'uloc-50a0ea3c-124bf-1', 'Received': '[not set]', 'Path': '[not set]',
>> 'Reg-Id': 0, 'Expires': 99, 'Flags': 0, 'User-Agent': 'Jitsi1.0-Linux', 'Q':
>> 0.0, 'Instance': '[not set]', 'State': 'CS_SYNC', 'CSeq': 11, 'Methods':
>> 18446744073709551615L, 'CFlags': 0, 'Address':
>> 'sip:[email protected]:25060;transport=udp;registering_acc=foo_bar_com',
>> 'Call-ID': '61ac73a44826f3887a5db2371b044275@0:0:0:0:0:0:0:0', 'Socket':
>> 'udp:192.168.0.82:5060'}}}, 'Size': 512}
>>
>> As you can see,. there should be two records but only one is parsed.
>>
>>
>> Here is the response body from tcpdump
>>
>> <?xml version="1.0"?>
>> <methodResponse>
>> <params>
>> <param>
>> <value><struct>
>>
>> <member><name>Domain</name><value><string>location</string></value></member>
>> <member><name>Size</name><value><int>512</int></value></member>
>> <member>
>> <name>AoRs</name>
>> <value><struct>
>> <member><name>AoR</name><value><string>jkp-02</string></value></member>
>>
>> <member><name>HashID</name><value><int>1731621670</int></value></member>
>> <member>
>> <name>Contacts</name>
>> <value><struct>
>> <member>
>> <name>Contact</name>
>> <value><struct>
>>
>> <member><name>Address</name><value><string>sip:[email protected]:35060</string></value></member>
>>
>> <member><name>Expires</name><value><int>768</int></value></member>
>>
>> <member><name>Q</name><value><double>0.000000</double></value></member>
>>
>> <member><name>Call-ID</name><value><string>[email protected]</string></value></member>
>> <member><name>CSeq</name><value><int>383</int></value></member>
>>
>> <member><name>User-Agent</name><value><string>Twinkle/1.4.2</string></value></member>
>> <member><name>Received</name><value><string>[not
>> set]</string></value></member>
>> <member><name>Path</name><value><string>[not
>> set]</string></value></member>
>>
>> <member><name>State</name><value><string>CS_SYNC</string></value></member>
>> <member><name>Flags</name><value><int>0</int></value></member>
>> <member><name>CFlags</name><value><int>0</int></value></member>
>>
>> <member><name>Socket</name><value><string>udp:192.168.0.82:5060</string></value></member>
>>
>> <member><name>Methods</name><value><int>6111</int></value></member>
>>
>> <member><name>Ruid</name><value><string>uloc-50a0ea3c-124c0-1</string></value></member>
>> <member><name>Instance</name><value><string>[not
>> set]</string></value></member>
>> <member><name>Reg-Id</name><value><int>0</int></value></member>
>> </struct></value>
>> </member>
>> </struct></value>
>> </member>
>> <member>
>> <name>AoR</name><value><string>jkp-01</string></value></member>
>>
>> <member><name>HashID</name><value><int>1731621673</int></value></member>
>> <member>
>> <name>Contacts</name>
>> <value><struct>
>> <member>
>> <name>Contact</name>
>> <value><struct>
>>
>> <member><name>Address</name><value><string>sip:[email protected]:25060</string></value></member>
>>
>> <member><name>Expires</name><value><int>185</int></value></member>
>>
>> <member><name>Q</name><value><double>0.000000</double></value></member>
>>
>> <member><name>Call-ID</name><value><string>61ac73a44826f3887a5db2371b044275@0:0:0:0:0:0:0:0</string></value></member>
>>
>> <member><name>CSeq</name><value><int>12</int></value></member>
>>
>> <member><name>User-Agent</name><value><string>Jitsi1.0-Linux</string></value></member>
>> <member><name>Received</name><value><string>[not
>> set]</string></value></member>
>> <member><name>Path</name><value><string>[not
>> set]</string></value></member>
>>
>> <member><name>State</name><value><string>CS_SYNC</string></value></member>
>>
>> <member><name>Flags</name><value><int>0</int></value></member>
>>
>> <member><name>CFlags</name><value><int>0</int></value></member>
>>
>> <member><name>Socket</name><value><string>udp:192.168.0.82:5060</string></value></member>
>>
>> <member><name>Methods</name><value><int>18446744073709551615</int></value></member>
>>
>> <member><name>Ruid</name><value><string>uloc-50a0ea3c-124bf-1</string></value></member>
>> <member><name>Instance</name><value><string>[not
>> set]</string></value></member>
>>
>> <member><name>Reg-Id</name><value><int>0</int></value></member>
>> </struct></value>
>> </member>
>> </struct></value>
>> </member>
>> </struct></value>
>> </member>
>> <member>
>> <name>Stats</name>
>> <value><struct>
>> <member><name>Records</name><value><int>2</int></value></member>
>> <member><name>Max-Slots</name><value><int>1</int></value></member>
>> </struct></value>
>> </member>
>> </struct></value>
>> </param>
>> </params>
>> </methodResponse>
>>
>>
>>
>> and for reference, the same command from kamctl:
>>
>> [krsi@sipproxy1 ~]$ kamctl mi ul_dump
>> Domain:: location table=512 records=2 max_slot=1
>> AOR:: jkp-02
>> Contact:: sip:[email protected]:35060 Q=
>> Expires:: 1961
>> Callid:: [email protected]
>> Cseq:: 383
>> User-agent:: Twinkle/1.4.2
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 0
>> Socket:: udp:192.168.0.82:5060
>> Methods:: 6111
>> Ruid:: uloc-50a0ea3c-124c0-1
>> Reg-Id:: 0
>> AOR:: jkp-01
>> Contact:: sip:[email protected]:25060 Q=
>> Expires:: 298
>> Callid::
>> 61ac73a44826f3887a5db2371b044275@0:0:0:0:0:0:0:0
>> Cseq:: 10
>> User-agent:: Jitsi1.0-Linux
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 0
>> Socket:: udp:192.168.0.82:5060
>> Methods:: 4294967295
>> Ruid:: uloc-50a0ea3c-124bf-1
>> Reg-Id:: 0
>>
>>
>> Thanks
>> ./Kristofer
>>
>>>
>>> For example, siremis uses the xmlrpc interface and all is ok with handling
>>> the replies. It uses a library from php pear.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.com
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> [email protected]
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> [email protected]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany
http://www.ng-voice.com
mailto:[email protected]
Office +49 40 34927219
Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
