sr-users October 2007

sr-users@lists.kamailio.org

130 participants
285 discussions

[OpenSER-Users] using sipsak to check openser

by Papadopoulos Georgios

Hello all, In order to check that our Openser is running properly I use sipsak periodically. The command is : sipsak -v -N -U -I -s sip:sipsak@213.5.xxx.xxx:5060 -a xxxxxxx This works fine 99% of the time, however sometimes I get the following from sipsak : warning: ignoring -i option when in usrloc mode received: SIP/2.0 400 Bad Request Via: SIP/2.0/UDP 127.0.0.1:54393;branch=z9hG4bK.4d383307;rport=54393;alias;received=213.5 .43.131 From: sip:sipsak@213.5.43.131:5060;tag=44d4f5ef To: sip:sipsak@213.5.43.131:5060;tag=97e44c910458bd56beb40ca4028d7cc8.91db Call-ID: 1154807279(a)127.0.0.1 CSeq: 2 REGISTER P-Registrar-Error: Invalid CSeq number Server: Altec Telecoms SIP Proxy Content-Length: 0 error: didn't received '200 OK' on register (see above). aborting SIP failure sipsak is running on the same server with Openser. Since the CSeq is 2 it means that Openser has received the first REGISTER, has asked for authentication, sipsak replied, but then Openser says "Invalid CSeq number". Has anyone seen this happen before and/or has a reasonable explanation? thank you George Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

17 years, 1 month

[OpenSER-Users] Reply vs. failure events.

by Alex Balashov

If I am not using a failure_route to catch failed responses to transactional events, but have an onreply_route, does that guarantee that *all* failures will be caught by the onreply_route without being diverted and muffled somewhere? Based on the behaviour I am witnessing, it seems that is correct, but I wanted to verify. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : +1-678-954-0670 Direct : +1-678-954-0671

17 years, 1 month

[OpenSER-Users] How to visualice a flag in easy way?

by Iñaki Baz Castillo

Hi, for now, the only way to test flags is by $bf (not useful if there are enabled some bflags) or doing something as: if (isbflagset(6)) { $var(bflag6) = 1; } xlog("L_INFO","--- $var(bflag6) ----\n"); As a suggestion, couldn't be a way to access to the value of a flag like: xlog("L_INFO","--- $bf[6] ----\n"); This could be useful to when matching flgas with table fields and so. Regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

[OpenSER-Users] About efficiency in conditionals

by Iñaki Baz Castillo

