sr-users February 2006

sr-users@lists.kamailio.org

189 participants
373 discussions

[Serusers] UAC UDP to Proxy TCP... Problem

by Christian Thomas

Hi everybody, I have a UDP2TCP problem with Ser. (0.9-4) The UACs connected to my SER Proxy are all UDP. When I use some carriers to connect them to PSTN The Carrier Proxy / GW could talk UDP or TCP. It depends on the destination. Each time the Carrier GW want to talk TCP, the contact field is correct and contains the 'transport=tcp' mention. all seems to be correct and, after a complete reading about this subject in the list, I trust that using t_relay() must do the right translation and send response via TCP to the Carrier GW when this one is transport=tcp declared. If I Check the message for an Ack or a BYE sent to the TCP GW the uri is correct : the transport=tcp is added. Request-Line: ACK sip:50033299848400@200.1xx.xx.xx:5060;transport=tcp SIP/2.0 I have red that this is sufficient to let SER understand that it must be sent via TCP. unfortunately, this message is ent thru UDP. May I force with a t_relay_to_tcp ? As this case depends on the carrier dynamic routing it could be complicated because of the need to know the destination to script t_relay_to_tco(uri, port)... If anybody has the trick or any advice... Other thing related, when TCP is the transport mode from the Carrier GW and I forward staefully to the UAC (Asterisk) the call failed between Asterisk as UAC and the carrier GW. I wondering it was because the Carrier Gw didn't receive an ACK TCP from my server.. Well I'm completely lost... as you can feel with my message... I need Help.. But don't cal me Harry ;) Regards, Christian Thomas

18 years, 9 months

Re: Re: Re: Re: [Serusers] a question about "cancel" in forwardingscenario

by zhangshuai

