On Tuesday 26 January 2010, Vikram Ragukumar wrote:
> I came across a post by Stefan Sayer regarding an rtpproxy transcoder
> patch http://lists.iptel.org/pipermail/serdev/2008-July/012794.html.
> We are interested in having rtpproxy perform transcoding, both in
> software and using DSP array cards, and are currently running rtpproxy
> version 1.2.1.
> Is this link http://user.cs.tu-berlin.de/~sayer/transcoder/ that is
> mentioned on the post our starting point or is there an updated
> version ?
Hi Vikram,
I don't know about this particiular case, so I can't give you more
informations in this regards. But i think Stefan read this list as well, if
you don't get a reply here perhaps you can contact him direcly by mail, if you
have not tried this yet.
Cheers,
Henning
Hi, under 1.5 cookbook I see some stuf related to Kamailio 3.0. For example
"debug" values are those for SR (if I'm not wrong) and the appearing command
to change debug leves uses "sercmd" rather than "kamctl":
http://kamailio.org/dokuwiki/doku.php/core-cookbook:1.5.x#debug
Is it correct?
--
Iñaki Baz Castillo <ibc(a)aliax.net>
For reference:
http://kamailio.org/dokuwiki/doku.php/install:1.5.x-to-3.0.0
It helps to upgrade to 3.0.0, feel free to add to the page.
In this particular case, kex initializes mi engine ad registers core
commands.
Still don't see the dr_reload, probably the command is not registered by
module's mod init. I will check.
Cheers,
Daniel
On 1/27/10 6:43 AM, Denis Putyato wrote:
>
> After load kex:
>
> root@ubuntutest:/kamailio# kamctl fifo which
>
> shv_get
>
> shv_set
>
> sip_trace
>
> dp_reload
>
> dp_translate
>
> lcr_reload
>
> lcr_gw_dump
>
> lcr_lcr_dump
>
> cr_reload_routes
>
> cr_dump_routes
>
> cr_replace_host
>
> cr_deactivate_host
>
> cr_activate_host
>
> cr_add_host
>
> cr_delete_host
>
> uptime
>
> version
>
> pwd
>
> arg
>
> which
>
> kill
>
> ps
>
> debug
>
> get_statistics
>
> reset_statistics
>
> *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> *Sent:* Tuesday, January 26, 2010 9:00 PM
> *To:* Denis Putyato
> *Cc:* users(a)lists.kamailio.org
> *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0
>
>
>
> On 1/26/10 1:01 PM, Denis Putyato wrote:
>
> root@ubuntutest:/kamailio# kamctl fifo which
>
> 500 command 'which' not available
>
>
> do you have the kex module loaded?
>
> Any fifo command that works for you?
>
> Cheers,
> Daniel
>
>
> root@ubuntutest:/kamailio#
>
> *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> *Sent:* Tuesday, January 26, 2010 2:55 PM
> *To:* Denis Putyato
> *Cc:* users(a)lists.kamailio.org <mailto:users@lists.kamailio.org>
> *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0
>
>
>
> On 1/26/10 12:35 PM, Denis Putyato wrote:
>
> I do not use lcr routing in config (only gw table is used).
>
> ok
>
>
>
> Not in kamailio 1.5 nor 3.0. I use carrierroute (in 1.5) and now
> drouting (in 3.0).
>
> By the way. Recently you helped me with drouting. Can I ask one more
> question about this module?
>
> When I try to do "kamctl fifo dr_reload" I receive "500 command
> 'dr_reload' not available".
>
>
> do:
>
> kamctl fifo which
>
> Should list available MI commands, is dr_reload there?
>
> Cheers,
> Daniel
>
>
>
> *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> *Sent:* Tuesday, January 26, 2010 12:43 PM
> *To:* Denis Putyato
> *Cc:* users(a)lists.kamailio.org <mailto:users@lists.kamailio.org>
> *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0
>
>
>
> On 1/26/10 10:38 AM, Denis Putyato wrote:
>
> Daniel thank you. Now it's working
>
>
> welcome! Be sure you understand the idea behind the instances. Not
> being a user of lcr don't know exactly the internal architecture, so
> as I understood from discussions on mailing lists, you can have more
> lcr instance on same kamailio grouped under same value of lcr_id (many
> gws and lcr rules with same lcr_id).
>
> Cheers,
> Daniel
>
>
>
>
> *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> *Sent:* Tuesday, January 26, 2010 12:31 PM
> *To:* Denis Putyato
> *Cc:* users(a)lists.kamailio.org <mailto:users@lists.kamailio.org>
> *Subject:* Re: [Kamailio-Users] LCR module in Kamailio 3.0
>
> Hello,
>
> On 1/26/10 7:33 AM, Denis Putyato wrote:
>
> Hello everybody!
>
> I have a such problem with LCR module
>
> When I add a new gw in gw table via kamctl addgw or direct via mysql
> command, never mind, after doing lcr reload, in memory loaded only gw
> with lcr_id = 1.
>
> All other gateways, with lcr_id > 1, not loaded into memory, so I
> cannot use them.
>
> (After lcr reload I do lcr dump and only gateways whis lcr_id = 1 can
> be seen)
>
> Thank you for any help.
>
> P.S. lcr table, where lcr_id is present too, is empty. It does not
> need for processing in my kamailio. Only gw table is used.
>
> Kamailio 3.0 was installed from GIT.
>
> maybe is related to lcr_count parameter:
>
> http://kamailio.org/docs/modules/3.0.x/modules/lcr.html#id2495949
>
> AFAIK, there were some changes in lcr by adding instances, which are
> hold in lcr_id (gws to same instance have same id).
>
> Cheers,
> Daniel
>
>
>
>
> --
> Daniel-Constantin Mierla
> *http://www.asipto.com/
>
>
>
>
>
> --
> Daniel-Constantin Mierla
> *http://www.asipto.com/
>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users(a)lists.kamailio.org <mailto:Users@lists.kamailio.org>
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> --
> Daniel-Constantin Mierla
> *http://www.asipto.com/
>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users(a)lists.kamailio.org <mailto:Users@lists.kamailio.org>
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> Daniel-Constantin Mierla
> *http://www.asipto.com/
--
Daniel-Constantin Mierla
* http://www.asipto.com/
Hello everybody!
I have a such problem with LCR module
When I add a new gw in gw table via kamctl addgw or direct via mysql
command, never mind, after doing lcr reload, in memory loaded only gw with
lcr_id = 1.
All other gateways, with lcr_id > 1, not loaded into memory, so I cannot
use them.
(After lcr reload I do lcr dump and only gateways whis lcr_id = 1 can be
seen)
Thank you for any help.
P.S. lcr table, where lcr_id is present too, is empty. It does not need for
processing in my kamailio. Only gw table is used.
Kamailio 3.0 was installed from GIT.
Hello,
I came across a post by Stefan Sayer regarding an rtpproxy transcoder
patch http://lists.iptel.org/pipermail/serdev/2008-July/012794.html.
We are interested in having rtpproxy perform transcoding, both in
software and using DSP array cards, and are currently running rtpproxy
version 1.2.1.
Is this link http://user.cs.tu-berlin.de/~sayer/transcoder/ that is
mentioned on the post our starting point or is there an updated
version ?
Thanks and Regards,
Vikram.
Hello,
There seems to be a design problem in proxy.c mk_proxy(str* name,
unsigned short port, unsigned short proto,
int is_sips) function. The purpose of this function is to create
a proxy and return a pointer to the
created structure.
The issue arises from the fact that the name (type struct str) member of
the proxy structure is not deep copied from the given parameters(refer
to the str* name ) (the hostent structure is instead deep copied). This
isn't a problem for now but I have worked on a small patch that caches
proxies (using add_proxy() and find_proxy()) and ,because of this
shallow copy, things are broken.
I said that this is a design problem because we can let the shallow copy
happen (performance is better), and when needed the caller should
provide a buffer that doesn't change (let him do the copy instead). This
is not clearly documented but done from /modules(_k)/utils/conf.c. But
it this way we may have a memory leak when the proxy is deallocated,
because I doubt that the caller keeps track of the allocated buffers(the
code in proxy.c doesn't take ownership of the given pointer).
This affects functions mk_proxy and mk_shm_proxy in both kamailio(1.5 to
speak of) and sip-router.
I have created a patch that also does a deep copy of the name, thus
removing the need for the caller to bother about the lifetime of the
name buffer.
Any ideas?!
Cheers
Marius
> Hi Daniel,
>
> This is my ACC configuration:
>
> # ----- acc params -----
> /* what sepcial events should be accounted ? */
> modparam("acc", "early_media", 1)
> modparam("acc", "report_ack", 1)
> modparam("acc", "report_cancels", 1)
> /* by default ww do not adjust the direct of the sequential requests.
> if you enable this parameter, be sure the enable "append_fromtag"
> in "rr" module */
> modparam("acc", "detect_direction", 0)
> /* account triggers (flags) */
> *modparam("acc", "failed_transaction_flag", 3)*
> modparam("acc", "log_flag", 1)
> modparam("acc", "log_missed_flag", 2)
> modparam("acc", "log_extra",
>
> "src_user=$fU;src_domain=$fd;dst_to_user=$tU;dst_user=$rU;dst_domain=$rd;diversion_uri=$di;destination_uri=$du;display_name=$fn;orig_src_domain=$od;orig_req_uri=$ou;orig_username=$oU;prefered_identity=$pd;display_name_pref_ident=$pn;proxy_ip=$Ri;proxy_port=$Rp;src_ip=$si;dst_dom_uri=$td;user_agent=$ua")
> /* uncomment the following lines to enable DB accounting also */
> modparam("acc", "db_flag", 1)
> modparam("acc", "db_missed_flag", 2)
> modparam("acc", "db_url",
> "mysql://openser:openserrw@localhost/openser10")
> modparam("acc", "db_extra",
>
> "src_user=$fU;src_domain=$fd;dst_to_user=$tU;dst_user=$rU;dst_domain=$rd;diversion_uri=$di;destination_uri=$du;display_name=$fn;orig_src_domain=$od;orig_req_uri=$ou;orig_username=$oU;prefered_identity=$pd;display_name_pref_ident=$pn;proxy_ip=$Ri;proxy_port=$Rp;src_ip=$si;dst_dom_uri=$td;user_agent=$ua")
>
> I run kamailio-1.5.3 no TLS
>
> What exactly is iirc?
>
> When i call from an user to an other and the call is passing in case of
> failure from failure route1 then I get an extra cdr from the failure route1
> BUT when I call pstn and the call goes to Failure route2 then I don't get
> the extra CDRs. One important diference between Failure route1 and 2 is that
> in the Failure route2 I have an extra *append_branch();*
>
> Failure Route 1 (default)
>
> failure_route[1] {
> xlog("alx ------- Failure Route 1 -------");
> #n# if (is_method("INVITE")
> #n# && (isbflagset(6) || isflagset(5))) {
> #n# unforce_rtp_proxy();
> #n# }
>
> if (t_was_cancelled()) {
> exit;
> }
>
> # uncomment the following lines if you want to block client
> # redirect based on 3xx replies.
> ##if (t_check_status("3[0-9][0-9]")) {
> ##t_reply("404","Not found");
> ## exit;
> ##}
>
> # uncomment the following lines if you want to redirect the failed
> # calls to a different new destination
> ##if (t_check_status("486|408")) {
> ## sethostport("192.168.2.100:5060");
> ## append_branch();
> ## # do not set the missed call flag again
> ## t_relay();
> ##}
> }
>
> Failure Route2
>
>
> failure_route[2] {
>
> if(t_was_cancelled()) {
> exit;
> }
>
> if(t_check_status("4[0-9][0-9]|5[0-9][0-9]"))
> {
>
> #xlog("ACCOUNTING:
> src_user=$fU;src_domain=$fd;dst_to_user=$tU;dst_user=$rU;dst_domain=$rd;diversion_uri=$di;destination_uri=$du;display_name=$fn;orig_src_domain=$od;orig_req_uri=$ou;orig_username=$oU;prefered_identity=$pd;display_name_pref_ident=$pn;proxy_ip=$Ri;proxy_port=$Rp;src_ip=$si;dst_dom_uri=$td;user_agent=$ua;sip_replay_reson=$rr;sip_replay_status=$T_reply_code");
>
> if(ds_next_domain())
> {
> xlog("alx ------------------------------------- The final RU is
> $rU and the cust_prefix:$avp(s:cust_prefix) --------");
> xlog("alx ------- [ FAILURE ROUTE 2 ] First part of failure with
> rd = $rd and prefix = $(ru{uri.param,prefix}) ---");
> # more destinations from same dispatcher group
>
> # add prefix if set and remove the param from R-URI
> if($(ru{uri.param,prefix})!=null)
> {
> $ru = "sip:" + $avp(s:cust_prefix) +
> $(ru{uri.param,prefix}) + $avp(s:user) + "@" + $rd;
> } else {
> $ru = "sip:" + $avp(s:cust_prefix) + $avp(s:user) + "@" +
> $rd;
> }
> #rewriteport(5065);
> #setport("5065");
> t_on_failure("2");
> *append_branch();*##################################################################### This
> is different !!!!!!!!!!!!!!!!!!
> t_relay();
> exit;
> } else {
> # go to next dispatcher group
> xlog("alx ------- This is the next DST group = $avp(s:dstgrp)
> -------");
>
>
> if($avp(s:dstgrp)!=null)
> {
> # select destination
> if(ds_select_domain("$avp(s:dstgrp)", "4"))
> {
> xlog("alx ------- [ FAILURE ROUTE 2 ] Second part of
> failure with rd = $rd and prefix = $(ru{uri.param,prefix}) ---");
> xlog("alx ------------------------------------- The
> final RU is $rU and the cust_prefix:$avp(s:cust_prefix) --------");
> # add prefix if set and remove the param from R-URI
> if($(ru{uri.param,prefix})!=null)
> {
> $ru = "sip:" + $avp(s:cust_prefix) +
> $(ru{uri.param,prefix}) + $avp(s:user) + "@" + $rd;
> } else {
> $ru = "sip:" + $avp(s:cust_prefix) + $avp(s:user)
> + "@" + $rd;
> }
> $avp(s:dstgrp) = null;
> xlog("alx ------- This is the next DST group after
> NULL = $avp(s:dstgrp) -------");
> xlog("alx ------- The final RURI is $ru ------- ");
> t_on_failure("2");
> *append_branch();*#####################################################################
> This is different !!!!!!!!!!!!!!!!!!
> t_relay();
> exit;
> }
> } else {
> t_reply("444", "No more tries for you!");
> }
> }
> }
>
>
>
> Thanks
> Alex
>
>
>
>
> On Mon, Jan 25, 2010 at 12:39 PM, Daniel-Constantin Mierla <
> miconda(a)gmail.com> wrote:
>
>> Hi Alex,
>>
>>
>> On 1/25/10 11:03 AM, alex pappas wrote:
>>
>> Hi Daniel,
>>
>> We make a call and the call tries from the Failure Route 5 times new
>> gateway (with dispatcher) but WITHOUT success in termination. In every try
>> we get back 503 Congestion. In this case how many CDRs we should see in our
>> LOG.
>>
>> We have the modparam("acc", "failed_transaction_flag", 6) and we
>> setflag(6) for every INVITE.
>>
>> iirc, at some point was an option to get all failed legs accounted. I
>> don't remember using it so I have to check the sources (you are on 1.5.x,
>> right?).
>>
>> For next version I plan to make acc functions available on rest of the
>> routes, should be few updates to take sip method from cseq header and ignore
>> r-uri if it is a reply processed, in failure route should work by default, I
>> see no reasons now what could be the problem.
>>
>> Cheers,
>> Daniel
>>
>>
>> On Fri, Jan 22, 2010 at 3:33 PM, Daniel-Constantin Mierla <
>> miconda(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>>
>>> On 1/22/10 1:08 PM, alex pappas wrote:
>>>
>>>> Dear Friends,
>>>>
>>>> In case of a call failure I'm trying from failure route to send the call
>>>> through other gateways with Dispatcher module.
>>>> I would like to have ACC for all failures that a call can possibly pass.
>>>> If the call fails in the 3 first gateways I want them also in my mysql ACC
>>>> table. I tried that with AVPs in the syslog and it works fine BUT is there
>>>> any way that I can simply setflag(1) for accounting and I can have ACC for
>>>> every try?
>>>>
>>>> I tryied to add in failure route :
>>>>
>>>> setflag(1); # do accounting ...
>>>> setflag(3); # ... even if the transaction fails
>>>>
>>>> but I'm getting ACC only the last try.
>>>>
>>>> last failed try? Or what you mean by "the last try"? IIRC, failed
>>> transaction flag should be set for each leg if you want all failures.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> --
>>> Daniel-Constantin Mierla
>>> * http://www.asipto.com/
>>>
>>>
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>>
>> --
>> Daniel-Constantin Mierla
>> * http://www.asipto.com/
>>
>>
>
Hello,
I'd like to use dispatcher module with Berkeley DB.
How can I manipulate the dispatcher table, I mean, insert or delete gateways?
kamctl seems not to work:
[root@vnsiprtest ~]# kamctl dispatcher addgw 1 '1.2.3.4' 1 'test'
/usr/local/sbin/kamctl: line 1458: insert into dispatcher
( setid, destination, flags, description )
VALUES (1,'1.2.3.4',1,'test');: command not found
ERROR: dispatcher - SQL Error
Thank you.
Santiago
Hello,
I have worked lately on the patch that tries to mitigate one performance
problem in core:action.c file. I am talking about the multiple
calls to mk_proxy(), and the creation of temporary proxies for each
FORWARD_T action that the daemon executes.
I think this behaviour can be improved by caching certain proxies. My
idea is this:
* If the next_hop matches a name in the alias list (for example we
have an alias for example.com and the next_hop is proxy1.example.com),
then cache the proxy by calling add_proxy instead of mk_proxy. If the
proxy is already cached a pointer is returned, if not it is created and
added (the functionality already exists in proxy.c)
* For all other hosts a temporary proxy is made(same as now).
This whole logic can be turned off(default)/on by a parameter in .cfg.
I have run some tests and this can lead to big improvemets (because
mk_proxy mean some pkg_malloc - fast but also some DNS resolving -
slow). This might benefit some medium-large setups where you have some
servers forwarding request to other application servers, etc.
The patch is very small and it's already done and finished. I will
provide it tomorrow if somebody thinks this idea is good
Cheers
Marius
Hello all,
I've questions 'bout the redirect/forward with 30x requests.
Actually, it does not work, it seems the uac redirect module doesn' t use
the new contact for the new invite.
simple schema : pstn gw -> kamailio -> linksys -> call forward
unconditionnal to another pstn number -> kamailio -> gw pstn
the 302 as seen with ngrep tool :
#SIP/2.0 302 Moved Temporarily.
#To: <sip:B@sip_proxy;user=phone>;tag=91515579fff6b8d1i0.
#From: <sip:A@pstn_gw1;user=phone>;tag=16627-UI-00020cf3-54eea92c4.
#Call-ID: 16627-RO-00020cf2-4186e9762@pstn_gw1.
#CSeq: 81990 INVITE.
#Via: SIP/2.0/UDP sip_proxy;branch=z9hG4bK0f0c.22989b87.1.
#Via: SIP/2.0/UDP
pstn_gw1:5060;rport=5060;received=ip_pstn_gw1;branch=z9hG4bK-25EA-243F3.
#Record-Route:
<sip:sip_proxy;lr=on;ftag=16627-UI-00020cf3-54eea92c4;did=f65.bcc44f06>.
#Contact: <sip:C@sip_proxy>.
#Diversion: "B" <sip:B@sip_proxy>;reason=unconditional.
#Server: Linksys/SPA942-6.1.3(a).
DBG:uac_redirect:shmcontact2dset: adding contact <sip:C@sip_proxy>
dest set : Contact: sip:B@ip_B, <sip:C@sip_proxy>;q=0.01
contact $ct: <sip:pstn_gw1:5060>
the second pstn gateway received a request to B, and not C (so it creates a
loop through pstn ...).
in my config :
loadmodule "uac.so"
modparam("uac", "rr_store_param", "vsf")
modparam("uac", "from_restore_mode", "auto")
loadmodule "uac_redirect.so"
modparam("uac_redirect", "default_filter", "accept")
modparam("uac_redirect","bflags", 1)
loadmodule "diversion.so"
failure_route[2]
{
setdebug(4);
if (t_check_status("301|302"))
{
route(26) # acc fwd
$avp(s:acc_status) = "cfu";
if (!get_redirects("2:1"))
{
xlog("L_NOTICE", "failed to extract contact info
from 30x header");
route(10); # stop rtp
t_reply("480", "Temporarily Unavailable");
exit;
}
# flag 3xx status, open a new branch and back to find the
new callee
setflag(28);
append_branch();
t_on_branch("1");
route(3); # search the new callee
setdebug();
exit;
}
t_on_branch("1");
setdebug();
route(3); # find callee
route(12); # local outbound
route(10); # stop rtp
}
I'm using lcr module to route calls, kamailio v. 1.5.3.
I've another question, is the 30x always considered as a failure_route ?
Any help and/or explanations about the tricks would be really appreciated
... thanks,
--
Samuel MULLER
sml(a)l33.fr