Hi, I'm wondering which solution (A or B) is more efficient in case method is NOT an INVITE: A) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) ) B) if ( mehtod=="INVITE" ) My question is: Is faster B because does less comparasions? or does OpenSer break A conditional during first condition (method=="INVITE") because it's false so then A and B are equally efficient? And which is more efficient (C or D) when all the conditions are true? C) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) ) { .... D) if ( method=="INVITE" ) { if ( (isflagset(5) || isbflagset(6)) ) { ... Thanks for any explanation. Best regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

[OpenSER-Users] 500 Server error occurred (1/SL)

by Cseke Tamas

Hello, I get a similar problem like this: http://www.openser.org/pipermail/devel/2007-February/005984.html I get the following error log, and packets: http://pastebin.com/f112f652a <http://pastebin.com/f112f652a> Thanks any help, Tamas

17 years, 1 month

[OpenSER-Users] Multidomain and in-dialog REFER auth issue

by Iñaki Baz Castillo

Hi, I've a multidomain OpenSer and I want to allow REFER (with authenticacion before) just in calls between users of same domain, but it's quite complex: - userA(a)domainA.com INVITE's userB(a)domainB.com. - During the call userA(a)domainA.com does an in-dialog REFER. Because the REFER is in-dialog the message is like: -------------------- REFER sip:userB@80.98.123.23:5060 SIP/2.0 From: sip:userA@domainA.com To: userB(a)domainB.com Refer-To: ... ... -------------------- How can my OpenSer know which domain this REFER goes? of course the "To" header is not valid at all. Could be a solution a SQL query to "location" table looking for the URI (sip:userB@80.98.123.23:5060) and getting the username and domain of this? Any other option? Thanks a lot. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

[OpenSER-Users] Do AVP's really exist in entire transaction?

by Iñaki Baz Castillo

Hi, in order to not apply RtpPrxy if the called is an Asterisk (that supports "comedia") I load "usr_preferences" table looking for "pbx_comedia" attribute for called domain. If it's, then it's created a avp: avp(s:pbx_comedia)="yes". But when I try to test this AVP in the "on_reply_route" (to not apply RtpProxy) this AVP has null value. In fact it's easy to see: ------------------------------------------------------ route[3] { ; INVITE route $avp(s:test)="hello"; ... route(1); } onreply_route[1] { xlog("L_INFO","----- avp(s:test) = $avp(s:test) ------\n"); } ------------------------------------------------------ The xlog of onreply_route shows: ----- avp(s_test) = null ----- is it normal? aren't AVP's transaction aware? Thanks. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years, 1 month

Re: [Serusers] SER + Linksys SPA942 + Call transfer

by roayu

Hi there! I'm using ser0.9.6 to do the call transfer, which part of the configuration that I need to configure in ser.cfg? Do I need to create a new route? Thanks. Cheers, Roa Yu :) -----Original Message----- From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of roayu Sent: Friday, October 12, 2007 2:45 PM To: kgfleischmann(a)t-online.de Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] SER + Linksys SPA942 + Call transfer Hi Klaus! The UA does not received the REFER sent by SPA942. What should I need to configure to ensure that the UA receive the REFER from the transfer agent(SPA942)? Thanks. Cheers, Roa Yu -----Original Message----- From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of kgfleischmann(a)t-online.de Sent: Friday, October 12, 2007 2:22 PM To: serusers(a)lists.iptel.org Subject: Re: [Serusers] SER + Linksys SPA942 + Call transfer The NOTIFY is always sent from the UA, which received the REFER. SER only relays it. Did you check this? Cheers Klaus roayu wrote: > Hi there! > > After SPA942(transfer agent) sent REFER to SER, SER does not send a NOTIFY > to SPA942(transfer agent). What's causes this? Can anyone tell me. > > Thanks. > > Cheers, > Roa Yu :) > > -----Original Message----- > From: serusers-bounces(a)lists.iptel.org > [mailto:serusers-bounces@lists.iptel.org] On Behalf Of roayu > Sent: Thursday, October 11, 2007 4:34 PM > To: Atle Samuelsen > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] SER + Linksys SPA942 + Call transfer > > > Hi Atle, > > Let me make my scenario clear on you. > > I have 2 softphone and 1 IP phone(SPA942). I would like to call from > Softphone A to SPA942, then use SPA942 transfer the call to Softphone B. > But, when I do so, the connection still remained on between SPA942 and > Softphone B. > > I managed to get Softphone A onHold and the SPA942 managed to call to > Softphone B. Once I press on the 'xfer' button after calling Softphone B, A > still onHold and no SIP signal to unHold A and to terminate B. > > If I would like to configure the ser.cfg file, which part that I need to > configure? And how do I do that? > > Thanks. > > Cheers, > Roa Yu > > > -----Original Message----- > From: Atle Samuelsen [mailto:clona@cyberhouse.no] > Sent: Thursday, October 11, 2007 3:19 PM > To: roayu > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] SER + Linksys SPA942 + Call transfer > > > Hi Roa,i > * roayu <roayu(a)ctisys.net> [071011 04:01]: >> Hi, there! >> >> I have some questions and help. >> 1) I would like to know can call transfer being done when the >> connection is P2P? When I tried to use relay (mediaproxy) to do the call >> transfer, it's able to transfer the call to the other party whereas when > the >> condition is P2P, it just can't pass the correct signal. > > I'm proberbly only tierd (9:15 am here) but P2P? Can you provide the > signalling and ser.cfg so we can understand what you are trying to > establish? > > I personally think you are trying to do a call transfer from one ua to a > other, where the original call went true mediaproxy, but you do not want > the "new" transferd call to go true it. > >> 2) Can SER support SPA942 ? Or is there some other settings that I need >> to configure on SER ? > > SPA942, SPA962, SPA2102, yea.. all Linksys SPA products work like a > charm with SER (Who has a 942 as his primary phone these days) > > > Best Regards > > ATle >> Thanks. >> >> Cheers, >> Roa Yu >> >> _______________________________________________ >> 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 > > _______________________________________________ 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

17 years, 1 month

Re: [OpenSER-Users] Insert in location table very slow

by Ovidiu Sas

