sr-users March 2011

sr-users@lists.kamailio.org

83 participants
123 discussions

Watch algeria 3 TV 29 march at 07:00pm GMT
by Meftah Tayeb 27 Mar '11

27 Mar '11

hi guys, please everyone that have access to Neal SAT or Arab sat try to lookup algeria 3 TV channel and watch it starting from 07:00pm gmt time the TV channel have made a show about me, including my blind / tech life please check;) -- Meftah Tayeb inum: +883510001288000 phone: +13477595883

1 0

Managing SUBSCRIBES
by Spinov Evgeniy 27 Mar '11

27 Mar '11

Hello, everyone. I've got stuck with a small problem with SUBSCRIBES. Let's say we have 2 separate customers with IDs: 1 and 2. They have 2 extenstions each: 1_100, 1_101 and 2_100, 2_101. The task is to subscribe 1_100 to 1_101. When I assign on DSS ( BLF ) key, phone number 1_101, then everything works perfectly, however, I cannot press this DSS key and get connected with 101 as prefix will break the magic. The question is there any workaround for this issue except cutting of the prefix for INVITE requests each time? Or how correctly to implement multi tenant kamailio? Thanks.

1 0

[Kamailio-Users] Rewrite $tU
by Spinov Evgeniy 27 Mar '11

27 Mar '11

>Hello, >with the latest version there are alternatives you can use: >> On 12/10/09 5:06 PM, David wrote: >> Hey, >> >> I won't pretend to be an expert in Kamailio, someone will probably >> suggest a better way. But here is how I rewrote my SIP packet's TO >> header before relaying it to the next hop : >> >> # Rewrite RURI >> avp_printf("$rU", "prefix_$rU"); >$rU = "prefix_" + $rU; >> >> # Remove existing header >> remove_hf("To") ; >> >> # Add new header which is copied from RURI >> insert_hf("To: $ru\r\n", "From"); >you can do in one step, so you avoid operations on r-uri: >insert_hf("To: sip:prefix_$rU@$rd\r\n", "From"); >> >> >> DISCLAIMER : Several threads have said that changing the TO header is >>a bad idea, so I only recommend using this as a last resort. >If devices are RFC3261 (SIP 2.0), then it is ok. If there are SIP 1.0 >devices, then you have to preserve To/From header. >For the future, I would add options to change the From/To values via >pseudo-variables. It is the admin to decide to use it or not -- now >people need and do workarounds with subst or append_hf(). >Cheers, >Daniel I use Kamailio 3.0.3, and tried to use both of methods, i.e. insert_ft() and reassigning pseudo variable $rU and all mentioned in this topic. However, handle_subscribe() and dlg_manage() somewhy uses unmodified packet. Is there any workaround to handle $rU or $tU overwrites that for pua_dialoginfo module? I'm doing it like that: $var(orig_uri) = $rU; $rU = $(fU{re.subst,/(.*)_(.*)/\1/}) + "_" + $rU; if (is_method("INVITE")) { dlg_manage(); } if (is_method("SUBSCRIBE")) { handle_subscribe(); } $rU = $var(orig_uri); However, according to debug messages, NOTIFY's which are coming just after INVITE are still without prefixes, but packets on Asterisk, which is after Kamailio, are coming modified. Please, advice. > > David > > > > > > David a écrit : >> Hey, >> >> I do understand that normally the TO header should not be written, my >> problem is that I am using the presence_dialoginfo module which uses the >> TO header and not the RURI, which means that in order to tell the >> difference between customer A's extension 101 and Customer B's extension >> 101, I rewrite the TO header to add context. >> >> This is actually the ame problem that I started discussing here : >> http://lists.kamailio.org/pipermail/users/2009-August/024316.html >> >> Trouble is I have not had time to work on this since then. >> >> Thanks, >> >> David >> >> Olle E. Johansson a écrit : >>> 10 dec 2009 kl. 15.04 skrev Iñaki Baz Castillo: >>> >>> >>>> El Jueves, 10 de Diciembre de 2009, David escribió: >>>>> Hey, >>>>> >>>>> I need to rewrite the $tU variable on a packet before it is >>>>> relayed. It >>>>> is ok if the change is only on the relayed packet and the $tU >>>>> variable >>>>> change. The important thing is that I modify the To header, it seems >>>>> that rewritting $tU would be the easiest. >>>> $tU is not writable, but just readable. >>>> If you want to change the "To" header you should do some "dirty" >>>> replacing operation (see textops module). >>> >>> This is propably something we need to change and make the To and >>> From headers writable. >>> It's not dirty to change them any more. >>> >>> David: In the original SIP 1.0 protocol the To/From headers was part >>> of the dialog identification, thus you where not allowed to change >>> them in a proxy. THis was kept in RFC3261 - sip v2 - but has been >>> removed in an additional RFC a short while ago (seen from SIP history). >>> >>> Regards, >>> /O >>> _______________________________________________ >>> Kamailio (OpenSER) - Users mailing list >>> Users at lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Kamailio (OpenSER) - Users mailing list >> Users at lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users at 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/

