sr-users March 2008

sr-users@lists.kamailio.org

169 participants
237 discussions

Re: [OpenSER-Users] issue - remote sip client must re-register after failover in Openser Registrar HA config

by Naija Man

Thanks Patrick, I have re-configured a common database for the servers and I am still having the same issues. Can this be an issue with PAT at the Load balancer after failover since the INVITE is coming from openser_2 and going to the same IP:port associated with openser_1. I am also open to trying other methods to achieve OpenSER registrar HA if any available. Thanks. Buki A > > > ---------- Forwarded message ---------- > > From: Patrick Miccio <pmiccio(a)upcbroadband.com> > > To: <users(a)lists.openser.org> > > Date: Thu, 6 Mar 2008 11:04:40 +0100 > > Subject: Re: [OpenSER-Users] issue - remote sip client must re-register > > after failover in Openser Registrar HA config > > Hi, > > > > you need to have a common mysql table for the registrations so that when > > OpenSER_2 taks over it has the informations > > OpenSER_1 wrote in the DB. > > > > you can achieve this with a single mysql server, or better with a > > cluster ;) > > > > > > cheers, > > > > Patrick. > > > > > > > Hi friends, > > > > > > I am having problems setting up seamless openser registrar failover. I > > am trying to setup OpenSER registrar HA using > > > 2 openser registrars v1.3.0 behind a Netscaler citrix Load balancer > > and I cant get the failover scenario to work > > > without re-registration of the remote sip client. > > > > > > I am desperately looking for tips to make this configuration work or > > any other ideas to achieve SIP registrar HA > > > using OpenSER. Thanks. > > > > > > > > > > > > The setup is configured as active-passive and the 2nd OpenSER becomes > > active only after a Openser_1 fails and the LB > > > fails-over to the 2nd. The 2 openser servers are SIP registrars for my > > voice network. > > > > > > REGISTRATION: > > > remote SIP UA ---> remote firewall ---> internet ---> my firewall ---> > > citrix NA loadbalancer (VIP) ----> openSER_1 > > > > > \---> > > > openSER_2 > > > > > > 1. Remote SIP client configures the LB VIP as the SIP proxy and > > registers > > > 2. the citrix LB gets the registrations and forwards to the active > > openser (say, openser_1) > > > 3. openser_1 stores the contact as MIP:port in the mysql database > > > 4. openser_1 replicates the registration to openser_2 (t_replicate) > > > > > > OUT-GOING CALL - before fail-over > > > remote SIP UA <--- remote firewall <--- internet <--- my firewall <--- > > citrix NA loadbalancer (VIP) <----> openSER_1 > > > > > ^ > > > openSER_2 | > > > > > Asterisk > > > > > > 1. call (INVITE) is generated from asterisk and sent to LB VIP > > > 2. the citrix LB gets the INVITE and forwards to the active openser > > (say, openser_1) > > > 3. openser_1 looks-up the URI in the MySQL database, finds the > > MIP:port that the registration was received from the > > > LB and forwards the INVITE to that destination. 4. the LB receives > > the INVITE and forwards it to the remote SIP > > > client > > > > > > > > > OUT-GOING CALL - after fail-over > > > remote SIP UA ---x remote firewall ---x internet ---x my firewall > > ---x citrix NA loadbalancer (VIP) ----x openSER_1 > > > > > ^ > > > \-----< openSER_2 | > > > > > Asterisk > > > > > > 1. call (INVITE) is generated from asterisk and sent to LB VIP > > > 2. the citrix LB gets the INVITE and forwards to the openser now > > active (openser_2) > > > 3. openser_2 looks-up the URI in the MySQL database, finds the same > > MIP:port of the LB that was replicated from > > > openser_1 and forwards the INVITE to that destination. 4. the LB > > receives the INVITE and drops the packet without > > > forwarding it out to the remote SIP client > > > > > > > > > > > > For the outgoing call to work: the remote sip client either has to > > re-register, so the registration gets passed to > > > openser_2. OR, openser_1 is made active again. > > > > > > > > > Configuration of OpenSER: > > > > > > REGISTRATION: > > > # If this is a registration from the public UA, > > > # then we store it > > > fix_nated_contact(); # use ip address of the packet > > instead of the sip message > > > force_rport(); # append rport. might not be necessary > > > > > > # save Registration in location table > > > save("location"); > > > xlog("L_DBG", "SipMsgId[$mi] Save Registration: > > To[$tu] Contact[$ct]\n"); > > > append_hf("CtlRegFwd: \r\n"); > > > # replicate the register message to the backup > > registrar > > > # if I am the backup, ignore the message > > > if(!t_replicate("sip:openser_2:5060")) { > > > xlog("L_WARN", "SipMsgId[$mi] Fail to replicate > > Contact[$ct] to fail over registrar\n"); > > > > > > OUTGOING CALL: > > > > > > # Do lookup so it gets to the correct NATed destination > > > if (!lookup("location")) > > > { > > > # this user has not REGISTERed or registration has > > expired > > > xlog("L_INFO", "SipMsgId[$mi] Send 404-Not Found (Msg > > rejected because user not found)\n"); > > > sl_send_reply("404", "Not Found"); > > > exit; > > > }; > > > > > > # keep track of reply > > > t_on_reply("11"); > > > if (!t_relay()) > > > { > > > xlog("L_DBG", "SipMsgId[$mi] Failed t_relay. Do > > sl_reply_error.\n"); > > > sl_reply_error(); > > > }; > > > > > > > > > > > > Thank you for your anticipated help. > > > > > > Regards, > > > > > > Buki A > > > > > > >