Dear Greger V. Teigre, Thanks for your suggestion. I've reset the fr_inv_timer and debug level, and put some log functions into ser.cfg: # ----------- global configuration parameters ------------------------ debug=7 # debug level (cmd line: -dddddddddd) fork=no log_stderror=yes # (cmd line: -E) listen=218.97.252.39 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 alias=localhost.localdomain alias=218.97.252.39 # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" # ----------------- setting module-specific parameters --------------- # -- tm params -- # set time for which ser will be waiting for a final response; # fr_inv_timer sets value for INVITE transactions, fr_timer # for all others modparam("tm", "fr_inv_timer", 120 ) modparam("tm", "fr_timer", 10 ) # ------------------------- request routing logic ------------------- # main routing logic route{ # for testing purposes, simply okay all REGISTERs if (method=="REGISTER") { log("REGISTER\n"); sl_send_reply("200", "ok"); break; }; seturi("sip:200@218.97.252.35:5060"); # if we do not get a positive reply, continue at reply_route[1] log("for test\n"); t_on_failure("1"); # forward the request to all destinations in destination set now t_relay(); } failure_route[1] { #when caller cancel, terminate the call if (t_check_status("487")) { log("cancel received\n"); t_reply("487", "Request Terminated"); break; }; # forwarding failed -- try again at another destination append_branch("sip:300@218.97.252.44:5060"); log(1,"first redirection\n"); # if this alternative destination fails too, proceed to reply_route[2] #t_on_failure("2"); t_relay(); } Here is my test: When ua1(sip:100@localhost.localdomain:5060) call <sip:400@localhost.localdomain:5060>, SER, at once, rewrites uri and sends invite to ua2(sip:200@218.97.252.35:5060). But because ua2 is offline, SER forwards the invite to ua3(sip:300@218.97.252.44:5060) and then ua3 begins ringing. Now, ua1 sends cancel to SER, SER sends cancel to ua3. ua3 returns "487" to SER and SER sends "408" to ua1. I don't know whether the timers were reset properly before forwarding. And with the attachment is the ser debug info. Please have a look. Thanks again. >I think you need to make an ngrep SIP trace of the two scenarios. SER will >not generate a 408 unless the timer hits. Increase the timer (it will be >easier to see what happens). You use a very low timer value >(fr_inv_timer=15). Set it to 120. Then look for the CANCEL from ua3. Does >SER receive the CANCEL and process it (use debug mode 7)? >I'm not sure if this is the same as mentioned in the bug referred to in >another reply, but let's try to find out. >Please post the ngrep trace for the two scenarios. >g-) > >----- Original Message ----- >From: "zhangshuai" <zhangshuai(a)goldentek.biz> >To: "serusers" <serusers(a)lists.iptel.org> >Cc: "wuyuan" <wuyuan(a)goldentek.biz> >Sent: Tuesday, February 14, 2006 9:41 AM >Subject: Re: Re: Re: [Serusers] a question about "cancel" in >forwardingscenario > > >> Dear Greger V. Teigre, >> >> >> I've tried t_on_failure("2"). >> >> failure_route[2] { >> #when caller cancel, terminate the call >> if (t_check_status("487")) { >> log(1,"cancel received\n"); >> t_reply("487", "Request Terminated"); >> break; >> } >> } >> >> There are similar lines in failure_route[1]. When ua2 is ringing and ua1 >> cancel the call, the value of "t_check_status("487")" in failure_route[1] >> will be true. However, When ua3 is ringing and ua1 cancel the call, the >> value of "t_check_status("487")" in failure_route[2] will be false. This >> time, t_check_status() returns "408". I don't know why SER generates "408" >> under this circumstance. My ser's version is 0.9.3 and I just run >> update_from_cvs. And I found similar description here: >> http://bugs.sip-router.org/browse/SER-63 >> Is it an unsolved problem? >> >> >>>Do some logging, what happens in the failure route? To me, it looks like >>>your config appends a branch. BTW, run update_from_cvs in your SER source >>>dir top make sure you get the latest bug fixes! >>>g-) >>> >>>----- Original Message ----- >>>From: "zhangshuai" <zhangshuai(a)goldentek.biz> >>>To: "serusers" <serusers(a)lists.iptel.org> >>>Cc: "wuyuan" <wuyuan(a)goldentek.biz> >>>Sent: Tuesday, February 14, 2006 3:49 AM >>>Subject: Re: Re: [Serusers] a question about "cancel" in forwarding >>>scenario >>> >>> >>>> Dear Greger V. Teigre, >>>> >>>> >>>> >>>> Thanks for your quick reply. >>>> >>>> I have read the sergettingstarted05.pdf (Based upon SER version 0.9.3) >>>> and >>>> tested the onr.cfg in >>>> ser-0.9.3.GettingStarted.1.3.tar.gz/ser-0.9.3/examples many times. SER >>>> sent out "408" to caller immediately after received "486" from ua3. I >>>> don't know how does ser's failure route deal with this kind of "cancel" >>>> when the invite has been forwarded. Any ideas will help me a lot. >>>> Thanks! >>>> >>>> Here is the onr.cfg: >>>> >>>> # ------------------ module loading ---------------------------------- >>>> loadmodule "/usr/local/lib/ser/modules/sl.so" >>>> loadmodule "/usr/local/lib/ser/modules/tm.so" >>>> # ----------------- setting module-specific parameters --------------- >>>> >>>> # -- tm params -- >>>> # set time for which ser will be waiting for a final response; >>>> # fr_inv_timer sets value for INVITE transactions, fr_timer >>>> # for all others >>>> modparam("tm", "fr_inv_timer", 15 ) >>>> modparam("tm", "fr_timer", 10 ) >>>> >>>> # ------------------------- request routing logic ------------------- >>>> >>>> # main routing logic >>>> >>>> route{ >>>> # for testing purposes, simply okay all REGISTERs >>>> if (method=="REGISTER") { >>>> log("REGISTER"); >>>> sl_send_reply("200", "ok"); >>>> break; >>>> }; >>>> # try these two destinations first in parallel; the second >>>> # destination is targeted to sink port -- that will make ser >>>> # wait until timer hits >>>> seturi("sip:200@218.97.252.35:5060"); >>>> #append_branch("sip:300@218.97.252.36:5060"); >>>> # if we do not get a positive reply, continue at reply_route[1] >>>> t_on_failure("1"); >>>> # forward the request to all destinations in destination set now >>>> t_relay(); >>>> } >>>> >>>> failure_route[1] { >>>> #when caller cancel, terminate the call >>>> if (t_check_status("487")) { >>>> t_reply("487", "Request Terminated"); >>>> break; >>>> }; >>>> # forwarding failed -- try again at another destination >>>> append_branch("sip:300@218.97.252.44:5060"); >>>> log(1,"first redirection\n"); >>>> # if this alternative destination fails too, proceed to >>>> reply_route[2] >>>> #t_on_failure("2"); >>>> t_relay(); >>>> } >>>> >>>> >>>> Thanks in advance. >>>> >>>> Have a good day! >>>> >>>> >>>> >>>> Shuai >>>> >>>> >>>>>The internal SER timer hits and the request times out (the request is >>>>>not >>>>>terminated). >>>>>See SER-GettingStarted doc at ONsip.org for a full example of call >>>>>features >>>>>like forwarding. >>>>>g-) >>>>>----- Original Message ----- >>>>>From: "zhangshuai" <zhangshuai(a)goldentek.biz> >>>>>To: "serusers" <serusers(a)lists.iptel.org> >>>>>Cc: "wuyuan" <wuyuan(a)goldentek.biz> >>>>>Sent: Friday, February 10, 2006 11:18 AM >>>>>Subject: [Serusers] a question about "cancel" in forwarding scenario >>>>> >>>>> >>>>>> Dear All, >>>>>> >>>>>> >>>>>> I want to make use of avpops module to achieve forward on-no-reply. >>>>>> When >>>>>> ua1 calls ua2 and ua2 is off-line, or busy, or doesn't answer the >>>>>> phone, >>>>>> the invite should be forwarded to ua3 and ua3 begins ringing. >>>>>> >>>>>> In my tests, first, ua1 sends "cancel" when ua2 is ringing. Ua1 >>>>>> receives >>>>>> "487 Request Terminated" from SER. Second, ua1 sends "cancel" when ua3 >>>>>> is >>>>>> ringing. So, theoretically, ua1 should receive "487 Request >>>>>> Terminated" >>>>>> after "200 canceling" from SER, right? But, ua1 received "408 Request >>>>>> Timeout" instead. So strange. How come? >>>>>> >>>>>> I think something is wrong with my ser.cfg. Could anyone help me about >>>>>> this? Thanks in advance. >>>>>> >>>>>> Here is my ser.cfg: >>>>>> >>>>>> # ------------------ module loading ---------------------------------- >>>>>> >>>>>> loadmodule "/usr/local/lib/ser/modules/sl.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/tm.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/rr.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/maxfwd.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/usrloc.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/registrar.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/textops.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/avp.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/acc.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/mysql.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/dbtext.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/avpops.so" >>>>>> #loadmodule "/usr/local/lib/ser/modules/postgres.so" >>>>>> #loadmodule "/usr/local/lib/ser/modules/flatstore.so" >>>>>> >>>>>> # Uncomment this if you want digest authentication >>>>>> # mysql.so must be loaded ! >>>>>> loadmodule "/usr/local/lib/ser/modules/auth.so" >>>>>> #loadmodule "/usr/local/lib/ser/modules/auth_db.so" >>>>>> >>>>>> loadmodule "/usr/local/lib/ser/modules/auth_radius.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/group_radius.so" >>>>>> loadmodule "/usr/local/lib/ser/modules/uri_radius.so" >>>>>> # ----------------- setting module-specific parameters --------------- >>>>>> >>>>>> # -- usrloc params -- >>>>>> >>>>>> #modparam("usrloc", "db_mode", 0) >>>>>> >>>>>> # Uncomment this if you want to use SQL database >>>>>> # for persistent storage and comment the previous line >>>>>> modparam("usrloc", "db_mode", 1) >>>>>> >>>>>> # -- auth params -- >>>>>> # Uncomment if you are using auth module >>>>>> # >>>>>> #modparam("auth_db", "calculate_ha1", yes) >>>>>> # >>>>>> # If you set "calculate_ha1" parameter to yes (which true in this >>>>>> config), >>>>>> # uncomment also the following parameter) >>>>>> # >>>>>> #modparam("auth_db", "password_column", "password") >>>>>> >>>>>> # -- rr params -- >>>>>> # add value to ;lr param to make some broken UAs happy >>>>>> >>>>>> modparam("rr", "enable_full_lr", 1) >>>>>> modparam("tm", "fr_timer", 10 ) >>>>>> modparam("tm", "fr_inv_timer", 20) >>>>>> modparam("tm", "noisy_ctimer", 1) >>>>>> >>>>>> modparam("auth_radius|uri_radius|group_radius", "radius_config", >>>>>> "/usr/local/etc/radiusclient-ng/radiusclient.conf") >>>>>> >>>>>> modparam("avpops","avp_url","mysql://ser:heslo@localhost/ser") >>>>>> modparam("avpops","avp_table","usr_preferences") >>>>>> # ------------------------- request routing logic ------------------- >>>>>> >>>>>> # main routing logic >>>>>> >>>>>> route{ >>>>>> # initial sanity checks -- messages with >>>>>> # max_forwards==0, or excessively long requests >>>>>> if (!mf_process_maxfwd_header("10")) { >>>>>> sl_send_reply("483","Too Many Hops"); >>>>>> break; >>>>>> }; >>>>>> if (msg:len >= 2048 ) { >>>>>> sl_send_reply("513", "Message too big"); >>>>>> break; >>>>>> }; >>>>>> >>>>>> if (!method=="REGISTER") record_route(); >>>>>> >>>>>> if (loose_route()) { >>>>>> t_relay(); >>>>>> break; >>>>>> }; >>>>>> >>>>>> if (method=="INVITE") { >>>>>> lookup("location"); >>>>>> #if (!lookup("location")) { >>>>>> # sl_send_reply("404", "Not Found"); >>>>>> # break; >>>>>> #}; >>>>>> } >>>>>> >>>>>> if (method=="REGISTER") { >>>>>> log("REGISTER\n"); >>>>>> if (!radius_www_authorize("localhost.localdomain")) { >>>>>> www_challenge("localhost.localdomain", "0"); >>>>>> break; >>>>>> }; >>>>>> save("location"); >>>>>> break; >>>>>> }; >>>>>> >>>>>> if (method=="INVITE") { >>>>>> if (!radius_proxy_authorize("localhost.localdomain")) { >>>>>> proxy_challenge("localhost.localdomain", "1"); >>>>>> break; >>>>>> }; >>>>>> } >>>>>> >>>>>> # if we do not get a positive reply, continue at failure_route[1] >>>>>> t_on_failure("1"); >>>>>> # forward the request to all destinations in destination set now >>>>>> t_relay(); >>>>>> >>>>>> #if (!t_relay()) { >>>>>> # sl_reply_error(); >>>>>> #}; >>>>>> } >>>>>> >>>>>> failure_route[1] { >>>>>> >>>>>> #when caller cancel, terminate the call >>>>>> if (t_check_status("487")) { >>>>>> t_reply("487", "Request Terminated"); >>>>>> break; >>>>>> }; >>>>>> >>>>>> if ( ( avp_db_load("$ruri","s:redirect_on_failure") && >>>>>> avp_check("redirect_on_failure","eq/i:1"))) { >>>>>> # User need to forward >>>>>> log(1, "User wants redirection.\n"); >>>>>> if ( ( avp_db_load("$ruri","s:redirectnumber") && >>>>>> !avp_check("redirectnumber","re/^$"))) { >>>>>> log(1,"first redirect\n"); >>>>>> #avp_print(); >>>>>> attr2uri("redirect number"); >>>>>> lookup("location"); >>>>>> append_branch(); >>>>>> #t_on_failure("2"); >>>>>> t_relay(); >>>>>> } >>>>>> else { >>>>>> t_reply("408", "TimeOut"); >>>>>> break; >>>>>> }; >>>>>> } >>>>>> else { >>>>>> t_reply("404", "Not Found"); >>>>>> break; >>>>>> }; >>>>>> } >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Serusers mailing list >>>>>> serusers(a)lists.iptel.org >>>>>> http://lists.iptel.org/mailman/listinfo/serusers >>>>>> >>>>> >>>>> >>>> >>>> = = = = = = = = = = = = = = = = = = = = >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Serusers mailing list >>>> serusers(a)lists.iptel.org >>>> http://lists.iptel.org/mailman/listinfo/serusers >>>> >>> >>> >> >> = = = = = = = = = = = = = = = = = = = = >> >> >> >> >> >> _______________________________________________ >> Serusers mailing list >> serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> > > = = = = = = = = = = = = = = = = = = = =