That's normal. Set the db_mode to 1 if you want instant updates: http://www.openser.org/docs/modules/1.3.x/usrloc.html#AEN285 Regards, Ovidiu Sas On 10/15/07, Gregorio <goyo.villalba(a)dialcom.com> wrote: > Hi, > > Up to 60 seconds in mode 2: 'modparam("usrloc", "db_mode", 2)' > > Gregorio. > > -----Mensaje original----- > De: Alex Balashov [mailto:abalashov@evaristesys.com] > Enviado el: lunes, 15 de octubre de 2007 18:48 > Para: Gregorio > CC: users(a)openser.org > Asunto: Re: [OpenSER-Users] Insert in location table very slow > > > Gregorio, > > How long does it take? > > -- Alex > > On Mon, 15 Oct 2007, Gregorio wrote: > > > Hi all. > > > > > > > > I am using openSer 1.3 with mySQL. My problem is that although > registration > > is fast in SIP protocol terms, the contact binding is written in the > > 'location' table long time after this contact has received a 200 OK to his > > registration. So a user could think that he is registered before he is in > > the data base. > > > > > > > > Could it be a configuration issue? > > > > Can I solve this? > > > > > > > > Thanks! > > > > > > > > This is my config: > > > > > > > > > > > > # ----------- global configuration parameters ------------------------ > > > > > > > > debug=2 # debug level (cmd line: -dddddddddd) > > > > log_facility=LOG_LOCAL7 > > > > fork=yes > > > > log_stderror=no children=4 > > > > port=5060 > > > > > > > > listen=udp:192.168.1.206:5060 > > > > listen=tcp:192.168.1.206:5060 > > > > > > > > # ------------------ module loading ---------------------------------- > > > > > > > > #set module path > > > > mpath="/usr/local/lib/openser/modules/" > > > > > > > > loadmodule "mysql.so" > > > > loadmodule "xlog.so" > > > > loadmodule "sl.so" > > > > loadmodule "tm.so" > > > > loadmodule "rr.so" > > > > loadmodule "maxfwd.so" > > > > loadmodule "usrloc.so" > > > > loadmodule "registrar.so" > > > > loadmodule "textops.so" > > > > loadmodule "auth.so" > > > > loadmodule "auth_db.so" > > > > > > > > loadmodule "presence.so" > > > > > > > > loadmodule "presence_xml.so" > > > > > > > > loadmodule "mi_fifo.so" > > > > > > > > loadmodule "mi_xmlrpc.so" > > > > > > > > # ----------------- setting module-specific parameters --------------- > > > > > > > > > > > > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") > > > > > > > > # -- usrloc params -- > > > > > > > > modparam("usrloc", "db_mode", 2) > > > > > > > > # -- auth params -- > > > > modparam("auth_db", "calculate_ha1", yes) > > > > 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) > > > > > > > > > > > > #Agnadido para la Presencia > > > > modparam("presence|usrloc|pua", > > "db_url","mysql://openser:openserrw@127.0.0.1/openser") > > > > modparam("presence", "presentity_table", "presentity") > > > > modparam("presence", "active_watchers_table", "active_watchers") > > > > modparam("presence", "watchers_table", "watchers") > > > > modparam("presence", "clean_period", 100) > > > > modparam("presence", "max_expires", 3600) > > > > modparam("presence", "server_address", "sip:192.168.1.206:5060" ) > > > > > > > > #Presence_XML > > > > modparam("presence_xml", > > "db_url","mysql://openser:openserrw@127.0.0.1/openser") > > > > modparam("presence_xml", "xcap_table", "xcap") > > > > modparam("presence_xml", "force_active", 1) > > > > modparam("presence_xml", "integrated_xcap_server", 1) > > > > modparam("presence_xml", "pidf_manipulation", 1) > > > > modparam("presence_xml", "pidf_manipulation", 1) > > > > > > > > #Mi FIFO > > > > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") > > > > modparam("mi_fifo", "fifo_mode", 0600) > > > > modparam("mi_fifo", "fifo_group", 0) > > > > modparam("mi_fifo", "fifo_group", "root") > > > > modparam("mi_fifo", "fifo_user", 0) > > > > modparam("mi_fifo", "fifo_user", "root") > > > > modparam("mi_fifo", "reply_dir", "/home/openser/tmp/") > > > > > > > > #Mi XMLRPC > > > > modparam("mi_xmlrpc", "port", 8080) > > > > modparam("mi_xmlrpc", "log_file", "/var/log/openser-xmlrpc.log") > > > > modparam("mi_xmlrpc", "reply_option", 0) > > > > modparam("mi_xmlrpc", "buffer_size", 8192) > > > > > > > > > > > > # ------------------------- 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. Route filter"); > > > > exit; > > > > } > > > > > > > > if (msg:len >= max_len ) { > > > > sl_send_reply("513", "Message too big. Route filter"); > > > > exit; > > > > } > > > > > > > > if (!method=="REGISTER") > > > > record_route(); > > > > > > > > # subsequent messages withing a dialog should take the > > > > # path determined by record-routing > > > > if (loose_route()) { > > > > # mark routing logic in request > > > > append_hf("P-hint: rr-enforced\r\n"); > > > > route(1); > > > > }; > > > > if (uri==myself) { > > > > route(1); > > > > }; > > > > > > > > if (uri==myself) { > > > > # presence handling > > > > if( is_method("PUBLISH|SUBSCRIBE")){ > > > > route(2); > > > > }; > > > > > > > > if (is_present_hf("MyHeader")) > > > > { > > > > t_relay("192.168.1.111"); > > > > exit; > > > > }; > > > > > > > > > > > > if (method=="REGISTER") { > > > > # Uncomment this if you want to use digest > > authentication > > > > if (!www_authorize("openserDialcom", "subscriber")) > > { > > > > www_challenge("openserDialcom", "0"); > > > > exit; > > > > }; > > > > > > > > save("location"); > > > > exit; > > > > }; > > > > > > > > lookup("aliases"); > > > > if (!uri==myself) { > > > > append_hf("P-hint: outbound alias\r\n"); > > > > route(1); > > > > }; > > > > > > > > # native SIP destinations are handled using our USRLOC DB > > > > if (!lookup("location")) { > > > > sl_send_reply("404", "Not Found in openSer"); > > > > exit; > > > > }; > > > > append_hf("P-hint: usrloc applied\r\n"); > > > > }; > > > > > > > > route(1); > > > > } > > > > > > > > route[1] { > > > > # send it out now; use stateful forwarding as it works reliably > > > > # even for UDP2TCP > > > > if (!t_relay()) { > > > > sl_reply_error(); > > > > }; > > > > exit; > > > > } > > > > route[2] > > > > { > > > > # absorb retransmissions > > > > if (! t_newtran()) > > > > { > > > > sl_reply_error(); > > > > exit; > > > > }; > > > > > > > > if(is_method("PUBLISH")) > > > > { > > > > handle_publish(); > > > > t_release(); > > > > } else if( is_method("SUBSCRIBE")) { > > > > handle_subscribe(); > > > > t_release(); > > > > }; > > > > > > > > exit; > > > > } > > > > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : +1-678-954-0670 > Direct : +1-678-954-0671 > > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >

