I have been trying to accomplish a couple tasks with Kamailio over the past
month with no luck. What I need is a bit of one-on-one training with
someone who knows the lay of the land. If you do this kind of consulting
and can use Skype with possibly a shared-screen terminal, please drop me an
email with your rate.
Hello,
I used Kamailio+rtpproxy to record a session and rtpproxy outputs the
following files
long_file_name.a.rtp, long_file_name.a.rtcp, long_file_name.o.rtp,
long_file_name.o.rtcp
http://www.rtpproxy.org/wiki/RTPproxy/FAQ
From the Rtpproxy FAQ above, i tried to extract the audio using
rtpbreak and sox.
rtpbreak -W -r long_file_name.a.rtp
rtpbreak -W -r long_file_name.o.rtp
The above commands generate rtp.0.0.raw, rtp.1.0.raw.
Then when i run sox using
sox --combine merge -r 8k -A rtp.0.0.raw -r 8k -A rtp.1.0.raw -t wavpcm
-s out.wav i get the following errors :
sox: invalid option -- -
sox: -c must be given a number
Is there a switch/anything else that i am missing ?
Thanks in advance,
Regards,
Vikram.
Hello Stefan,
On 3/14/11 11:03 AM, Stefan Tiedje wrote:
> Thanks for the answer.
> Maybe I have some older versions of the OPENSER-MIB and the other
> related MIB's since I could not find the counter you pointed at. I'm
> using a MIB browser for reading the MIB's.
> Is the suggested counter "expired dialogs" added in a specific release
> of Kamailio? Which? We use Kamailio 3.0.2.
I used Kamailio and recommend using it sine it has the latest commits
for stability.
However, what I wrote before is pretty much not related to the version.
There is a counter that tracks the processed dialogs, but seems it is
not exported by default through snmpstats module. The statistics counter
is named "processed_dialogs", implemented by dialog module.
You can dump all internal statistics through kamctl or via xmlrpc
command, but probably to export it through snmpstats you may need to
extend the mibs and the code of the module.
I just grepped the sources of snmpstats module to see what dialog
statistics it is exporting:
$ grep -n _dialogs modules_k/snmpstats/* | grep get_statistic
modules_k/snmpstats/alarm_checks.c:83: num_dialogs =
get_statistic("active_dialogs");
modules_k/snmpstats/snmpObjects.c:404: int result =
get_statistic("active_dialogs");
modules_k/snmpstats/snmpObjects.c:424:
get_statistic("active_dialogs") -
modules_k/snmpstats/snmpObjects.c:425:
get_statistic("early_dialogs");
modules_k/snmpstats/snmpObjects.c:443: int result =
get_statistic("early_dialogs");
modules_k/snmpstats/snmpObjects.c:459: int result =
get_statistic("failed_dialogs");
modules_k/snmpstats/snmpObjects.c:508: int num_dialogs =
get_statistic("active_dialogs");
Perhaps when the snmpstats was developed the dialog module didn't export
the statistics counter of "processed_dialogs" and then it was not updated.
Now, what I tried to say is that if the "processed_dialogs" counter is
not available through snmpstats (and it is not now after grepping the
sources) you can get its value from another application through "kamctl
get_statistics all" or XMLRPC command for all of the existing kamailio
releases. Upcoming one we will look to implement the export through
snmpstats as well. If you have time to do it and send us a patch, we
will gladly commit it to source tree in our GIT repository.
Cheers,
Daniel
> Do you have the MIB name for the "expired dialogs" counter. I will
> look for that in my version of OPENSER MIBS.
> Important, do you have a link to where MIB files can be downloaded for
> Kamailio 3.0.2?
> Below follows an excerp from one of the MIB's. Is it old, I don't know?
>
> -- ***********************************************************************
>
> -- OPENSER-MIB: OPENSER MIB
>
> --
>
> -- Date of Creation: Januay 2006
>
> --
>
> -- This MIB provides information related to the OpenSER SIP Router.
>
> --
>
> -- Copyright (c) The Internet Society (2006)
>
> -- Ammendments (c) Soma Networks, Inc. (2006)
>
> --
>
> -- All rights reserved.
>
> -- *****************************************************************
>
> /Stefan
>
> ------------------------------------------------------------------------
> *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> *Sent:* den 14 mars 2011 10:16
> *To:* Stefan Tiedje
> *Cc:* sr-users(a)lists.sip-router.org
> *Subject:* Re: [SR-Users] OPENSER MIB
>
> Hello,
>
> On 3/14/11 9:42 AM, Stefan Tiedje wrote:
>> Hi,
>> In the Kamailio OPENSER-MIB there is the counter
>> "openserTotalNumFailedDialogSetups". This is a Counter32.
>> The description is:
>> "The total number of calls that failed with an error. The
>> following codes define a failed call:"
>> *Question:*
>>
>> * I'm looking for the corresponding counter to
>> "openserTotalNumFailedDialogSetups" who counts successful
>> Dialog setups of Counter32 type. Does it exist?
>> * If not, does it exist a work around?
>> * Where in the code can the new suggested counter be added?
>> * Something else????
>>
>
> the dialog module counts the number of processed dialogs, see:
> http://kamailio.org/docs/modules/stable/modules_k/dialog.html#id2966360
>
> There is no counter currently inside dialog module exporting exactly
> the number of successfully setup dialogs, it should not be hard to do
> it, though. Using the above and the number of failed and expired
> dialogs, you can actually get the number of successful dialogs.
>
> Dialog module being the one that tracks SIP dialogs, therefore being
> able to count them, now I don't know if snmpstats module exports all
> the counters from dialog module. I setup snmpstats just few weeks ago
> and works perfect on Ubuntu/Debian servers, but I had no need to check
> dialog module counters.
>
> Note that you can get the list of all internal statistics via kamctl:
> - kamctl fifo get_statistics all
>
> Or via XMLRPC if you need them remotely in another application.
>
> Another option is to define your statistics with statistics module.
> Knowing that in SIP a successful call dialog means 200ok reply to an
> INVITE transaction, you can count it in the onreply_route[abc] that
> you arm for relayed transactions with t_on_reply("abc").
>
> Hope these help you,
> Daniel
>
>> Suggestion for the new counter is a name like:
>> "openserTotalNumSucceededDialogSetups". It has a counter32.
>> Description: "The total number of calls that succeeded"
>> I know that there are the counters openserCurNumDialogs,
>> openserCurNumDialogsInProgress and openserCurNumDialogsInSetup but
>> these are of Gauge type who only reflects the current situation.
>> These Gauge counters can't be used together with a Counter32 counter.
>> That don't mix. The calculation done for the counter
>> "openserCurNumDialogsInProgress" should be used where every new
>> dialog setup is added to the new suggested counter. A counter of 32
>> should cover a great deal of connections. These counters are usually
>> read, if used, every 15 minutes or 1 hour.
>> *Rationale:*
>> The reason for the new counter is that a calculation between
>> succeeded and failed dialog setups can be done and be used for SLA
>> agreements. Without this, its hard to make any customer versus
>> provider agreements.
>> /Stefan
>> PS. Ask if anything is unclear and I need an answer rapidly.
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi,
my kamailio server is receiving from some customers 3 identical INVITEs when
call is initiated (separated by 200ms). Those 3 INVITEs are making a big
problem with call_control:
WARNING: call_control [call_control.c:1156]: dialog to trace controlled call
was not created. discarding callcontrol.
That is why, the prepaid limit is not working at all in this case. This way
the user can hack the prepaid protection of the account. Otherwise the
call_control is fuilly functional.
Anybody experienced the similar problem? If so, how to resolve it?
Thanks,
Mino Haluz
Hello
It presents a problem because I do not know how to assimilate the
implementation. Until now we had a design of a proxy to balance out between
several gateway, but it will add another proxy for another service (other
users) and use the same gateway output or perhaps different (although not
that be better if divide or unify the gateway). The problem as I have with
the routing entry, which is not very well how to implement it.
Now we have the design like this:
-GW ----\
/ - CARRIER1
USER ------ KAMAILIO ----- GW ---- +
\ - CARRIER2
-GW ----/
And becomes like this:
-GW ----\
/
- CARRIER1
USER ------ KAMAILIOSERVICE1 ----- GW ---- +
\
- CARRIER2
-GW ----/
-GW ----\
/
- CARRIER1
USER ------ KAMAILIOSERVICE2 ----- GW ---- +
\
- CARRIER2
-GW ----/
Or maybe using the same gateway.
The problem is that each carrier provides DID number (I use the same for
both services). Kamailio had thought to put a gateway between the carriers
and that they did check the service and send it to the corresponding gateway
(in the case of the gateway separately), or put it in the proxy gateway and
making checking for routing to proxy (in the case of using the same
gateway). What would be better? Any recommendations on how to put this into
practice?.
The biggest question that I believe is the routing table, as if this new
proxy routes the traffic into and leaves her in the field via ip, also pass
through the output data (I have doubts whether SIP level, following standard,
you can not pass through the exit) and want it to be direct (USER -> Proxy
-> GW -> CARRIER), just past the entrance.
Anyone could advise me where I could find more information to set up this
scenario?. thanks and sorry for bothering you with this question ;-).
best regards
Hi,
I'd just like to say that I found the answer to my own question in the documentation:
With 3.x versions, you have to load ctl and cfg_rpc modules and execute:
sercmd cfg.set_now_int core mem_dump_pkg <pid>
http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory
I did also write a patch to suppress the full memory dump, because I am only interested in the first lines of the status (total usage). This way I the server doesn't get blocked - full memory dump usually takes a VERY long time. Patch is attached and I'd be glad if something similar would be integrated in the trunk.
I've introduced a mem_summary option "16" to control that behavior.
Best regards,
Ricardo.
Hello,
Is there anything special that needs to be done for float comparison?
For example:
if([5.5 >= 4.3]) ....
or
if(5.5 > 4.3) ....
The conditional does not seem to be coming back as true like it should?
This is simply an example... the precision in the actual case is different
(longer decimal places).
Thank you for all and any help in advance!
Hello,
based on the last devel IRC meeting, the next major release should
happen sometime by end of September, therefore we should freeze the
development and go into testing phase about one month before.
I propose Monday, August 22, the day to freeze development for version
3.2.0. By then, I hope every developer will be able to push to master
branch what he/she wants to have in 3.2.0. Write here to mailing lists
if you thing about alternatives.
The very good side of 3.2.0 is that we didn't need to touch much the
core and main modules, meaning we have a solid tested foundation,
further testing should be focused on the new modules and the other
enhancements.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi all,
we are trying to setup a kamailio presence server in SIP/SIMPLE domain
to interwork with XMPP domains including the GTalk (see the config
below). The architecture is like this:
- SIP/SIMPLE server: kamailio3.14 with full configuration with XCAP integration
- XMPP Gateway: another kamailio server + ejabberd server
- component mode
- xmpp moduleL: outbound proxy to the Kamailio SIP/SIMPLE server
- pua_xmpp: no outbound proxy?
- XMPP server: ejabberd
The users from XMPP domain can add the SIP account and see the
presence of the SIP users, but not vice versa. The chat from both
directions works fine.
in the Presence Server, we have configured the kamailio with XCAP
integration. We have the following doubts:
- does pua_xmpp/pua modules need the xcap integration for the presence
integration with xmpp domains?
because to use xcap for presence authorization rules, it needs the
sip clients support the xcap
- does pua_xmpp/pua support xcap? otherwise how to works?
- in case of multiple SIP/SIMPLE presence server, how we can configure
the server_address of
pua_xmpp and presence parameter in xmpp gw?
Can you help us to clarify the doubts please?
Many thanks in advanced!
Best Regards,
Laura
PS: following are the main configuration of the xmpp GW:
---------------------------------------------------------------------------------------------
...
modparam("xmpp", "domain_separator", "*")
modparam("xmpp", "backend", "component")
modparam("xmpp", "gateway_domain", "<mygwdomain>")
modparam("xmpp", "xmpp_domain", "<mygwdomain>")
modparam("xmpp", "xmpp_host", "127.0.0.1")
modparam("xmpp", "xmpp_password", "secret")
modparam("xmpp", "outbound_proxy", "<my oubound proxy uri>")
modparam("pua", "outbound_proxy", "<my outbound proxy uri>")
modparam("pua", "update_period", 60)
modparam("pua", "default_expires", 1200)
modparam("presence", "server_address", "<my presence server uri>")
modparam("pua_xmpp", "server_address", "<my presence server uri>")
route{
route(REQINIT);
t_check_trans();
if (uri =~ "sip:.+@.*<myxmppdomain>") {
route(PRESENCE);
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(CHAT);
}
xlog("L_INFO", "*** xmpp: unhandled message type\n");
t_reply("503", "Service unavailable");
return;
}
...
route[CHAT] {
if(!is_method("MESSAGE"))
return;
if (!t_newtran()) {
sl_reply_error();
exit;
}
xlog("L_INFO", "*** xmpp-handled MESSAGE message.");
if ($cT=~"^text/plain") {
if (xmpp_send_message()) {
t_reply("200", "Accepted");
} else {
t_reply("404", "Not found");
}
} else {
xlog("L_INFO", "*** xmpp-handled MESSAGE, ignoring not text messages");
t_reply("200", "Accepted");
}
t_release();
exit;
}
route[PRESENCE] {
if(!is_method("PUBLISH|SUBSCRIBE|NOTIFY"))
return;
# create new transaction to catch retransmissions
if (!t_newtran())
{
sl_reply_error();
exit;
}
if( is_method("NOTIFY"))
{
xlog("L_INFO", "*** xmpp-handled NOTIFY message.");
if(pua_xmpp_notify())
t_reply("200", "OK");
t_release();
exit;
} else if( is_method("SUBSCRIBE"))
{
xlog("L_INFO", "*** xmpp-handled SUBSCRIBE message.\n");
handle_subscribe();
if($(hdr(Event))== "presence")
{
pua_xmpp_req_winfo("$ruri", "$hdr(Expires)");
}
t_release();
exit;
} else if(is_method("PUBLISH"))
{
handle_publish();
t_release();
exit;
}
}
...