3 10

Presence, RLS, and NAT Traversal
by Peter Dunkley 26 Mar '11

26 Mar '11

Hello, I am using Kamailio and nathelper to connect UAs behind a NAT. However, I want to use presence and RLS in this system as well. The problem I have is that the presence and RLS modules are not nathelper aware and the NOTIFY requests that they generate are targeted at the private network IP address and port of the UA. Has anyone any experience of this? Can anyone help? I had a cunning plan where, in route[NAT], I detected SUBSCRIBE requests that originate from behind a NAT (and do not have myself as the last hop). When I see a request like this I use add_contact_alias(), record_route() and forward it to myself. I then added a handle_ruri_alias() to the WITH_NAT section of route[RELAY]. The theory being that an in-dialog NOTIFY from presence or RLS will use the route-set established by the SUBSCRIBE transaction. This almost works. The presence.winfo NOTIFY from the presence module and the initial presence NOTIFY from the RLS module make it back to the client successfully. However, when this forwarding of the SUBSCRIBE is in place the RLS subscriptions don't happen. I know it is the forward of the SUBSCRIBE that is the trigger behind this problem because simply commenting that out (and allowing the first SUBSCRIBE to get to RLS) makes the RLS subscriptions happen (but in this case the NOTIFYs get back to the client and are 404'd because the request URI is not correct). The only difference between the first SUBSCRIBE and the forwarded SUBSCRIBE is an additional "Via:" header and a "Record-Route:" header. I ran Kamailio with the -E -ddd options and observed that: * modules_k/rls/subscribe.c:rls_get_service_list() is outputting the line "searching document for user sip:@" * This function is called by modules_k/rls/subscribe.c:rls_handle_subscribe() and the output suggests that GET_FROM_PURI(msg)->user and GET_FROM_PURI(msg)->host are empty strings * However, parse_from_header(msg) is called near the top of rls_handle_subscribe() and clearly succeeds to find the "From:" header in the message * As I mentioned above the forwarded SUBSCRIBE is almost identical to the first SUBSCRIBE, and so it does contain a valid "From:" header All I can think of is that Kamailio is becoming confused by the two near-identical SUBSCRIBE requests and that the "cleaning up" of the first (statelessly forwarded) SUBSCRIBE is also "cleaning up" the forwarded SUBSCRIBE that I am currently working with? My route[NAT]: route[NAT] { xlog("L_INFO", "$rm: route[NAT]\n"); #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19") && $si!="MY_REAL_IP" && $si! ="127.0.0.1") { xlog("L_INFO", " Request from NAT'd UAC\n"); if (is_method("REGISTER")) { fix_nated_register(); } else if (is_method("SUBSCRIBE")) { add_contact_alias(); route(RECORD_ROUTE); forward(127.0.0.1, MY_REAL_PORT); exit; } else { fix_nated_contact(); } setflag(FLT_NATS); } #!endif return; } My route[RECORD_ROUTE]: route[RECORD_ROUTE] { # remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); return; } The start of my route[RELAY]: route[RELAY] { xlog("L_INFO", "$rm: route[RELAY]\n"); #!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) { route(RTPPROXY); } handle_ruri_alias(); #!endif Regards, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd

3 8

uri unescape transformation?
by Juha Heinanen 26 Mar '11

26 Mar '11

i could not find a transformation or function to unescape an uri, such as this: sip%3Atest%40test.fi did i miss it or is there a need to write one? -- juha

3 3

uri unescape transformation?
by Juha Heinanen 26 Mar '11

26 Mar '11

i could not find a transformation or function to unescape an uri, such as this: sip%3Atest%40test.fi did i miss it or is there a need to write one? -- juha

3 6

issue: fr_inv_timer_avp in Kamailio 3.1
by Min Wang 26 Mar '11

26 Mar '11

Hi I am trying to use fr_inv_timer_avp like the following in Kamailio 3.1: #!KAMAILIO ... modparam("tm", "fr_inv_timer_avp", "$avp(i:2)") modparam("tm", "fr_inv_timer", 180000) .. $avp(i:2)=10 ... # t_set_fr(10000); ... t_on_failure("failroute"); It seems it is not working. the invite will timeout in 3 min, not 10 seconds. If t_set_fr is used, it is working ( 10 seconds timeout). the t_set_fr issue is it can only accept the constant, not avp. I saw there was a discussion in the april 2010, http://lists.sip-router.org/pipermail/sr-users/2010-April/027101.html Not sure fr_inv_timer_avp has been tested or not in Kamailio 3.0/3.1? A bug or my misuage the fr_inv_timer_avp? thanks -- Kind regards / Mit freundlichen Grüßen Min Wang BASIS AUDIONET North America BASIS AUDIONET * 716 N. Bethlehem Pike - Suite 300 * Lower Gwynedd * PA 19002 * USA Phone +1 215 674 8600 ext 451 Fax +1 215 646 4959 wang(a)basis-audionet.com www.basis-audionet.com Europe BASIS AUDIONET GmbH * Jessenstraße 4 * 22767 Hamburg * Germany Phone +49 40 85 31 14-0 Fax +49 40 85 31 14-33 www.basis-audionet.de Registered: Hamburg HR B 85866 Managing Director: Lutz Schaffhausen, Rüdiger Kaun

3 8

RES: event_route and acc_db_request().
by Alexandre Abreu 26 Mar '11

26 Mar '11

Hi Daniel, Using 'xmlrpc' and 'mi' it works. When I finish this project, I will write a small text explaining the steps I did to make this work. Maybe this will benefit more people from the community. Thank you. Alexandre -----Mensagem original----- De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: quinta-feira, 24 de março de 2011 03:51 Para: Alexandre Abreu Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List' Assunto: Re: RES: RES: [SR-Users] event_route and acc_db_request(). Hello, the method name is 'mi' then the first parameter is dlg_terminate_dlg and the next parameters are the ones required by the dlg_terminate_dlg. The XMLRPC command 'mi' is to execute commands from the old control interface that we named MI: http://kamailio.org/docs/modules/stable/modules/mi_rpc.html#id2945832 Cheers, Daniel On 3/23/11 4:30 PM, Alexandre Abreu wrote: > Hi Daniel, > > Look the request/reply. > > <...> > <?xml version="1.0" encoding="UTF-8"?>. > <methodCall>. > <methodName>mi dlg_terminate_dlg</methodName>. > <params>. > <param><value><string>065fa668d8485f33</string></value></param>. > </params>. > </methodCall>. > > <...> > <?xml version="1.0"?> > <methodResponse> > <fault> > <value> > <struct> > <member> > <name>faultCode</name> > <value><int>500</int></value> > </member> > <member> > <name>faultString</name> > <value><string>Method Not Found</string></value> </member> </struct> > </value> </fault> </methodResponse> > > This is module xmlrpc handling the POST at route[XMLRPC]. I am not > sure if I understand correctly how you suggested the use of 'mi dlg_terminate_dlg' > command. > > Thanks, > Alexandre > > -----Mensagem original----- > De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: > quarta-feira, 23 de março de 2011 11:10 > Para: Alexandre Abreu > Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List' > Assunto: Re: RES: [SR-Users] event_route and acc_db_request(). > > Hello, > > On 3/23/11 2:36 PM, Alexandre Abreu wrote: >> Hello Daniel. >> >> The module being used is 'mi_xmlrpc.so' > ok, this one creates a new process for handling xmlrpc requests. It is > pretty much clear that is very likely what I suspected first time. > > If you have time, try load instead xmlrpc module and use the command > 'mi dlg_terminate_dlg ...". > > Cheers, > Daniel > >> I am using the Carsten's rtpproxy >> patch. RTPPROXY detects the media timeout and send a notification >> through XMLRPC lib with 'dlg_terminate_dlg callid' to Kamailio. After >> that, I configured the event_route to catch the local generated >> requests for accounting these BYEs. >> >> Thanks, >> Alexandre >> >> -----Mensagem original----- >> De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: >> quarta-feira, 23 de março de 2011 10:17 >> Para: Alexandre Abreu >> Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >> Users Mailing List' >> Assunto: Re: RES: [SR-Users] event_route and acc_db_request(). >> >> Hello, >> >> On 3/23/11 1:44 PM, Alexandre Abreu wrote: >>> Hello Daniel. >>> >>> The BYE is generated by kamctl/xmlrpc (dlg_terminate_dlg). >> is xmlrpc via mi_xmlrpc or via xmlrpc module? >> >> I have to double check, but looks very likely to be the fact that acc >> db connection was not initialized for MI/RPC children processes. >> >> Thanks, >> Daniel >> >>> Alexandre >>> >>> De: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Enviada em: >>> quarta-feira, 23 de março de 2011 04:55 >>> Para: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >>> Users Mailing List >>> Cc: Alexandre Abreu >>> Assunto: Re: [SR-Users] event_route and acc_db_request(). >>> >>> Hello, >>> >>> On 3/17/11 5:45 PM, Alexandre Abreu wrote: >>> Hello. >>> >>> Why acc_db_request() doesnt work on event_route? >>> >>> I will take a look. >>> >>> Is the BYE generated by dialog timeout or you trigger it by > kamctl/xmlrpc? >>> Cheers, >>> Daniel >>> >>> >>> >>> Mar 17 13:15:44 devel kamailio[25209]: INFO:<script>: Routing >>> locally generated BYE to<sip:2000000@192.168.200.114:9297> >>> Mar 17 13:15:44 devel kamailio[25209]: ERROR:<core> [db.c:421]: >>> invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: >>> acc [acc.c:391]: error in use_table Mar 17 13:15:44 devel >>> kamailio[25209]: INFO:<script>: Routing locally generated BYE >>> to<sip:2000001@192.168.200.149:7335> >>> Mar 17 13:15:44 devel kamailio[25209]: ERROR:<core> [db.c:421]: >>> invalid parameter value Mar 17 13:15:44 devel kamailio[25209]: ERROR: >>> acc [acc.c:391]: error in use_table >>> >>> event_route[tm:local-request] { >>> >>> xlog("L_INFO", "Routing locally generated $rm >>> to<$ru>\n"); >>> >>> if (is_method("BYE")) >>> acc_db_request("rtp-timeout", acc); } >>> >>> If I change acc_db_request() to acc_log_request() everything works >>> fine, but this BYE should go to database for accounting purposes. >>> >>> I am using GIT version from Kamailio branch 3.1. >>> >>> From 2008 there is a thread that also demonstrate this problem: >>> >>> http://www.mail-archive.com/users@lists.kamailio.org/msg01411.html >>> >>> Unfortunately, in the archives, theres no solution for that. >>> >>> Regards, >>> Alexandre >>> >>> >>> _______________________________________________ >>> 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 > -- Daniel-Constantin Mierla http://www.asipto.com

4 3

Error when using dispatcher module
by Gary Chen 25 Mar '11

25 Mar '11

Kamailio 3.1.2 I am using Kamailio in front of Freeswitch as simple sip router. To do multi-tenant in Freeswitch I created SIP domain (fs2000.ly.net) and used as sip domain inside my sip phone. This domain does not map to any real IP and no entry in our DNS server. If I sent the call directly to Freeswitch, it works fine and registered with Freeswitch. When I tried to go through Kamailio using dispatcher to route the call to freeswitch, I got this error: ERROR: <core> [resolve.c:1540]: ERROR: sip_hostport2su: could not resolve hostname: "fs2000.ly.net" The strange thing is that sometime the call did go through kamailio and registered with freeswitch. Whenever I restart Kamailio, I got above error and then the error went away by itself. Sometime took a minute and sometime took several hours. And sometime the error come back without restart. Does anybody know why? Why dispatcher want to resolve the hostname when it only lookup dispatcher for destination IP? Gary

1 0

kamailio 3.1: rtpproxy_sock multiple rtpproxies not working?
by Min Wang 24 Mar '11

24 Mar '11

hi I have two questions regarding kamailio 3.1 (1) It seems the following format for rtpproxy_sock not working in Kamailio 3.1 modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:12221 udp:localhost:12222") the error is: 0(11881) ERROR: rtpproxy [rtpproxy.c:957]: Name or service not known ////////////////////////// 0(11881) DEBUG: <core> [sr_module.c:871]: DEBUG: init_mod: rtpproxy 0(11881) DEBUG: rtpproxy [rtpproxy.c:531]: url is udp:locahost:22222, len is 18 0(11881) DEBUG: rtpproxy [rtpproxy.c:531]: url is udp:localhost:22222, len is 19 0(11881) DEBUG: <core> [sr_module.c:871]: DEBUG: init_mod: nathelper .... 0(11881) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (-127): rtpproxy 0(11881) ERROR: rtpproxy [rtpproxy.c:957]: Name or service not known 0(11881) ERROR: <core> [sr_module.c:832]: init_mod_child(): Error while initializing module rtpproxy (/usr/lib/kamailio/modules_k/rtpproxy.so) But if you do the following it is ok modparam("rtpproxy", "rtpproxy_sock","udp:localhost:12221") modparam("rtpproxy", "rtpproxy_sock","udp:localhost:12222") any clue or format changed for rtpproxy_sock? (2) BTW, how do I log stderror into syslog file? -- log_stderror=yes the error will print out in the console, #configure the /etc/syslog.conf for this feature log_facility=LOG_LOCAL1 this log_facility does not log the log_stderror?? Thanks. Kind regards / Mit freundlichen Grüßen Min Wang

2 2

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users March 2011