Module: sip-router
Branch: master
Commit: f925ea38f98c3c6f0908064586338a3fb971def6
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f925ea3…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Wed Sep 3 09:28:53 2014 +0200
doc/rpc: updated content to reflect renaming of printf() to rpl_printf()
---
doc/rpc/ser_rpc.txt | 34 +++++++++++++++++++++-------------
doc/rpc/ser_rpc.xml | 32 +++++++++++++++++++++++---------
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/doc/rpc/ser_rpc.txt b/doc/rpc/ser_rpc.txt
index 5d0cb13..06b8044 100644
--- a/doc/rpc/ser_rpc.txt
+++ b/doc/rpc/ser_rpc.txt
@@ -17,7 +17,7 @@
1.2.4.1. fault
1.2.4.2. send
1.2.4.3. add
- 1.2.4.4. printf
+ 1.2.4.4. rpl_printf
1.2.4.5. struct_add
1.2.5. Real World Example
@@ -39,12 +39,19 @@
implementing RPC transports.
The RPC transports are implemented by writting a RPC transport module.
- The most used transport modules are ctl and xmlrpc . The first one
- implements a ser-proprietary fast and space efficient RPC encoding over
- different protocols (unix sockets, UDP, TCP, fifo). The second one uses
- the de-facto XML-RPC standard encoding (over HTTP TCP or TLS). For more
- information about the existing transport modules, please refer to their
- documentation.
+ The most used transport modules are ctl , xmlrpc and jsonrpc-s .
+
+ ctl implements a proprietary fast and space efficient RPC encoding over
+ different protocols (unix sockets, UDP, TCP, fifo).
+
+ xmlrpc uses the de-facto XML-RPC standard encoding (over HTTP TCP or
+ TLS).
+
+ jsonrpc-s uses the de-facto JSON-RPC standard encoding (over HTTP TCP
+ or TLS).
+
+ For more information about the existing transport modules, please refer
+ to their documentation.
When writing a RPC procedure or function, one needs only use the RPC
API and it will work automatically with all the transports and
@@ -523,13 +530,14 @@ static void rpc_func(rpc_t* rpc, void *ctx)
You can set the attributes of the newly created structure using
struct_add function described in Section 1.2.4.5, "struct_add".
-1.2.4.4. printf
+1.2.4.4. rpl_printf
- printf is a convenience function. The function adds data of type string
- to the result set. The first parameter of the function is again a
- formatting string, but this time it is printf-like formatting string:
-if (rpc->printf(ctx, "Unable to delete %d entries from table %s", num_entries, t
-able_name) < 0) return;
+ rpl_printf is a convenience function. The function adds data of type
+ string to the result set. The first parameter of the function is again
+ a formatting string, but this time it is standard printf-like
+ formatting string:
+if (rpc->rpl_printf(ctx, "Unable to delete %d entries from table %s", num_entrie
+s, table_name) < 0) return;
The return value of the function is the same as of add function.
diff --git a/doc/rpc/ser_rpc.xml b/doc/rpc/ser_rpc.xml
index 2aca3fd..a8355c8 100644
--- a/doc/rpc/ser_rpc.xml
+++ b/doc/rpc/ser_rpc.xml
@@ -34,17 +34,30 @@
<para>
The RPC transports are implemented by writting a RPC
transport module. The most used transport modules are
- <ulink url='http://sip-router.org/docbook/sip-router/branch/master/modules/ctl/ctl.html'>
+ <ulink url='http://www.kamailio.org/docs/modules/devel/modules/ctl/ctl.html'>
<emphasis>ctl</emphasis>
+ </ulink>,
+ <ulink url='http://www.kamailio.org/docs/modules/devel/modules/xmlrpc/xmlrpc.html'>
+ <emphasis>xmlrpc</emphasis>
</ulink>
and
- <ulink url='http://sip-router.org/docbook/sip-router/branch/master/modules/xmlrpc/xmlrp…'>
- <emphasis>xmlrpc</emphasis>
+ <ulink url='http://www.kamailio.org/docs/modules/devel/modules/jsonrpc-s/jsonrpc-s.html'>
+ <emphasis>jsonrpc-s</emphasis>
</ulink>.
- The first one implements a ser-proprietary fast and space efficient
+ </para>
+ <para>
+ ctl implements a proprietary fast and space efficient
RPC encoding over different protocols (unix sockets, UDP, TCP, fifo).
- The second one uses the de-facto XML-RPC standard encoding
+ </para>
+ <para>
+ xmlrpc uses the de-facto XML-RPC standard encoding
(over HTTP TCP or TLS).
+ </para>
+ <para>
+ jsonrpc-s uses the de-facto JSON-RPC standard encoding
+ (over HTTP TCP or TLS).
+ </para>
+ <para>
For more information about the existing transport modules, please
refer to their documentation.
</para>
@@ -738,15 +751,16 @@ static void rpc_func(rpc_t* rpc, void *ctx)
</para>
</section>
<section>
- <title>printf</title>
+ <title>rpl_printf</title>
<para>
- <varname>printf</varname> is a convenience function. The
+ <varname>rpl_printf</varname> is a convenience function. The
function adds data of type string to the result set. The
first parameter of the function is again a formatting
- string, but this time it is <function>printf</function>-like formatting string:
+ string, but this time it is standard
+ <function>printf</function>-like formatting string:
<programlisting>
<![CDATA[
-if (rpc->printf(ctx, "Unable to delete %d entries from table %s", num_entries, table_name) < 0) return;
+if (rpc->rpl_printf(ctx, "Unable to delete %d entries from table %s", num_entries, table_name) < 0) return;
]]>
</programlisting>
The return value of the function is the same as of
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#449 - CRASH: Program terminated with signal 6, Aborted.
User who did this - Nuno Miguel Reis (nmreis)
----------
Hi Daniel.
I've just started working this Monday again, after a 2 week vacation period and in the meanwhile didn't have the opportunity to test this issue better.
Nevertheless since you felt confident with your patches ans closed the issue, i'll let you know if the bug pops up again, eventually, as suggested.
Thanks and keep up the good work.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=449#comment1610
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Sorry for putting this question on both dev and user mailing lists, as it
is a rather theoretical question and i hope some SIP guru on either mail
list will answer.
For non-WS endpoints which use TCP or UDP for SIP transport, each upstream
request has top most VIA header pointing to the previous hop which
forwarded the request to current hop while each downstream request has top
most VIA header pointing to next hop to which it will be forwarded from
current hop.
But for WS endpoints, the top most VIA has dummy static value, so there is
no way to identify who sent this request or to whom the reply is going to.
Please note that i am not specifically interested in network address of
remote endpoint (though VIA header is suppose to provide it), i only need
to match requests and responses from / to a specific device using SIP v2.0
standard.
Any help is highly appreciated.
Thank you.