18 years, 9 months

[Serusers] SER authentication through FreeRadius with an LDAP backend

by Jon Steer

Requirement Authenticating SIP Clients through a SIP proxy via RADIUS with an LDAP Backend using digest mode. The path is SIP client X -> Ser SIP Proxy -> FreeRadius -> Fedora Directory Server Issue Cannot authenticate a SIP client using Freeradius digest mode and LDAP. After reading through a number of the newslists of all of the projects being used, There is contradictory information about whether this is possible. One solution described in the FreeRadius mailing list says that the it should be possible by setting up radiusd.conf correctly to return the password field from the LDAP server and then having the digest module decode it. Another thread in freeradius says that it isn't possible to store the passwords the LDAP server encrypted. That the LDAP server needs to return cleartext passwords over a TLS connection. Several threads in the SER say that it is possible, but the examples given don't include LDAP in the equation so it is hard to tell. I have read the Radius Howto on the SER page and the LDAP howto in the freeradius documentation and neither of them authoritatively answer the question. Environment OS: Fedora 4 Radius Server : FreeRadius 1.0.4 Radius Client : radiusclient-ng 5.2 SIP Proxy : SER 0.9.4 Directory Server: Fedora Directory Server 1.0.1 Directory Server schema: inetOrgPerson Directory Server password encoding: SHA SIP Client : Client X Network setup ServerA hosts SER, FreeRadius ServerB hosts Directory Server Both servers are on the same subnet. thanks, jon -- "Whereever you go, there you are"

