All posts under tagged ‘OpenSER’

Feed for all posts filed under "OpenSER"

OpenSER Summit At VON X Spring 2008

Source: snapvoip.blogspot.com

As I mentioned, I am pretty excited to visit VON Spring 2008. One more product that I am looking forward to see, attend is the second edition of OpenSER Summit. This will take place during VON X Spring 2008 pre-conference events. This being the first US edition of the OpenSER Summit makes it even more valuable.
The registration has been extended until 14th and if you like OpenSER, you better hurry! You will find more information and registration procedure here.
OpenSER is a Open Source SIP server for XoIP communication needs!

Published on March 11th, 2008 under ,

OpenSER 1.2.3 Released.

Source: snapvoip.blogspot.com

OpenSER has released a new member of the 1.2 family, OpenSER 1.2.3. It brings all kind of fixes (mainly from the 1.3 version) to the 1.2.X branch. Site also noted that no new featues were added. I missed this as I was using the 1.3 from the SVN. Need to visit the site much often. Thanks team now I will inform my clients that use 1.2 branch.
Enhancements and fixes in 1.2.3 includes:
  • small fixes (compile warnings, porting across UNIX platform errors)
  • bug fixing
  • mi_xmlrpc update to work with latest 1.0 libxmlrpc-c3 releases
  • functionality fixes (Route header handling in local sequential requests)
  • small improvments - more self - sanity checks, more verbous error codes in script (like t_relay() in TM).

All the downloads are available from OpenSER Download.

Published on January 8th, 2008 under ,

OpenSER moves to a new location, (Only the Site)

Source: snapvoip.blogspot.com

According to a message on the site, OpenSER Site has moved to a new location and that there might be missing links during the transition. Bear with them.

Published on November 3rd, 2007 under

OpenSER get Berkeley DB support (Experimental)

Source: snapvoip.blogspot.com

OpenSER ads Berkeley DB support. Courtesy of William Quan, of CISCO Systems, a new DB module has been submitted to the trunk that incorporates the Berkeley DB into Openser. This module depends on Berkeley DB, which is a high-performance embedded DB kernel.

The Berkeley DB offers a couple of architectures:
1. Concurrent Data Store (CDS)
2. Transaction Data Store
You will have to access the SVN Trunk to get the module.

Openser Announcement

Readme for the module
Openser SVN at SourceForge

Published on October 15th, 2007 under , , ,

OpenSER Training Session for Administrators at VON Europe!

Source: snapvoip.blogspot.com

VON Europe! is offering multiple training and education units this year and today is the last day to grab some of the best deals. Among the As last year, one of them are;

OpenSER Admin Training Session!

  • Full Access to OpenSER Admin Training Session on Wednesday, 26 September
  • Full Access to VON Conference sessions on Wednesday, 26 September
  • Full Access to Conference tracks in Italian on 26 & 27 September
  • Access to the Expo on 26 & 27 September
  • Access to Networking Lunch and Afternoon Snack

OpenSER, the Open Source SIP Server, is one of the most innovative and scalable VoIP softswitches. It is a flexible and cost-effective software solution that allows you to implement a large set of VoIP platforms, as size (from SMB, residential or carrier), services or models (end-user services, traffic trunking, application server). The "OpenSER Admin Training" course will deliver the deep knowledge you need deal with the diversity and complexity of OpenSER in order to properly configure and optimize your OpenSER system to speed up roll out and administration procedures. The training course is offered by the actual people designing and developing the OpenSER SIP server, in an interactive way, based on examples and hands-on work, in order to guarantee the best knowledge transfer.

Published on September 24th, 2007 under , , ,

Survey: OpenSER Admin Course at VoN Italy

Source: snapvoip.blogspot.com

Survey: OpenSER Admin Course at VoN Italy, September 26, 2007
The OpenSER course will be a one day course and it will be hosted by the VoN Italy in Milan, on 26 September, from 9:30 to 18:00 hours. The package includes breakfast and lunch at the training location and the cost is estimated to be not more than 400 Euro per person. The course is aimed at OpenSER admins who are looking to enhance their knowledge, in configuring different OpenSER features or services via interactive sessions.

The event is organized in collaboration with Pulvermedia and they are assessing the attendees so they can provide the best care to all!
The site says the dead line for the survey is 8th but does not say which month. In either case get in touch with team@openser.org