16 years, 6 months

[OpenSER-Users] ERROR:core:main: bad user name/uid number: -u openser

by bsb093

Hi all, I am still trying to run OpenSER. Now I see the following error: ERROR:core:main: bad user name/uid number: -u openser I am trying to install version 1.3 with MySQL. I have succeeded to create the db but when trying to run OpenSER I still have this error. I have found in the forum that maybe I don't have openser user in /etc/passwd and that is true but I can't figure how to create that user. Any suggestions? Thanks in advance, Shine -- View this message in context: http://www.nabble.com/ERROR%3Acore%3Amain%3A-bad-user-name-uid-number%3A--u… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

16 years, 6 months

Re: [OpenSER-Users] Users Digest, Vol 34, Issue 17

by Naija Man

Thanks Patrick, I have re-configured a common database for the servers and I am still having the same issues. Can this be an issue with PAT at the Load balancer after failover since the INVITE is coming from openser_2 and going to the same IP:port associated with openser_1. I am also open to trying other methods to achieve OpenSER registrar HA if any available. Thanks. Buki A > ---------- Forwarded message ---------- > From: Patrick Miccio <pmiccio(a)upcbroadband.com> > To: <users(a)lists.openser.org> > Date: Thu, 6 Mar 2008 11:04:40 +0100 > Subject: Re: [OpenSER-Users] issue - remote sip client must re-register > after failover in Openser Registrar HA config > Hi, > > you need to have a common mysql table for the registrations so that when > OpenSER_2 taks over it has the informations > OpenSER_1 wrote in the DB. > > you can achieve this with a single mysql server, or better with a cluster > ;) > > > cheers, > > Patrick. > > > > Hi friends, > > > > I am having problems setting up seamless openser registrar failover. I > am trying to setup OpenSER registrar HA using > > 2 openser registrars v1.3.0 behind a Netscaler citrix Load balancer and > I cant get the failover scenario to work > > without re-registration of the remote sip client. > > > > I am desperately looking for tips to make this configuration work or any > other ideas to achieve SIP registrar HA > > using OpenSER. Thanks. > > > > > > > > The setup is configured as active-passive and the 2nd OpenSER becomes > active only after a Openser_1 fails and the LB > > fails-over to the 2nd. The 2 openser servers are SIP registrars for my > voice network. > > > > REGISTRATION: > > remote SIP UA ---> remote firewall ---> internet ---> my firewall ---> > citrix NA loadbalancer (VIP) ----> openSER_1 > > > \---> > > openSER_2 > > > > 1. Remote SIP client configures the LB VIP as the SIP proxy and > registers > > 2. the citrix LB gets the registrations and forwards to the active > openser (say, openser_1) > > 3. openser_1 stores the contact as MIP:port in the mysql database > > 4. openser_1 replicates the registration to openser_2 (t_replicate) > > > > OUT-GOING CALL - before fail-over > > remote SIP UA <--- remote firewall <--- internet <--- my firewall <--- > citrix NA loadbalancer (VIP) <----> openSER_1 > > > ^ > > openSER_2 | > > > Asterisk > > > > 1. call (INVITE) is generated from asterisk and sent to LB VIP > > 2. the citrix LB gets the INVITE and forwards to the active openser > (say, openser_1) > > 3. openser_1 looks-up the URI in the MySQL database, finds the > MIP:port that the registration was received from the > > LB and forwards the INVITE to that destination. 4. the LB receives the > INVITE and forwards it to the remote SIP > > client > > > > > > OUT-GOING CALL - after fail-over > > remote SIP UA ---x remote firewall ---x internet ---x my firewall ---x > citrix NA loadbalancer (VIP) ----x openSER_1 > > > ^ > > \-----< openSER_2 | > > > Asterisk > > > > 1. call (INVITE) is generated from asterisk and sent to LB VIP > > 2. the citrix LB gets the INVITE and forwards to the openser now > active (openser_2) > > 3. openser_2 looks-up the URI in the MySQL database, finds the same > MIP:port of the LB that was replicated from > > openser_1 and forwards the INVITE to that destination. 4. the LB > receives the INVITE and drops the packet without > > forwarding it out to the remote SIP client > > > > > > > > For the outgoing call to work: the remote sip client either has to > re-register, so the registration gets passed to > > openser_2. OR, openser_1 is made active again. > > > > > > Configuration of OpenSER: > > > > REGISTRATION: > > # If this is a registration from the public UA, > > # then we store it > > fix_nated_contact(); # use ip address of the packet > instead of the sip message > > force_rport(); # append rport. might not be necessary > > > > # save Registration in location table > > save("location"); > > xlog("L_DBG", "SipMsgId[$mi] Save Registration: To[$tu] > Contact[$ct]\n"); > > append_hf("CtlRegFwd: \r\n"); > > # replicate the register message to the backup registrar > > # if I am the backup, ignore the message > > if(!t_replicate("sip:openser_2:5060")) { > > xlog("L_WARN", "SipMsgId[$mi] Fail to replicate > Contact[$ct] to fail over registrar\n"); > > > > OUTGOING CALL: > > > > # Do lookup so it gets to the correct NATed destination > > if (!lookup("location")) > > { > > # this user has not REGISTERed or registration has > expired > > xlog("L_INFO", "SipMsgId[$mi] Send 404-Not Found (Msg > rejected because user not found)\n"); > > sl_send_reply("404", "Not Found"); > > exit; > > }; > > > > # keep track of reply > > t_on_reply("11"); > > if (!t_relay()) > > { > > xlog("L_DBG", "SipMsgId[$mi] Failed t_relay. Do > sl_reply_error.\n"); > > sl_reply_error(); > > }; > > > > > > > > Thank you for your anticipated help. > > > > Regards, > > > > Buki A > > >

