[OpenSIPS-Users] Help with "t_relay"
Hi list, i need some hints by you experts to get working my idea.
What I am trying to do is parallel forking toward 2 different IP PBXs whose
have different carateristics. Let me explain:
IP PBX #1: accept UDP connections on port 5060
IP PBX #2: accept TCP connections on port 5068
What i tried to do is as follow:
if (src_ip == IP_MEDIANT || (method=="INVITE")) {
rewritehostport("FQDN_IP_PBX_2:PORT_IP_PBX_2");
route(10);
exit;
}
.
route[10] {
append_branch();
t_relay("tcp:IP_PBX_2:PORT_IP_PBX_2");
exit;
}
So now I am stuck because i have some dubts that i can't answer:
1- How Can I forward the original request and the new BRANCH created to
different "t_relays" ( which they have to have different features (UDP, TCp
etc.. ) ) ?
I tried with
$(branch(uri)[0]) = "sip:???@IP_PBX_1:PORT_IP_PBX_1";
But seems not working. In this last snippet of code, Can I use pseudo
variables like $rU??
$(branch(uri)[0]) = "sip:$rU@IP_PBX_1:PORT_IP_PBX_1"; ( ? )
Hope someone can point me in a right way.
Regards
I did not found into documentation something about protocol for Branches
sections. In my case i also need to change it to UDP.
--
View this message in context:
http://opensips-open-sip-server.1449251.n2.nabble.com/Help-with-t-relay-tp7583170.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] how to forward SIP messages?
It means you are still doing forwarding. Find "forward" method and comment
it. :-)
Thank you.
On Thu, Nov 22, 2012 at 8:07 PM, Christian Cambier wrote:
> Hello.
>
> Direct registration (not passing via the proxy) with extension:
> 5006@10.0.2.16 works
> (see SIP trace 1)
>
>
> Registration with the same extension but via the proxy doesn't work
>
> (see SIP trace 2)
>
> I've added in the proxy as you suggested:
> record_route();
>
> rewritehostport("10.0.2.16:5060");
>
> t_relay();
>
> exit;
>
>
> Interesting to note though is that the message has been forwarded to the
> PBX (see Server-header in the response) but the PBX didn't accept the
> registration
>
>
>
> ==
> SIP trace 1 (OK)
>
> ** **
>
> REGISTER sip:10.0.2.16:5060 SIP/2.0
>
> Via: SIP/2.0/UDP
> 10.0.46.1:5082;rport;branch=z9hG4bKPj28b4d6575de442a5afb372fe9ddc47a9
>
>
> Max-Forwards: 70
>
> From: "cid5006" ;tag=43098562225648238bd899bc85994e05
>
>
> To: "cid5006"
>
> Call-ID: 78017ce971b646e7a6f41bd60601fd9c
>
> CSeq: 38561 REGISTER
>
> User-Agent: VoxtronSipPhone_01.00.010.000
>
> Contact: "cid5006"
>
> Expires: 300
>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
> MESSAGE, OPTIONS
>
> Content-Length: 0
>
> ** **
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP
> 10.0.46.1:5082;rport;branch=z9hG4bKPj7621a9f9aa544be7b50abc499f68b004
>
>
> From: "cid5006" ;tag=43098562225648238bd899bc85994e05
>
>
> To: "cid5006" ;tag=3609800608
>
> Call-ID: 78017ce971b646e7a6f41bd60601fd9c
>
> CSeq: 38562 REGISTER
>
> Contact: ;expires=120
>
> Allow:
> REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
>
>
> Content-Length: 0
>
> Date: Thu, 22 Nov 2012 19:55:46 GMT
>
> Expires: 120
>
> Server: (innovaphone IP6000/8.00 hotfix25 [80500.65/8050065/107])
>
> Allow-Events: reg,dialog,message-summary,presence
>
> Presence-State: register-action="added"
>
> P-Alias: 0,4,5006
>
> P-Alias: 2,6,id5006
>
> ** **
>
>
> ==
>
>
> SIP trace 2 (Not OK)
>
>
> REGISTER sip:10.0.2.16:5060 SIP/2.0
>
> Via: SIP/2.0/TCP
> 10.0.46.1:49370;rport;branch=z9hG4bKPjd606484bdde5459a96175285593932df
>
>
> Route:
>
> Max-Forwards: 70
>
> From: "cid5006" ;tag=9bf43fc5cfb04bce8f6f42150223c301
>
>
> To: "cid5006"
>
> Call-ID: c6752588892f4ba499ddba6d5d9bc90e
>
> CSeq: 26467 REGISTER
>
> User-Agent: VoxtronSipPhone_01.00.010.000
>
> Supported: outbound, path
>
> Contact: "cid5006"
> ;reg-id=1;+sip.instance=""
>
>
> Expires: 300
>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
> MESSAGE, OPTIONS
>
> Content-Length: 0
>
> ** **
>
> SIP/2.0 301 Moved Permanently
>
> Via: SIP/2.0/TCP
> 10.0.46.1:49370;received=10.0.46.1;rport=49370;branch=z9hG4bKPjd606484bdde5459a96175285593932df
>
>
> From: "cid5006" ;tag=9bf43fc5cfb04bce8f6f42150223c301
>
>
> To: "cid5006" ;tag=3609800590
>
> Call-ID: c6752588892f4ba499ddba6d5d9bc90e
>
> CSeq: 26467 REGISTER
>
> Contact:
>
> Content-Length: 0
>
> Server: (innovaphone IP6000/8.00 hotfix25 [80500.65/8050065/107])
>
>
> How to solve this?
>
> thx
> Chris
>
> ** **
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] how to forward SIP messages?
Hello.
Direct registration (not passing via the proxy) with extension:
5006@10.0.2.16 works
(see SIP trace 1)
Registration with the same extension but via the proxy doesn't work
(see SIP trace 2)
I've added in the proxy as you suggested:
record_route();
rewritehostport("10.0.2.16:5060");
t_relay();
exit;
Interesting to note though is that the message has been forwarded to the
PBX (see Server-header in the response) but the PBX didn't accept the
registration
==
SIP trace 1 (OK)
REGISTER sip:10.0.2.16:5060 SIP/2.0
Via: SIP/2.0/UDP
10.0.46.1:5082;rport;branch=z9hG4bKPj28b4d6575de442a5afb372fe9ddc47a9
Max-Forwards: 70
From: "cid5006"
;tag=43098562225648238bd899bc85994e05
To: "cid5006"
Call-ID: 78017ce971b646e7a6f41bd60601fd9c
CSeq: 38561 REGISTER
User-Agent: VoxtronSipPhone_01.00.010.000
Contact: "cid5006"
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP
10.0.46.1:5082;rport;branch=z9hG4bKPj7621a9f9aa544be7b50abc499f68b004
From: "cid5006"
;tag=43098562225648238bd899bc85994e05
To: "cid5006" ;tag=3609800608
Call-ID: 78017ce971b646e7a6f41bd60601fd9c
CSeq: 38562 REGISTER
Contact: ;expires=120
Allow:
REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO
,UPDATE,PUBLISH
Content-Length: 0
Date: Thu, 22 Nov 2012 19:55:46 GMT
Expires: 120
Server: (innovaphone IP6000/8.00 hotfix25 [80500.65/8050065/107])
Allow-Events: reg,dialog,message-summary,presence
Presence-State: register-action="added"
P-Alias: 0,4,5006
P-Alias: 2,6,id5006
==
SIP trace 2 (Not OK)
REGISTER sip:10.0.2.16:5060 SIP/2.0
Via: SIP/2.0/TCP
10.0.46.1:49370;rport;branch=z9hG4bKPjd606484bdde5459a96175285593932df
Route:
Max-Forwards: 70
From: "cid5006"
;tag=9bf43fc5cfb04bce8f6f42150223c301
To: "cid5006"
Call-ID: c6752588892f4ba499ddba6d5d9bc90e
CSeq: 26467 REGISTER
User-Agent: VoxtronSipPhone_01.00.010.000
Supported: outbound, path
Contact: "cid5006"
;reg-id=1;+sip.instance=""
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0
SIP/2.0 301 Moved Permanently
Via: SIP/2.0/TCP
10.0.46.1:49370;received=10.0.46.1;rport=49370;branch=z9hG4bKPjd606484bd
de5459a96175285593932df
From: "cid5006"
;tag=9bf43fc5cfb04bce8f6f42150223c301
To: "cid5006" ;tag=3609800590
Call-ID: c6752588892f4ba499ddba6d5d9bc90e
CSeq: 26467 REGISTER
Contact:
Content-Length: 0
Server: (innovaphone IP6000/8.00 hotfix25 [80500.65/8050065/107])
How to solve this?
thx
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2b custom_header not working!
What headers you are trying to preserve, its possible that the headers your are try to save are mandatory headers necessary for B2BUA function, which will get duplicated if you try to preserve then from leg 1 to leg 2. See custom_headers documentation for more info. Thank you. On Thu, Nov 22, 2012 at 5:25 PM, Jorge Henrique Pinho < jorge-h-pi...@ext.ptinovacao.pt> wrote: > Hi all, > I have installed opensips-1.7.2-2.el5 and I am using b2b module. > I need to preserve some headers that b2b module changes. I was using avp > and textops modules in local_route to accomplish that. But this lead to > unexpected behaviours by opensips. > So i define the custom_headers variable in my configuration ( > http://www.opensips.org/html/docs/modules/1.7.x/b2b_logic.html#id250020), > and the message that b2b passes to the other side of the dialog has the > preserve headers repeated. One header with the original value and other > with the new value generated by b2b module. > Is this the correct behaviour? How do i solve this? > > Thanks in advance, > > Jorge Pinho > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] how to forward SIP messages?
Hi,
You can use this, basically taken from the default OpenSIPS script - at
the end of the route check the "rewritehostport" :
### Routing Logic
# main request routing logic
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("INVITE")) {
# even if in most of the cases is
useless, do RR for
# re-INVITEs alos, as some buggy
clients do change route set
# during the dialog.
record_route();
}
# route it out to whatever destination was set
by loose_route()
# in $du (destination URI).
t_relay();
exit;
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful
ACK; must be an ACK after
# a 487 or e.g. 404 from
upstream server
t_relay();
exit;
} else {
# ACK without matching
transaction ->
# ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
t_check_trans();
if (!is_method("INVITE")) {
sl_send_reply("500","Method not allowed");
exit;
}
record_route();
rewritehostport("10.0.2.16:5060");
t_relay();
exit;
}
On 11/22/2012 06:04 PM, Christian Cambier wrote:
Hi.
I'd like to use openSIPS proxy (10.0.4.34) for tracing but leave all
SIP-handling to a PBX that is on the same network (10.0.2.16)
I tried just forwarding the sip-messages on the proxy using
forward("10.0.2.16:5060
Re: [OpenSIPS-Users] installing OpenSIPS on Centos 5.8
you need to install the ncurses-devel package via yum -Laszlo 2012/11/22 Carlos Cruz : > > > I really don't know why it needs to be so difficult to install a piece of > software? > > > > I'm trying to install OpenSIPS on CentOS 5.8 below are the errors I get: > > > > I've done quite a bit research, I've tried the suggestions described in the > mailing list under the subject "Re: libmysqlclient-dev for CentOS?" but I > still can't get off the ground. I would appreciate any suggestions or tips!! > > > > I am willing to pay someone to assist me with this and to also help with > getting me started with basic integration with Asterisk. If you're > interested I can pay you via PayPal. I can give you temporary access to a > VM. If you're interested or know someone who could be, let me know. > > > > > > > > [root@localhost opensips-1.8.2-tls]# make menuconfig > bison -d -b cfg cfg.y > cfg.y: conflicts: 1 shift/reduce > flex cfg.lex > cd menuconfig; make ; cd .. > make[1]: Entering directory > `/usr/src/opensips/opensips-1.8.2-tls/menuconfig' > gcc -g -Wall -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\" > -DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1 -c -o cfg.o > cfg.c > In file included from main.h:33, > from cfg.c:30: > curses.h:31:19: error: curses.h: No such file or directory > In file included from cfg.c:30: > main.h:35: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘*’ token > main.h:40: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘*’ token > make[1]: *** [cfg.o] Error 1 > make[1]: Leaving directory `/usr/src/opensips/opensips-1.8.2-tls/menuconfig' > ./menuconfig/configure --local > make: ./menuconfig/configure: Command not found > make: *** [menuconfig] Error 127 > > > > > > > > > > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] installing OpenSIPS on Centos 5.8
I really don't know why it needs to be so difficult to install a piece of software? I'm trying to install OpenSIPS on CentOS 5.8 below are the errors I get: I've done quite a bit research, I've tried the suggestions described in the mailing list under the subject "Re: libmysqlclient-dev for CentOS?" but I still can't get off the ground. I would appreciate any suggestions or tips!! I am willing to pay someone to assist me with this and to also help with getting me started with basic integration with Asterisk. If you're interested I can pay you via PayPal. I can give you temporary access to a VM. If you're interested or know someone who could be, let me know. [root@localhost opensips-1.8.2-tls]# make menuconfig bison -d -b cfg cfg.y cfg.y: conflicts: 1 shift/reduce flex cfg.lex cd menuconfig; make ; cd .. make[1]: Entering directory `/usr/src/opensips/opensips-1.8.2-tls/menuconfig' gcc -g -Wall -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\" -DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1 -c -o cfg.o cfg.c In file included from main.h:33, from cfg.c:30: curses.h:31:19: error: curses.h: No such file or directory In file included from cfg.c:30: main.h:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token main.h:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token make[1]: *** [cfg.o] Error 1 make[1]: Leaving directory `/usr/src/opensips/opensips-1.8.2-tls/menuconfig' ./menuconfig/configure --local make: ./menuconfig/configure: Command not found make: *** [menuconfig] Error 127 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] B2b custom_header not working!
Hi all, I have installed opensips-1.7.2-2.el5 and I am using b2b module. I need to preserve some headers that b2b module changes. I was using avp and textops modules in local_route to accomplish that. But this lead to unexpected behaviours by opensips. So i define the custom_headers variable in my configuration (http://www.opensips.org/html/docs/modules/1.7.x/b2b_logic.html#id250020), and the message that b2b passes to the other side of the dialog has the preserve headers repeated. One header with the original value and other with the new value generated by b2b module. Is this the correct behaviour? How do i solve this? Thanks in advance, Jorge Pinho ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] how to forward SIP messages?
Hi.
I'd like to use openSIPS proxy (10.0.4.34) for tracing but leave all
SIP-handling to a PBX that is on the same network (10.0.2.16)
I tried just forwarding the sip-messages on the proxy using
forward("10.0.2.16:5060
Re: [OpenSIPS-Users] [RFC] New Release Policy for OpenSIPS project
Hi Saul, On 11/22/2012 12:46 PM, Saúl Ibarra Corretgé wrote: Release cycles === - instead of a feature driven release cycle, I would prefer a time driven release cycle - because it is more predictable and being feature driven may actually escalate the time to the next release (the snowball effect) - see the timing for 1.7, 1.8 versions - have a 5-7 months release cycle (depending on the required volume of work) - smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade ; also shorter release cycles will make new features available in stable versions much faster. While a time-based release cycle sounds good to me for minor releases (1.8.1, 1.8.2, ...) I'm not sure if it can also be applied to major releases. What if feature X takes longer than expected to develop? Things may be inadvertently rushed and that's not good. For major releases I'd go with the Debian-ish policy: it's ready when it's ready :-) [bogdan] The problem I see with the features-based release cycle is that they are unpredictable as time - some features may not be properly (or impossible) time evaluated -> it may stretch the interval between releases ; IMHO, for a project to reliable it is a must to be predictable. The best examples are what is happening now with OpenSIPS (the interval between releases is keep growing) and Debian (lack of predictability and huge intervals between release ended up in the Ubuntu alternative). Being able to predict the releases (as time) without huge differences between versions (to make an upgrade something easy you are not scared like hell to do it) should be some key-feature of the project. The time-based releases should not be affected by how long a feature takes to be implemented - 6 months of development for a feature is really more than enough, IMHO. PS: let me ask you: how many OpenSIPS installations do you still have running old versions because upgrade is really painful ? ;) Next Release TODO == - on a new cycle, we should start with a brainstorming on what the next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community. - maintain a web page with the TODO features that will be updated (this process is to be continuous); also the items that where address to be documented and listed as new available features (see http://www.opensips.org/Main/Ver190) - as the release is time driven, the next release will contain only the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release. Steps inside a Cycle - brainstorming on TODO list - estimating the release time (T) based on the volume of work (between 5-7 months) - actual work on implementing the items on TODO list ; it is critical important to have a better description / documentation / examples on the newly added feature -> it will help people to understand and use them from day 0 (an undocumented super feature is an inexistent feature) - SVN freeze (no more new stuff) at T - 1 months ; at this point the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release) ; this will make the trunk free and available for new work in the mean while (we overlap the testing on release N with the start of release N+1) - testing, debugging - 1 month -> at T we have the GA release (full stable release) Version Management == - at any moment, officially we will support only the last 2 stable release (by support I mean troubleshooting, fixing bugs, backporting, etc) - whatever is older than 2 stable release (like older than 1.7 now) is unsupported (no fixing, no packing, no new tarballs) - when a new release gets to a full stable state, the window of 2 supported versions is shifted (like when 1.9 will become stable, 1.7 will become obsolete and unsupported). What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not a task to be taken lightly. [bogdan] That is true problem that may have as solutions: 1) simply upgrade (most common way to go in open source world) , considering that upgrades should become easier. 2) try to define what is really critical (based on what??) and still do backporting - but at the end of the day we need to encourage people to use the new versions - keep patching and supporting really old versions (consider 1.6 at this point) is
Re: [OpenSIPS-Users] Fix empty lines in SIP headers generated by buggy hardware
Use TextOPS module,
http://www.opensips.org/html/docs/modules/1.8.x/textops.html#id250208
You probably need to use it something like this,
replace_all("^\s+$", "");
You have to do this BEFORE involving B2BUA stuff.
Thank you.
On Thu, Nov 22, 2012 at 2:03 PM, Adam Raszynski wrote:
> Hi
>
> I have problem with some buggy hardware ATAs and routers, some of them
> mess SIP requests by adding empty lines (\n or \r\n) between headers.
>
> For example:
>
> Via: SIP/2.0/UDP 80.1.1.1:5060;branch=z9hG4bKe89.28ac75a.0
> To: sip:80.1.1.1
> From: >;tag=13e3d64e25956fb4c1e2442af82fd0e3-c2c5
> CSeq: 14 INVITE
>
> Call-ID: 1af0eccc5994a91b-19144@80.1.1.1
> Max-Forwards: 70
> Content-Length: 0
>
>
> Note empty line between CSeq and Call-Id. That's just example, empty lines
> appear in random order.
>
> I route calls to sippy B2BUA wich does not accept malformed requests and
> throw exception in that condition.
>
> Is it possible to detect such requests in OpenSIPS and remove unnecessary
> empty lines from between headers?
>
> Regards
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Fix empty lines in SIP headers generated by buggy hardware
Hi I have problem with some buggy hardware ATAs and routers, some of them mess SIP requests by adding empty lines (\n or \r\n) between headers. For example: Via: SIP/2.0/UDP 80.1.1.1:5060;branch=z9hG4bKe89.28ac75a.0 To: sip:80.1.1.1 From: ;tag=13e3d64e25956fb4c1e2442af82fd0e3-c2c5 CSeq: 14 INVITE Call-ID: 1af0eccc5994a91b-19144@80.1.1.1 Max-Forwards: 70 Content-Length: 0 Note empty line between CSeq and Call-Id. That's just example, empty lines appear in random order. I route calls to sippy B2BUA wich does not accept malformed requests and throw exception in that condition. Is it possible to detect such requests in OpenSIPS and remove unnecessary empty lines from between headers? Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] New Release Policy for OpenSIPS project
Hi Bogdan, It's great to see this. See some comments inline. On Nov 22, 2012, at 11:34 AM, Bogdan-Andrei Iancu wrote: > Hi all, > > I want to bring to public discussion the changing of the release policy of > the project. Why, because I had an interesting feedback from the community > after the email on shaping the 1.9 release and I felt the need of straighting > some things up. > > First of all, what this change should target? It should make the release > process : > - more open - anyone from community (and not only developers) should be > able to > contribute to roadmap of the next release (on what should be done) > - more predictable - everyone should know when and how the next release > will be > available, so they can rely and sync their own private schedules (for > using opensips) > with the project scheduling. You will know when the next release will > be available > as RC, as GA, etc, you will know what features will contain, you will > know when to > get involved for bringing in discussion some new features for the > next release. > - more transparent - the entire releasing process to be generally known > in details, so > we can achieve a better collaboration and interfacing between > community and developers > (we should avoid a separation between these two entities and rather > put them together > to work) > > > Now, I'm listing here what I see as a starting point and I'm eager to hear > your comments, suggestions, improvements or any other ideas related to this > topic. > > Release cycles > === > - instead of a feature driven release cycle, I would prefer a time driven > release cycle - because it is more predictable and being feature driven may > actually escalate the time to the next release (the snowball effect) - see > the timing for 1.7, 1.8 versions > - have a 5-7 months release cycle (depending on the required volume of > work) > - smaller steps in releases will be more friendly to users as there are > no big gaps between releases, easier and more appealing to upgrade ; also > shorter release cycles will make new features available in stable versions > much faster. > While a time-based release cycle sounds good to me for minor releases (1.8.1, 1.8.2, ...) I'm not sure if it can also be applied to major releases. What if feature X takes longer than expected to develop? Things may be inadvertently rushed and that's not good. For major releases I'd go with the Debian-ish policy: it's ready when it's ready :-) > Next Release TODO > == > - on a new cycle, we should start with a brainstorming on what the next > release should contain (or focus on). This will open up the development and > roadmap of the project to the entire community. > - maintain a web page with the TODO features that will be updated (this > process is to be continuous); also the items that where address to be > documented and listed as new available features (see > http://www.opensips.org/Main/Ver190) > - as the release is time driven, the next release will contain only the > features (from TODO list, based on priorities) that can be done in that time > frame; the remaining list will be inherited by the next release. > > Steps inside a Cycle > > - brainstorming on TODO list > - estimating the release time (T) based on the volume of work (between > 5-7 months) > - actual work on implementing the items on TODO list ; it is critical > important to have a > better description / documentation / examples on the newly added > feature -> it will help > people to understand and use them from day 0 (an undocumented super > feature is an > inexistent feature) > - SVN freeze (no more new stuff) at T - 1 months ; at this point the SVN > trunk code > is moved in a new separate SVN branch (dedicated to that release)-> > Release Candidate > (or beta release) ; this will make the trunk free and available for > new work in the > mean while (we overlap the testing on release N with the start of > release N+1) > - testing, debugging - 1 month -> at T we have the GA release (full > stable release) > > Version Management > == > - at any moment, officially we will support only the last 2 stable > release (by support I mean > troubleshooting, fixing bugs, backporting, etc) > - whatever is older than 2 stable release (like older than 1.7 now) is > unsupported (no fixing, > no packing, no new tarballs) > - when a new release gets to a full stable state, the window of 2 > supported versions is shifted > (like when 1.9 will become stable, 1.7 will become obsolete and > unsupported). > What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the par
Re: [OpenSIPS-Users] OpenSIPS and Sip-Provider like gateway authenticate.
Checkout the uac_registrant module. On Nov 22, 2012, at 11:28 AM, Miguel J. López Valverde wrote: > Hello users@list.opensips > > I've a query for you. I want to connect my OpenSIP Server with a SIP > provider that requires validate the user account and password instead of by > IP. The question is... ¿It's posible to resgistar OpenSIPS like an UAC > against a SIP-Provider like gateway authenticate by user/pass for send and > recive calls throught it? > > Regards. > > Miguel J. López. > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] [RFC] New Release Policy for OpenSIPS project
Hi all, I want to bring to public discussion the changing of the release policy of the project. Why, because I had an interesting feedback from the community after the email on shaping the 1.9 release and I felt the need of straighting some things up. First of all, what this change should target? It should make the release process : - *more open* - anyone from community (and not only developers) should be able to contribute to roadmap of the next release (on what should be done) - *more predictable* - everyone should know when and how the next release will be available, so they can rely and sync their own private schedules (for using opensips) with the project scheduling. You will know when the next release will be available as RC, as GA, etc, you will know what features will contain, you will know when to get involved for bringing in discussion some new features for the next release. - *more transparent* - the entire releasing process to be generally known in details, so we can achieve a better collaboration and interfacing between community and developers (we should avoid a separation between these two entities and rather put them together to work) Now, I'm listing here what I see as a starting point and I'm eager to hear your comments, suggestions, improvements or any other ideas related to this topic. Release cycles === - instead of a feature driven release cycle, I would prefer a time driven release cycle - because it is more predictable and being feature driven may actually escalate the time to the next release (the snowball effect) - see the timing for 1.7, 1.8 versions - have a 5-7 months release cycle (depending on the required volume of work) - smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade ; also shorter release cycles will make new features available in stable versions much faster. Next Release TODO == - on a new cycle, we should start with a brainstorming on what the next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community. - maintain a web page with the TODO features that will be updated (this process is to be continuous); also the items that where address to be documented and listed as new available features (see http://www.opensips.org/Main/Ver190) - as the release is time driven, the next release will contain only the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release. Steps inside a Cycle - brainstorming on TODO list - estimating the release time (T) based on the volume of work (between 5-7 months) - actual work on implementing the items on TODO list ; it is critical important to have a better description / documentation / examples on the newly added feature -> it will help people to understand and use them from day 0 (an undocumented super feature is an inexistent feature) - SVN freeze (no more new stuff) at T - 1 months ; at this point the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release) ; this will make the trunk free and available for new work in the mean while (we overlap the testing on release N with the start of release N+1) - testing, debugging - 1 month -> at T we have the GA release (full stable release) Version Management == - at any moment, officially we will support only the last 2 stable release (by support I mean troubleshooting, fixing bugs, backporting, etc) - whatever is older than 2 stable release (like older than 1.7 now) is unsupported (no fixing, no packing, no new tarballs) - when a new release gets to a full stable state, the window of 2 supported versions is shifted (like when 1.9 will become stable, 1.7 will become obsolete and unsupported). Regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OpenSIPS and Sip-Provider like gateway authenticate.
Hello users@list.opensips I've a query for you. I want to connect my OpenSIP Server with a SIP provider that requires validate the user account and password instead of by IP. The question is... ¿It's posible to resgistar OpenSIPS like an UAC against a SIP-Provider like gateway authenticate by user/pass for send and recive calls throught it? Regards. Miguel J. López. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