17 years, 1 month

Re: [OpenSER-Users] Insert in location table very slow

by Alex Balashov

Gregorio, How long does it take? -- Alex On Mon, 15 Oct 2007, Gregorio wrote: > Hi all. > > > > I am using openSer 1.3 with mySQL. My problem is that although registration > is fast in SIP protocol terms, the contact binding is written in the > 'location' table long time after this contact has received a 200 OK to his > registration. So a user could think that he is registered before he is in > the data base. > > > > Could it be a configuration issue? > > Can I solve this? > > > > Thanks! > > > > This is my config: > > > > > > # ----------- global configuration parameters ------------------------ > > > > debug=2 # debug level (cmd line: -dddddddddd) > > log_facility=LOG_LOCAL7 > > fork=yes > > log_stderror=no children=4 > > port=5060 > > > > listen=udp:192.168.1.206:5060 > > listen=tcp:192.168.1.206:5060 > > > > # ------------------ module loading ---------------------------------- > > > > #set module path > > mpath="/usr/local/lib/openser/modules/" > > > > loadmodule "mysql.so" > > loadmodule "xlog.so" > > loadmodule "sl.so" > > loadmodule "tm.so" > > loadmodule "rr.so" > > loadmodule "maxfwd.so" > > loadmodule "usrloc.so" > > loadmodule "registrar.so" > > loadmodule "textops.so" > > loadmodule "auth.so" > > loadmodule "auth_db.so" > > > > loadmodule "presence.so" > > > > loadmodule "presence_xml.so" > > > > loadmodule "mi_fifo.so" > > > > loadmodule "mi_xmlrpc.so" > > > > # ----------------- setting module-specific parameters --------------- > > > > > > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") > > > > # -- usrloc params -- > > > > modparam("usrloc", "db_mode", 2) > > > > # -- auth params -- > > modparam("auth_db", "calculate_ha1", yes) > > 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) > > > > > > #Agnadido para la Presencia > > modparam("presence|usrloc|pua", > "db_url","mysql://openser:openserrw@127.0.0.1/openser") > > modparam("presence", "presentity_table", "presentity") > > modparam("presence", "active_watchers_table", "active_watchers") > > modparam("presence", "watchers_table", "watchers") > > modparam("presence", "clean_period", 100) > > modparam("presence", "max_expires", 3600) > > modparam("presence", "server_address", "sip:192.168.1.206:5060" ) > > > > #Presence_XML > > modparam("presence_xml", > "db_url","mysql://openser:openserrw@127.0.0.1/openser") > > modparam("presence_xml", "xcap_table", "xcap") > > modparam("presence_xml", "force_active", 1) > > modparam("presence_xml", "integrated_xcap_server", 1) > > modparam("presence_xml", "pidf_manipulation", 1) > > modparam("presence_xml", "pidf_manipulation", 1) > > > > #Mi FIFO > > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") > > modparam("mi_fifo", "fifo_mode", 0600) > > modparam("mi_fifo", "fifo_group", 0) > > modparam("mi_fifo", "fifo_group", "root") > > modparam("mi_fifo", "fifo_user", 0) > > modparam("mi_fifo", "fifo_user", "root") > > modparam("mi_fifo", "reply_dir", "/home/openser/tmp/") > > > > #Mi XMLRPC > > modparam("mi_xmlrpc", "port", 8080) > > modparam("mi_xmlrpc", "log_file", "/var/log/openser-xmlrpc.log") > > modparam("mi_xmlrpc", "reply_option", 0) > > modparam("mi_xmlrpc", "buffer_size", 8192) > > > > > > # ------------------------- 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. Route filter"); > > exit; > > } > > > > if (msg:len >= max_len ) { > > sl_send_reply("513", "Message too big. Route filter"); > > exit; > > } > > > > if (!method=="REGISTER") > > record_route(); > > > > # subsequent messages withing a dialog should take the > > # path determined by record-routing > > if (loose_route()) { > > # mark routing logic in request > > append_hf("P-hint: rr-enforced\r\n"); > > route(1); > > }; > > if (uri==myself) { > > route(1); > > }; > > > > if (uri==myself) { > > # presence handling > > if( is_method("PUBLISH|SUBSCRIBE")){ > > route(2); > > }; > > > > if (is_present_hf("MyHeader")) > > { > > t_relay("192.168.1.111"); > > exit; > > }; > > > > > > if (method=="REGISTER") { > > # Uncomment this if you want to use digest > authentication > > if (!www_authorize("openserDialcom", "subscriber")) > { > > www_challenge("openserDialcom", "0"); > > exit; > > }; > > > > save("location"); > > exit; > > }; > > > > lookup("aliases"); > > if (!uri==myself) { > > append_hf("P-hint: outbound alias\r\n"); > > route(1); > > }; > > > > # native SIP destinations are handled using our USRLOC DB > > if (!lookup("location")) { > > sl_send_reply("404", "Not Found in openSer"); > > exit; > > }; > > append_hf("P-hint: usrloc applied\r\n"); > > }; > > > > route(1); > > } > > > > route[1] { > > # send it out now; use stateful forwarding as it works reliably > > # even for UDP2TCP > > if (!t_relay()) { > > sl_reply_error(); > > }; > > exit; > > } > > route[2] > > { > > # absorb retransmissions > > if (! t_newtran()) > > { > > sl_reply_error(); > > exit; > > }; > > > > if(is_method("PUBLISH")) > > { > > handle_publish(); > > t_release(); > > } else if( is_method("SUBSCRIBE")) { > > handle_subscribe(); > > t_release(); > > }; > > > > exit; > > } > > -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : +1-678-954-0670 Direct : +1-678-954-0671

17 years, 1 month

← Newer
1
...
14
15
16
17
18
19
20
...
29
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 October 2007