18 years, 9 months

[Users] Requests resent by proxy?

by Walter Schober

Hello! Using OpenSER 1.0.0 in my path I encounter it rather often, that (exactly the same) requests (no append_branch()) are resent by the proxy (!) after 2 to 40 ms. Any idea what triggers that? /walter

18 years, 9 months

[Serusers] Error 481 and CANCEL

by Benito Caracuel

Hello all, I am trying to cancel an INVITE but I can't. UAC ----------------- SER ----------------- UAS INVITE ------> CANCEL -----> <---------481 When UAS receive the CANCEL, it sends a "481 Call/Transaction does not exist". UAS must send 200 ok and 487 instead of 481. How can I solve this problem? Help me please. Thank you.

18 years, 9 months

[Users] install TLS package

by Tóth Péter

Helo! I'm very new on the list, and I have a basic problem. After installing openser deb packages (1.0.0 tls version), i got the following error at the start: #/etc/init.d/openser start Starting openser: openserbad user name/uid number: -u openser # When I installed the 1.0.0 simple package, a user started up automatically with name "openser", but at the tls install there is no user entry in /etc/passwd file. I meant this is the error, but I don't know exactly. What should I do? Please help me! An other question: what is the default mysql password? Thanks: Tóth Péter

18 years, 9 months

