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
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.
>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/
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
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
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
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
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
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
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