( This email address is being protected from spam bots, you need Javascript enabled to view it) for any details/questions.

Published on July 15th, 2007 under , , ,

OpenSER VS SER, running on a $3,000 Lintel server, both manage 8 billion minutes of VoIP traffic per year.

Source: snapvoip.blogspot.com

VoIP IP Telephony @ http://snapvoip.blogspot.com via eMediawire.
Two competing open source projects have now been compared in a side by side test. SIP Express Router, also known as SER (www.iptel.org), is the respected pioneer of open source SIP proxies. SER has been available since November 2003 and has a reputation for high performance and reliability. The upstart, OpenSER (www.openser.org) was created when developers disappointed by SER’s slow release schedule, forked a version of SER to create OpenSER in June 2005.
Ever since, SIP proxy users have been faced with the question, which project is best?

TransNexus, an independent developer of VoIP Operations and Billing Support System (OSS/BSS) software decided to answer this question for its customers once and for all. Most product benchmark test plans are designed to yield incredible results for marketing promotion. The TransNexus benchmark plan was different. It was designed to mimic a production network with a lot of failed call attempts and the added overhead of call detail record collection.

As expected, the TransNexus results were not as amazing as some of the other published test results, but they were realistic and still very impressive. Telecom equipment vendors need to beware, both SER and OpenSER are ready to scale for the largest wholesale carrier operations. To summarize the results, TransNexus found that either OpenSER or SER SIP proxies have the performance to manage 720 calls per second on a $3,000 Linux server with dual Intel Xeon CPUs. For a typical wholesale carrier operation, this performance is sufficient to manage over 700 million minutes of traffic each month! While OpenSER and SER are competing against each other, they are rapidly out running the cost/benefit performance offered by commercial telecom equipment vendors.

Here is What Transnexus had to say;

Performance Results for OpenSER and SIP Express Router

We often hear the questions:

  • How fast are OpenSER or SER in a real world environment?

  • How do SER and OpenSER compare?

We decided to answer these questions and created a detailed performance test for OpenSER and SIP Express Router. To simulate a production environment, the SIP proxy under test queries an external OSP server for routing information on each and call and then reports call detail records to an external OSP server. Five destinations are returned to the SIP proxy for each call in random order. Four of the five destinations simulate call failure scenarios so the SIP proxy must retry the call an average of two times before the call is completed. These tests were performed on a single core of an Intel Xeon 5140 2.33 GHz CPU.

Here is a brief summary of what transnexus learned. For all the test details, click here.

  • The performance of OpenSER V1.2 and SER 2.0 are not materially different, however, there are two minor differences.
    • SER V2.0 requires less memory.
    • OpenSER V1.2 has less post dial delay.
  • By all measures, OpenSER V1.2 is significantly better than OpenSER V1.1.

  • For production operation (with call retries and CDR reporting), we suggest the following simple guideline for sizing server hardware to operate at 60% CPU utilization for OpenSER V1.2 and SER V2.0:

One GHz of CPU processing capacity can manage 60 calls per second.

For example, a server with two, dual core, 3.0 GHz CPUs would effectively have (2 CPUs * 2 cores * 3 GHz per CPU) twelve GHz of CPU processing capacity. This server, hosting either OpenSER V1.2 or SER 2.0, would be able to manage 720 calls per second at approximately 60% CPU utilization.

CPU Utilization

The following chart plots CPU utilization as a function of calls per second. The results for OpenSER V1.2 and SER 2.0 are identical. The performance of OpenSER V1.2 is 13% better than OpenSER V1.1.

image002.gif

Memory Usage

Memory is not a major resource requirement, even at high loads. SER 2.0 has the lowest memory requirement.

image004.gif

Post Dial Delay

The data on the following chart is an indirect indication of Post Dial Delay (PDD). The data presented is the percentage of calls in each test that experienced a PDD greater than six seconds.

image006.gif

Call Completion

The following chart presents the percentage of calls which were not completed successfully for each test. When CPU utilization was less 90%, both OpenSER V1.2 and SER 2.0 completed all calls successfully.

image008.gif

Published on May 24th, 2007 under , , ,

Cisco uses OpenSER, an Open Source SIP router and more in Linksys One.

Source: snapvoip.blogspot.com