[Users] fifo get_statistics

by Helge Waastad

Hi, not really a critical observation this time, but it seems I can only run openserctl fifo get_statistics one time. The next time it's hanging...after a ctrl-c, I can run it successfully again. (running get_statistics on a module, ex openserctl fifo get_statistics tm:, works fine) br hw -- Helge Waastad Senior Konsulent Systemavdelingen Smartnet

18 years, 9 months

[Serusers] avpops prefix adding for areacode

by Ibrahim TUNALI

Hi, If user call 7 digits number, I want to add caller prefix from avpops record to TO uri. I know prefix() function uses for adding prefix but it doesn't work with avpops module. I couldn't use avp_write() function because it's only work with avp_values or avp_alias. I want to mix of avp_alias and TO uri. ie sip:2304862@domain.com -> sip:9252304862@domain.com like traditional PSTN dialing (you don't dial your areacode if you want to call your area) My configuration part for avpops prefix is; if(uri=~"^sip:[0-9]{7}@" && avp_db_load("$from","$areacode")){ #this part should be get from avp_alias prefix("$areacode"); # or avp_write("$to","$areacode$to"); } regards ibrahim

18 years, 9 months

[Users] nathelper natping OPTIONS packets formated to not get reply?

by Glenn Dalgliesh

I was looking at packet traces of the OPTIONS packets generated by natping and it appears that at least in my implementation of OpenSer 1.0.0 the "To: sip" line has no username which causes many UA's require in order to respond to the OPTIONS packet. I was wondering if this was intentional or if it would be possible to change this behavior or at least make it an configurable option. I think a lot could be done/determined based on the results of the reply; including determining if the packet is really reaching the UA. I realize that some UA's may not support this feature but I think more do than not. Just my observations/thoughts. Please give me reasons for this being a good or bad idea.. Current Packet: U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060 OPTIONS sip:111.16.187.102:5060 SIP/2.0. Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0. From: sip:ping@intervoz.com.br;tag=ec30e9b7. To: sip:111.16.187.102:5060. Call-ID: b3fdcfa3-71a82db5-445151(a)111.15.13.67. CSeq: 1 OPTIONS. Content-Length: 0. Suggested Packet: U 2006/01/20 16:27:10.410848 111.15.13.67:5060 -> 111.16.187.102:5060 OPTIONS sip:<username from location table>@111.16.187.102:5060 SIP/2.0. Via: SIP/2.0/UDP 111.15.13.67:5060;branch=0. From: sip:ping@intervoz.com.br;tag=ec30e9b7. To: sip:111.16.187.102:5060. Call-ID: b3fdcfa3-71a82db5-445151(a)111.15.13.67. CSeq: 1 OPTIONS. Content-Length: 0.

18 years, 9 months

[Users] Caller ID

by Martin Kjeldsen

Hi I'm having a problem with users whose Caller-ID I would like to hide. I'm aware that the FROM header has to carry the value anonymous(a)anonymous.invalid, for a user to be shown as anonymous in the callees display. But I'm not sure how to accomplish this without violating core rules, concerning the FROM headerss tag! My accounting is done using the FROM header aswell, but I can imagine that I could just place the flag prior to altering the FROM header, if that is the way to go about this problem. I have just installed the OpenSER 1.0.0. I was wondering if the right way to achieve my goal, would be via the UAC module? All help appreciated, and thanks for a great community :-) Kind regards Martin Kjeldsen

18 years, 9 months

← Newer
1
...
16
17
18
19
20
21
22
...
38
Older →

Jump to page:

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 February 2006