16 years, 6 months

Re: [Serusers] General Question on BYE

by Mike Trest - Personal

Thanks Greger. I set debug to 9 and found the BYE inside the log file. It was seen by SER. Now I have a trail on the culprit. ..mike.. At 11:24 AM 3/7/2008, Greger Viken Teigre wrote: >Easy answer: none. >If there is a packet on a port SER is listening to, it will try to >parse it. If you don't see it with xlog, there should be an error >log message or it is dropped in a firewall. >g-) > >Mike Trest - Personal wrote: >>Hi, >> >>I have see recent discussions on this topic among developers >>but I am trying to ask a general question without getting into >>ser.cfg and 0.9x vs 2.x comparisons. >> >>My Question: >> >>What are the practical reasons why SER 2.0 would simply ignore "BYE" >>messages sent to it from a gateway when the user terminates a call? >> >> user => gateway => ser => gateway >> >>Good connection and conversation. When the user hangs up >>Gateway sends BYE message. SER does not reply or forward >>to destination gateway. SER never even sees it. >> >>I see the BYE message on tshark but it does not appear in ser.cfg >>with xlog() statements right at the top or route{}. >> >>Anyone with an opinion or suggestion to offer? >> >>..mike.. >> >>_______________________________________________ >>Serusers mailing list >>Serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >> >> > >