VoIP IP Telephony @ http://snapvoip.blogspot.com
It is coming in to light that big name companies are using more and more Open Source products. It is no difference when it comes to VoIP. I remember a bunch of companies that used OpenH323 before SIP came to be the leading protocol.
It is revealed that Cisco is using OpenSER as SIP proxy for Service node in Linksys one communication platform.
OpenSER is not the only Open Source Package in the Service Node;
The Cisco Service Node servers run a collection of open-source and Linksys One software:

• FreeBSD-This is the open-source operating system that runs on all Cisco Service Node servers. FreeBSD provides a mechanism that allows multiple virtual instances of the OS to be spawned and run on the same server, with each virtual OS completely isolated from all other instances. This is the partitioning mechanism used to implement the brand-level services.

• PostgreSQL-This open-source package is used to provide database services on the Cisco Service Node.

• OpenSER-This open-source package is used as the Cisco Service Node SIP proxy.

• BIND-This open-source package is used for Domain Name System {DNS) services. The Cisco Service Node runs its own DNS servers. DNS is used for several functions on the Cisco Service Node, including ENUM-based call routing of SIP calls and branding (each brand is known to the outside world as a separate DNS domain name).

• BIND DLZ-This open-source package allows BIND to use the PostgreSQL database to store its zone information. Dynamically loadable zones (DLZ) allows DNS updates to be reflected immediately when a change is made to zone data in the database. This feature is important because CPE that uses Dynamic Host Configuration Protocol (DHCP) can change its IP address at any time. When this happens, DNS must be updated immediately for the ENUM-based call routing to be able to successfully route calls to the CPE.

• NET-SNMP-This open-source SNMP package runs as an agent on the servers and implements several MIBs.
Thank you Cisco for letting us know so openly ;) and congrats to OpenSER people for providing such quality product.

Links;
The OpenSER mail archive entry and discussion


OpenSER gets CISCOs vote of confidence

Cisco Service Node for Linksys One SN-10 and SN-100 Data Sheet

Published on March 11th, 2007 under , , , , , , , , , , ,

OpenSER v1.1.1 is out and Available in Binary

Source: snapvoip.blogspot.com

VoIP IP Telephony @ http://snapvoip.blogspot.com

This release includes all fixes and corrections made to OpenSER since July 2006. The configuration file and database structure are fully compatible with v1.1.0, this release being a new packaging of CVS branch rel_1_1_0. It is recommended to update any v1.1.0 to v1.1.1.

The sources, binaries and packages for different OS distributions and architectures can be downloaded from:
http://openser.org/pub/openser/1.1.1/

The binary packages will be uploaded as soon as they are submitted by public contributors. You will find OpenSER packages in several Linux distributions packages for SUSE, Fedora and Mandriva and more are available in a RPM repository.
Click here for the link to the repository.
OpenSER 1.1.1 is now available in binary format for several embedded platforms, courtesy of Ovidiu Sas:
- Linksys NSLU
- Synology DS-101(g+)
- Iomega NAS 100d
- Freecom FSG-3
- Qnap TurboStation
And all routers supported by the oleg or dd-wrt distributions. Check out http://www.nslu2-linux.org for yours.

Published on February 16th, 2007 under , ,

OpenSER, what was 2006 and new goals in 2007, OpenSER 1.2.0

Source: snapvoip.blogspot.com

