[kamailio/kamailio] implement pua.publish rpc command in order to get rid of mi interface (#878)
There is currently no rpc version of mi pua_publish. I once tried to implement it, but was not successful:
http://lists.sip-router.org/pipermail/sr-dev/2014-November/026177.html
Perhaps someone else could complete the job.
-- Juha
There was also another later thread related to my pua.publish effort:
http://lists.sip-router.org/pipermail/sr-dev/2014-December/026293.html
Can you add the module attached to the discussion in the first link to master branch? I see that the discussion got to a point when you wanted to try further. Once the new module is in master I can pick up on troubleshooting eventual crashes.
For the second link, the discussion ended in approving the change if all was ok. I didn't have the time to check if you did the commit, but if not, go ahead and do it.
Daniel-Constantin Mierla writes:
Can you add the module attached to the discussion in the first link to master branch? I see that the discussion got to a point when you wanted to try further. Once the new module is in master I can pick up on troubleshooting eventual crashes.
For the second link, the discussion ended in approving the change if all was ok. I didn't have the time to check if you did the commit, but if not, go ahead and do it.
My Internet access is currently too slow. I'll commit later this week.
-- JUha
Added pua_rpc module. It is still work in progress: - failure message is not produced when callback is not executed due to an error - readme file is missing
Can you test, reproduce the crash and attach the gdb output for:
``` bt full info locals list ```
so I can have a starting point for troubleshooting with the current master branch?
there is no crash. see my previous comment.
I am not getting the current state, because in the links to old messages in mailing list archives are some backtraces.
In your previous message you say it's work in progress, referring to some missing failure message (a log message or what kind of message?!?) and docs. Maybe you can provide more details whether it is an issue to investigate or not, and if yes, describe what it is.
It was described as well as I could in the second thread: http://lists.sip-router.org/pipermail/sr-dev/2014-December/026293.html from message http://lists.sip-router.org/pipermail/sr-dev/2014-December/026294.html onwards.
@juha-h - I read the mailing list threads and it's hard to digest where you got stuck. You pointed a crash, but it seems it's no longer the case, you refer to a message, but you don't say what message, a.s.o.
In this way it's not easy for me to sort out your issue. That's why I asked to provide fresh details, to start the troubleshooting on actual data, with current master branch. If you keep me looping around, I don't see how I can help. Instead of just pointing back and forth for many times same resources, then saying some are not the last one to look at, I think it will save the time in both sides to just extract the relevant details where you know they are still causing the issue and put them here in the bug tracker.
Daniel-Constantin Mierla writes:
In this way it's not easy for me to sort out your issue. That's why I asked to provide fresh details, to start the troubleshooting on actual data, with current master branch. If you keep me looping around, I don't see how I can help. Instead of just pointing back and forth for many times same resources, then saying some are not the last one to look at, I think it will save the time in both sides to just extract the relevant details where you know they are still causing the issue and put them here in the bug tracker.
I have not asked for help. I just mentioned on the mailing list that I was not able to get pua.publish working and told what the problem was. It is OK with me to keep on using the MI command.
-- Juha
You haven't told the last and actual problem -- that's the *problem* here.
You pointed to some links in the mailing list archive that have no longer valid content. Like the one to the backtrace. So what I asked is to describe the last and current existing problem, but you kept pointing to same links -- waisting time in looping. If that's hard to do, then I cannot help. I tried to digest the discussions in the links and it is not clear what the actual issue is.
The issue is as explained in http://lists.sip-router.org/pipermail/sr-dev/2014-December/026294.html i.e. when pua module send_publish API function returns 418 to pua_rpc publish function, rpc->fault(c, 500, "Wrong ETag"); call produces response document
HTTP/1.1 200 OK. Via: SIP/2.0/TCP 127.0.0.1:52280. Server: OpenXg SIP Proxy (4.3.0-0 (i386/linux)). Content-Length: 108. . <?xml version="1.0"?> <methodResponse> <params> <param> <value></value> </param> </params>
when it should produce response document
HTTP/1.1 200 OK. Via: SIP/2.0/TCP 127.0.0.1:52204. Server: OpenXg SIP Proxy (4.3.0-0 (i386/linux)). Content-Length: 151. . <?xml version="1.0"?> <methodResponse> <params> <param> <value><int>500</int> <string>Wrong ETag</string> </value> </param> </params> </methodResponse>
Looks like my browser of github destroyed the xml documents in the previous message.They are shown in the original message http://lists.sip-router.org/pipermail/sr-dev/2014-December/026294.html
For the records: snippets of code/etc. can be enclosed in triple backticks to keep them in original and highlight as block example. I updated the previous comment to display properly the xml.
Formatting the text for github forms is documented at:
* https://guides.github.com/features/mastering-markdown/
The link is also below each input form, behind the text "Styling with Markdown is supported".
i tried again and had the same issue as in 2014, i.e., when this code is executed:
if (ret == 418) { LM_INFO("Calling rpc->fault(c, 500, "Wrong ETag")\n"); rpc->fault(c, 500, "Wrong ETag"); rpc->delayed_ctx_close(dctx); }
empty xmlrpc reply is produced:
T 2016/12/12 12:40:03.779869 127.0.0.1:45690 -> 127.0.0.1:6060 [AP] POST /RPC2 HTTP/1.0. Host: 127.0.0.1. Connection: close. User-Agent: OpenSIPg XML_RPC Client. Content-Type: text/xml. Content-Length: 972. .
## T 2016/12/12 12:40:03.779940 127.0.0.1:45690 -> 127.0.0.1:6060 [AP] <?xml version="1.0" ?>. <methodCall>. .<methodName>pua.publish</methodName>. .<params>. ..<param>. ...<value>. ....<string>sip:jh@test.tutpro.com</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>7776000</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>message-summary</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>application/simple-message-summary</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>.</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>foo</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>sip:127.0.0.1:5080;transport=tcp</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>P-Flags: 0
</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>Messages-Waiting: no
Message-Account: sip:jh@vm.test.tutpro.com
Voice-Message: 0/1 (0/0)
</string>. ...</value>. ..</param>. .</params>. </methodCall>.
## T 2016/12/12 12:40:03.781651 127.0.0.1:6060 -> 127.0.0.1:45690 [AP] HTTP/1.0 200 OK. Sia: SIP/2.0/TCP 127.0.0.1:45690. Server: OpenSIPg SIP Proxy (5.0.0-b3 (x86_64/linux)). Content-Length: 108. . <?xml version="1.0"?> <methodResponse> <params> <param> <value></value> </param> </params> </methodResponse>
Everything works fine when pua_send_publish(&publ) returns a non-negative value.
I added LM_INFO to xmlrpc.c:
static void rpc_fault(rpc_ctx_t* ctx, int code, char* fmt, ...) { static char buf[REASON_BUF_LEN]; va_list ap;
ctx->reply.code = code; LM_INFO("rpc_fault called with code '%d'\n", code);
and got to syslog:
Dec 12 13:24:17 lohi /usr/bin/sip-proxy[20580]: INFO: pua_rpc [pua_rpc.c:280]: publish(): Calling rpc->fault(c, 500, "Wrong ETag") Dec 12 13:24:17 lohi /usr/bin/sip-proxy[20580]: INFO: xmlrpc [xmlrpc.c:911]: rpc_fault(): rpc_fault called with code '500'
It shows that indeed xmlrpc_fault gets called, but it does not produce anything to xmlrpc response.
I didn't have time so far but it's in my plan for this week to play with it and figure out where is the problem.
Can you try with latest master? A small patch I pushed to xmlrpc module may be the solution, but I didn't have time to play with it yet. I got some rounds of symbol lookup conflicts while trying to troubleshoot on a macos that stuck me for a while (blaiming some compile flags) and I had to rename some symbols in pua_rpc to get me moved forward...
Daniel-Constantin Mierla writes:
Can you try with latest master? A small patch I pushed to xmlrpc module may be the solution, but I didn't have time to play with it yet. I got some rounds of symbol lookup conflicts while trying to troubleshoot on a macos that stuck me for a while (blaiming some compile flags) and I had to rename some symbols in pua_rpc to get me moved forward...
It worked now! So the bug was not in pua_rpc, but in xmlrpc module. I'll do some more testing. Thanks,
-- Juha
Yes, the issue was in xmrpc -- the delayed context used also when sending publish failed was not initialized for just doing rpc fault -- it was done when building a response with rpc add.
Closed #878.
I'm closing this, since pua_rpc module now includes pua.publish. I'll open another one on pua.subscribe in case someone needs it.
-
Daniel-Constantin Mierla -
juha-h