16 years, 6 months

Re: [Serusers] [Sems] Poll on dropping unix socket interface ("unixsockctrl")

by samuel

In the past I experienced "bad performance" using unixsoctrl with medium load so I think it's worth making users moving to new interfaces. vote for removing it samuel. 2008/3/7, Juha Heinanen <jh(a)tutpro.com>: > > Raphael Coeffic writes: > > > - reduces configuration and run-time complexity > > > this proved to be true. my openser configuration became much simpler > when i migrated it from unixsockets to sip. > > > -- juha > > _______________________________________________ > Sems mailing list > Sems(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/sems >

16 years, 6 months

[OpenSER-Users] How to access pseudovariables in exported functions?

by Peter Lemenkov

Hello All! I need to put more than 2 parameters in my module, and there are pseudovariables among them. If I find a way to access them within my function then two parameters will be enough. Namely I need to access $fU, $tU and $rU. Using parse_headers function I can only get $fu, $tu and $ru. -- With best regards!

16 years, 6 months

[OpenSER-Users] ERROR: presence_xml:get_final_notify_body?

by KevinKinnan

My testbed is combination of openser and openxcap. openser.cfg file is similar with the example on the website of OpenXCAP. After updating published information by sending PUBLISH, no NOTIFY message is sent to client-side. I got the following errors(debug=3) in syslog file. Any ideas anyone? --------------------------------------------------------------------------------------- ERROR:presence_xml:get_final_notify_body: while extracting the transformation node ERROR:presence_xml:pres_apply_auth: in function get_final_notify_body ERROR:presence:send_notify_request: in function apply_auth_nbody ERROR:presence:notify: sending Notify not successful ERROR:presence:publ_notify: Could not send notify for presence --------------------------------------------------------------------------------------- Regards, Kevin _________________________________________________________________ 手机也能上 MSN 聊天了，快来试试吧！ http://mobile.msn.com.cn/

16 years, 6 months

Re: [OpenSER-Users] OpenSER + OpenXcap for pres-rules: no NOTIFY

by Mircea Amarascu

16 years, 6 months

[OpenSER-Users] CANCEL with Route headers

by Andreas Granig

Hi all, I've a Cisco PGW interconnecting with an OpenSER server. The INVITE is sent to OpenSER, which does some record-routing via some different hops and then sends back the 180 from the called party. If the calling party now cancels the call, the PGW tries to loose-route the CANCEL by adding the Route header to the CANCEL and altering the R-URI, which is rejected by my OpenSER since I don't allow initial loose-routing. So the question is: is it valid for a CANCEL to carry a Route header which wasn't available in the INVITE? §9.1 of RFC3261 says it MUST contain the Route header if it was present in the request being cancelled. What about the other way around? I heavily suspect it's violating the RFC since CANCEL should be more or less a 1:1 copy of the INVITE, but can anyone confirm this? If it violates the RFC, anyone with some Cisco knowledge who knows how to disable this behavior, or is it a known bug? Cheers, Andreas

16 years, 6 months

[OpenSER-Users] "noisy_ctimer" parameter in TM module

by Bogdan-Andrei Iancu

Hi, I want to get some feedback from the users regarding one of the TM parameters: "noisy_ctimer" . This parameter, is disabled, would try to let a call to ring for ever (openser will never give internal timeout). But, the parameter is automatically turned on (disregarding the script setting) in certain conditions: - parallel forking is done - a failure route is set - a failure callback is set by other module (like acc, cpl, dialog, etc) - a fr_invite timeout was configured via AVP - some reply was already received - no other module explicitly asked for this (like siptrace, acc,osp) Following some discussion on the tracker, there is large support for removing this parameter as: 1) it is difficult to anticipate the final behaviour due complicated logic 2) due all dependencies, in 99% of the case, the param will be automatically turned on 3)it breaks the RFC3261, which make mandatory to have a final reply form a stateful proxy My question is: Is anybody having a good point in not removing this parameter (and having noisy_ctimer behaviour all the time)? I'm pushing this question only on users list, as between the developers, there is an consent in removing it ;) Regards, Bogdan

16 years, 6 months

← Newer
1
...
16
17
18
19
20
21
22
23
24
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 March 2008