It was a year full of achievements and events for OpenSER in 2006. The release in summer (OpenSER 1.1.0), and a continuous increase in features set, development and robustness of OpenSER. What was new in 1.1.0 could be read in the link given below.
Since then the Development community has expanded features and capabilities of the OpenSER and intend to release a new version, very soon.
Some of the intended features for the next version, OpenSER 1.2.0 and the beginning of 2007 are;
- domainpolicy - policies to connect federations
- imc - instant messaging conferencing
- mi_fifo and mi_xmlrpc - FIFO and XMLRPC transports for the new management interface (MI)
- perl - embed perl programming in configuration file
- presence - SIMPLE Presence Server implementation
- pua, pua_mi, pua_usrloc - presence user agent client implementations for user location records and management interface
- seas - connector to SIP Application Server - WeSIP - Java SIP Servlet Application Server (http://www.wesip.eu)
- snmpstats - SNMP (Simple Network Management Interface) interface to OpenSER statistics
- sst - SIP session timer support
- xmpp - transparent SIP-XMPP gateway

Read more about these in documentation section for OpenSER 1.2.0 in the link given below.

I am looking forward to see OpenSER opening more doors in VoIP IP Telephony and SIP technology in 2007

Links;
What was new in OpenSER 1.1.0
OpenSER 1.2.0 documentation

Published on January 2nd, 2007 under , , , , , , , , , ,

OpenSER all the features, upto version OpenSER version 1.1.0.

Source: snapvoip.blogspot.com

Due to conversations and controversies due to my thoughts on SER vs OpenSER comparison, I decided to bring forth the information on both the systems as told by the creators or organizations them selves. The first of two posts will focus on OpenSER and all the information comes from OpenSER site only. I have not even included mailing lists or external support sites like voip-info.org. I have given links at the end so you can do your own research. From here on, no my words until links!

What OpenSer is;
OpenSER can be:

* SIP proxy server
* SIP registrar server
* SIP location server
* SIP application server
* SIP dispatcher server

OpenSER cannot be:

* SIP phone
* media server
* back-to-back user agent

The OpenSER features;
Some of the features that OpenSER brings:

* robust and performant SIP (RFC3261) Registrar server, Location server, Proxy server and Redirect server
* small footprint - the binary file is small size, functionality can be stripped/added via modules
* plug&play module interface - ability to add new extensions, without touching the core, therefore assuring a great stability of core components
* stateless and transactional statefull SIP Proxy processing
* support for UDP/TCP/TLS transport layers
* IPv4 and IPv6
* support for SRV and NAPTR DNS
* multi-homed (mhomed) and multi-domain support
* scripting language for configurations file. With a syntax similar to sripting languages, the configuration offers a powerful and flexible way to deploy custom SIP services.
* management interface via FIFO file and unix sockets
* pseudo-variables to access and manage parts of the SIP messages and attributes specific to users and server
* authentication, authorization and accounting (AAA) via database (MySQL, Postgress, text files), RADIUS and DIAMETER
* digest and IP authentication
* CPL - Call Processing Language (RFC3880)
* NAT traversal support for SIP and RTP traffic
* ENUM support
* load balancing with failover
* least cost routing
* support for replication - REGISTER offer new functions for replicating client information (real source and received socket).
* logging capabilities - can log custom messages including any header or pseudo-variable and parts of SIP message structure.
* modular architecture - plug-and-play module interface to extend the server’s functionality
* gateway to sms or xmpp
* multiple database backends - MySQL, PostgreSQL, flat files and other database types which have unixodbc drivers
* straightforward interconnection with PSTN gateways
* impressive extension repository - over 50 modules are included in OpenSER repository

Scalability:

* OpenSER can run on embedded systems, with limited resources - the performances can be up to hundreds of call setups per second
* used a load balancer in stateless mode, OpenSER can handle over 5000 call setups per second
* on systems with 4GB memory, OpenSER can serve a population over 300 000 online subscribers
* system can easily scale by adding more OpenSER servers
* OpenSER can be used in geographic distributed VoIP platforms
* straightforward failover and redundancy

New in OpenSER modules OpenSER v1.1.0

* acc module
1. direction detection implemented it generate consistent logs disregarding if the BYE is generated by caller or callee.
2. enhancent accounting for missed calls by controlling thelogging at branch and call level.
3. more accurate per branch logging - winning branch (instead of last one) is accounted at call level.
4. radius acc requests include an event time stamp (Event-Timestamp Radius AVP - see RFC2869). The Radius server timpstamp is not reliable since itcontains also the delays due possible RADIUS retransmissions.

* avpops

1. avp_db_query() - new function that allows to do raw sql queries and store the result in AVPs - performance can be increased by reducing the number of accesses to database.
2. parameters format is same as for pseudo-variables - an AVP parameter is referred now via "$avp(type:name)" instead of old format "type:name" (e.g., old "i:11" must be now written "$avp(i:11)") - this brings coherence with pseudo-variables and avoids confusion between int/string values and AVP names

* cpl-c
1. NAT traversal support (via received) for the lookup CPL node.
2. added per branch nat flags support for lookup CPL node.
3. multi domain support added.

* dispatcher

1. dispatcher has failover support - when failover is enabled, selected destination is added as dst_uri or domain part of r-uri and the rest of addresses in destination setare added in AVP list.

* enum
1. new functions (or new vresions of them): enum_fquery(), is_from_user_e164(), is_from_user_enum()
* group
1. regular expression based group matching added

* lcr
1. optional group id parameter is accepted by load_gws(), from_gw(), and to_gw() functions.
2. DB caching support adde.
3. new FROM regexp matching.
4. dynamic strip URI before forward.

* nathelper
1. IPv6 compliant.
2. prope handling of multiple stream handling in sequential requests.
3. support for changing session-level SDP connection (c=) IP when media-description also includes connection information.
4. fix_nated_sdp() may take one more param to force a specific IP instead of the signalling IP.
5. force_rtp_proxy() accepts a new flag ’s’ to swap creation/confirmation between requests/replies (this is needed to be able to cope with SDPs advertised via 200OK / ACK)
6. add_rcv_param() may take as parameter a flag telling if the parameter should go to the contact URI or contact header; make sense if you forward REGISTER requests and need the registrar to save the parameter as part of URI.

* pdt
1. multi-domain support added

* permissions
1. added "none" protocol option that never matches and thus disables the peer

* registrar
1. module may set for TCP connection a custom lifetime for keeping it open as long as the registered contact is valid
2. Path support according to RFC 3327 - support in registrar for loadbalancing using Path-HF with NAT-Support applied
3. request with failed checks are negativly replied with err headers for hints
4. method filtering performed by lookup()

* rr
1. obsolete function strict_route() removed
2. add_rr_param may be called from BRANCH and FAILURE route
3. record_route() may take a parameter containing RR params
4. "lr" param is added as first param to speed up the loose_routing processing
5. record_route / add_rr_param / record_route_preset accept pseudo-variables in params
6. extra checking to void double record routing via record_route and record_route_preset
7. callbacks are executed after all routing changes were done - this allows the usage of callback that may change the routing info without overlappingwith the RR processing.
8. add_username alters also the behaviour of record_route_preset()

* sl
1. callbacks added - the only event is sending a stateless reply
2. statistics support added

* textops
1. new function has_body([mime])
2. new set of function to work on the body of the message: search_body(), search_append_body(), replace_body(), replace_body_all(), subst_body()
3. function is_method() can be called from BRANCH_ROUTE.

* tm
1. fixed branch picking algorithm - if cancelled, but not 487 replied received, fallback and use classical algorithm.
2. fixed in building ACKs for negative replies to local INVITEs. RURI must be the same as in INVITE and Route hdr have no send to be added

3. branch selection algorithm centralized in a single place - more coherent and easier to maintain.
o the selected branch in stored in a static variable to avoid multiple computation for same transaction (so far, each t_check_status() call was triggering computation of the selected branch)
o TM API exports a new function for making public the selected branch (how the winning branch is selected must be transparent for the other modules)
o fixed the branch selection algorithm - if the transaction was cancelled, the "487 Request cancelled" reply will have priority and it will be sent to UAC

4. t_replicate() takes as parameter a SIP URI instead of a destination (in order to align the format as for append_branch()). Also t_replicate() uses the set branches to perform parallel replication to multiple destinations.
5. new TM callbacks added:
o TMCB_TRANS_DELETED - called when the transaction is deleted ;
o TMCB_REQUEST_BUILT - called just before sending out a request.
6. "pass_provisional_replies" TM options (pass back through unixsock the provisional replies and not only the final one).
This was required in order to maintain compatbility with latest SEMS version.
7. module exports $T_branch_idx pseudo-variable refering to the index of the branch for which the branch_route[] is executed
8. advanced TM monitoring
9. t_relay*() returns 1 instead of 0 when forwarding ACK
10. relay functions merging:
o t_relay_to_udp(), t_relay_to_tcp(), t_relay_to_tls() merged into t_relay(proto:host:port)
o t_forward_nonack_uri(), t_forward_nonack_udp(), t_forward_nonack_tcp(),
o t_forward_nonack_tls() merged into t_forward_nonack(proto:host:port) and t_forward_nonack()
o t_replicate_udp(), t_replicate_tcp(), t_replicate_tls() merged into t_replicate(sip_uri)

* uac
1. default value for "from_restore_mode" switch to auto
2. new module parameter "from_passwd" - used to encrypt the RR parameter which contains the original FROM URI
3. uac_replace_from() adds the display name if not present (so far it only replaced it); uri is enclosed between brackets if not. Actually, now you can set a display name if none was present.
4. when performing UAC authentication, look in predefined AVPs for credentials before using the static set credentials (via modparam)

* uri_db
1. "db_url" module parameter may be set to empty string in orer to disable DB support in the module - this is needed if you want to use check_to() or check_from() to check the user against credentials in a non DBenvironment.

* usrloc
1. module is able to detect retransmissions based on Callid and Cseq. The retransmission detecton is controled via the new "cseq_delay" module parameter. REGISTER retransmissions (inside the cseq_delay interval) will not generate error, but they will be accepted and properly replied without any update on the location status. This solves the problem of retransmissions without having a statefullprocessing on requests.
2. advanced monitoring via statistics; module export dynamic statistic for each register domain (as location or aliases). Available statistics: number of registered users (AORs);number of registered contacts (>= AORs); number of expired contacts
3. get_contacts fifo and unixsock functions retunrn more additional info related to the contact: expires;flags;socket;methods;received?;user_agent?;path?. Values marked with ? may be missing if empty.
4. usrloc: new DB mode - DB-Only - no memory cache is kept, all operation being directly done into DB. Allows DB sharing between multiple proxies without the need of additional replication mechanism. Drawbacks:
o some performance penalties due intensive DB usage
o location watcher disabled (cannot be bind to a record into mem) => PA cannot be used
o statistics do not work since events cannot be properly been traced without a mem cache
5. contact maching algorithm aligned to the RFC 3261 specs (added extra checking based on callid and cseq)
6. configurable multi-algorithm for contact matching:
o contact only based (as in RFC)
o contac and callid based
7. supported methods are saved into usrloc
8. saved socket info contains now also the protocol. The socket is saved as: proto:ip:port

Links;
OpenSER.ORG
OpenSER.org public user forum
VOIP-INFO.ORG OpenSER page.

SER vs OpenSER, there is a differnce, I was wrong

Source: snapvoip.blogspot.com

My previous article "SER vs OpenSER, There is no real Comparison" is little out of touch. Even though I wrote the article I still partial to SER. Look at the links on the right side, "My favorite SIP Router" it has been the same since I started this blog. What drove me to write the article was the same reason that OpenSER came to be. Corporate or political bickering’s, and nonoperational home site, (one day it was up and next day it was down) so much so I stopped even trying to visit iptel.org site. I did visit Berlios developer site. That is the time I discovered OpenSER. What do you expect? it was a source of encouragement for me. I started immediately to work on OpenSER. I will continue to do so until SER assures me that it will not play the old tricks. I still have both the tracks and have deployed SER and OpenSER for many of my clients. I am also a very good fan of Asterisk and TrixBox (formerly Asterisk@home) and there are instances that I needed Both SER and Asterisk to find a solution for certain clients.
VOIP IP Telephony is very much more than what you see in the press. I have Academic, and corporate deployments that you will not read about in the press. Some of the deployments I have hit the ceiling on most of the OSS software but was able to overcome by using other OSS solutions like clustering to solve my problems. Although I like to code, due to the nature of my work and academia, I spend more time in design and deployment. So I let the others do the coding. That is why I rely on SER, Asterisk and the likes so much. One thing is for sure. Unless client insists, all my designs are OSS based. And it stand close to 90% OSS now.
But as time went by, things started to change at SER. New and better management, a new and certainly better IPTEL.ORG site and has come a long way. I do still work on SER and I did write about New SER.

All this said, SER is still a better solution than OpenSER. But for that information, please wait for the Soon to be written "Technical Diffrences between SER and OpenSER"

Links; as they were published on my site;
VOIP IP Telephony: What’s new in SER 0.10.x ? A lot and…

VOIP IP Telephony: SER gets a new home, Migrating to Drupal.

VOIP IP Telephony: SIP Express Media Server, SEMS, design documentation released by IPTEL.ORG

The article relating to SER vs OpenSER
VOIP IP Telephony: Ser VS OpenSER, There is no real comparison!

Ser at IPTEL.ORG
OpenSER Site

Published on December 1st, 2006 under , , , , , , ,

Member of "Hype Media! Network"