Các ứng dụng mã nguồn mở tốt nhất năm 2013

Từ các máy chủ phục vụ cho dạng tài chính cá nhân và các doanh nghiệp nhỏ để tích hợp các lưu trữ ERP với hàng ngàn module phục vụ cho mọi nhu cầu, chúng tôi đã chọn lựa tương đối tốt nhất và tích cực nhất các dự án ứng dụng mã nguồn mở trên thế giới đã đưa ra. Hãy nhớ rằng khi tải về một thiết bị ảo đó là cách dễ nhất để bắt đầu? Ngày càng có nhiều công ty đứng sau các dự án mà đang làm cho nó dễ dàng hơn với các tùy chọn SaaS(Software as a service). Các dự án ứng dụng khác được làm nóng hơn qua điện thoại di động, áp dụng các khuôn nền JavaScript thân thiện để tạo ra các tương tác đầu cuối linh hoạt hơn.

Nginx Apache HTTP Server, uyển chuyển hơn. Trong khoảng thời gian trong vòng 02 năm, Nginx đã vươn lên trở thành một trong những máy chủ web được sử dụng rộng rãi nhất. Nó không khó để hiểu tại sao. Nginx mang lại hiệu năng tuyệt vời - nhờ một kiến ​​trúc hướng sự kiện mà tiêu thụ rất ít bộ nhớ theo yêu cầu. Khả năng đồng thời xử lý hàng ngàn yêu cầu mà không bị nghẽn đã làm cho nó trở thành một thành phần quan trọng trong nhiều ngăn xếp Web chính, từ các web Netflix và Pinterest cho đến các web Heroku và WordPress.com. Một máy chủ siêu nhanh của các trang web tĩnh và một proxy hiệu quả cao dành cho Apache và các dịch vụ khác, Nginx đã trở thành chìa khóa để giải phóng cho nhiều trang web bị nghẽn băng thông nặng nề trong buôn bán cần hiệu suất cao. -- Serdar Yegulalp

Varnish Đôi khi những thứ tốt nhất là những thứ khiêm tốn và khiêm nhường nhất. Các ngăn xếp giống như Apache HTTP Server, Nginx, và Node.js có thể được cung cấp nguồn lực ngày càng nhiều cho các trang web, nhưng chúng ta không bỏ qua những giúp đỡ vô hình của chúng. Varnish là một HTTP bộ nhớ đệm và proxy tăng tốc, được thiết kế để làm một việc và làm tốt: làm cho các trang web tải nhanh hơn. Những người sáng tạo tự hào đã gia tăng từ 300 đến 1.000 lần ở bất cứ nơi nào, "tùy thuộc vào kiến trúc của bạn." Varnish đi kèm với ngôn ngữ cấu hình riêng của mình để cho phép tinh chỉnh cho nhu cầu của bạn, các module add-on để bắt tay với tất cả mọi thứ từ xác thực để đảm bảo tải xuống, và việc cấp giấy phép vô cùng tự do. -- Serdar Yegulalp

MariaDB MariaDB hoạt động như một "mặc nhiên thay thế" nhị phân tương thích cho MySQL. Cơ sở dữ liệu được tạo ra trong MySQL có thể được sử dụng minh bạch trong MariaDB. Phiên bản sắp tới của 10,0 MariaDB bản chuyển ngược một số thay đổi từ MySQL 5.6 và thêm các tính năng độc đáo đối với MariaDB, chẳng hạn như công cụ lưu trữ Cassandra mới (để truy cập vào các cụm Cassandra). Hơn nữa, dự án được kiểm soát bởi một nền tảng nhằm mục đích để giữ MariaDB độc lập đối với sự kiểm soát của công ty - một bảo vệ chống lại khả năng lịch sử lặp lại lần lượt khi dự án MySQL đã được thực hiện theo Oracle. -- Serdar Yegulalp

WordPress Phổ biến rãi nhất trên thế giới sử dụng rộng nền tảng blog chiếm một tỷ lệ phần trăm không nhỏ so với các trang web - không chỉ các blog, các trang web. Bổ sung vào việc viết blog, WordPress hỗ trợ các bảng tin và các mạng xã hội nhỏ, nhờ vào cộng đồng người dùng đã viết một phạm vi lớn các chủ đề của bên thứ ba và phần mở rộng chức năng cho nó. Một vài gói phần mềm của phạm vi này làm cho nó dễ dàng nổi trội và vận hành, và nằm trên đầu của các bản cập nhật và mọi thứ khác với tương đối ít đổ công sức. Lưu ý rằng bạn cần phải chọn chủ đề của bạn và các plug-in một cách khôn ngoan, và cấu hình mặc định không phải luôn luôn là tốt nhất, đặc biệt là nếu bạn đang sử dụng ở mức độ an toàn thấp hoặc chia sẻ lưu trữ. -- Serdar Yegulalp

Alfresco Vẫn là nền tảng quản lý nội dung mã nguồn mở chỉ để chinh phục toàn bộ vòng đời nội dung, Alfresco ấn tượng hơn nữa trong năm nay với việc pha trộn mới cho nội dung trên tiền đề dựa trên điện toán đám mây. Sự cởi mở của nền tảng là xuất sắc, nhờ hỗ trợ cho các tiêu chuẩn giống như CMIS (dịch vụ quản lý nội dung khả năng cộng tác) cũng như REST. Kết nối với các hệ thống đối tác nổi tiếng như SharePoint, Google Drive, SugarCRM, và Salesforce.com (và nhiều hơn nữa) mang lại giao dịch phong phú và các khả năng định tuyến để quản lý tài liệu truyền thống. Hỗ trợ cho nhân viên làm việc di động cũng như liền mạch với một SDK hỗ trợ tốt. -- James R. Borck

SugarCRM Mì ống tròn PHP yêu thích của chúng tôi đóng gói trong SFA, các chiến dịch tiếp thị, hỗ trợ khách hàng, hợp tác, CRM di động, CRM xã hội, và báo cáo thành một hệ thống phần mềm thống nhất. SugarCRM cho phép các công ty theo dõi khách hàng của họ và định hướng quy trình kinh doanh hiệu quả hơn. Năm nay các cải tiến hàng đầu bao gồm một bảng điều khiển tuyệt vời, các khả năng tìm kiếm toàn văn bản, và hiệu suất mạnh mẽ hơn. -- Michael Scarlett

Vtiger Vtiger tiếp tục gây ấn tượng. Phiên bản ổn định hiện nay, 5.4, đã trưởng thành và nổi bật trong các lĩnh vực dịch vụ sau bán hàng của khách hàng, hỗ trợ (với việc mở cấp phát xử lý các vấn đề và module Trợ giúp - FAQ), cổng thông tin khách hàng, và xử lý mail dựa trên quy tắc. Dự án bắt đầu như là một nhánh của SugarCRM, và nó đã phát triển khác một chút theo một hướng khác. Toàn bộ codebase vừa miễn phí và là mã nguồn mở. Dự án bao gồm tất cả các khả năng CRM tiêu chuẩn và nhiều tính năng khác, bao gồm bán hàng, đơn đặt hàng, hóa đơn, theo dõi tài sản, tin nhắn SMS thông báo, quản lý tổng đài, và quy trình công việc, v.v.. Cộng đồng lớn và đang hoạt động, và wiki là toàn diện. Một phiên bản lưu trữ không tốn kém cho phép bạn lựa chọn giữa giao diện cũ và mới. -- Fred Blauer

Magento Magento thì đang dẫn đầu, giải pháp mã nguồn mở có gốc tốt nhất cho thương mại điện tử dạng B2C, và nó thậm chí còn có một số khả năng B2B. Công ty đằng sau phần mềm thuộc sở hữu của eBay, và bản thân dự án có cộng đồng lớn và thị phần nhất. Có ba phiên bản: phiên bản miễn phí và phiên bản cộng đồng mã nguồn mở, một phiên bản SaaS dựa trên đăng ký được gọi là Magento Go, và phiên bản doanh nghiệp được cấp giấy phép thương mại được đóng gói với các tính năng cao cấp. Hệ thống Magento thì mạnh mẽ, hoạt động tốt, và nhiều tiện ích và nhiều phần mở rộng (chẳng hạn như kết nối với các hệ thống ERP, thanh toán trực tuyến, và các hệ thống vận chuyển) có sẵn thông qua thị trường Magento Connect. Thật khó có thể đi sai với dự án đã được chứng minh và được hỗ trợ quá tốt này. -- Fred Blauer

Feng Office Feng Office là một dự án trước đây gọi là Open Goo. Bây giờ, trớ trêu thay, nó giúp để năng suất lao động tăng cao với các công cụ của một bộ quản lý dự án và hợp tác tốt dựa trên trình duyệt. Cho dù trên trang web (Apache / PHP / MySQL) hoặc tại tổ chức (Feng Sky), phần mềm cho phép bạn sáng tạo các không gian làm việc dự án dọc theo các đường tổ chức hoặc cho các dự án cụ thể. Feng Office cung cấp một bộ tính năng vững chắc bao gồm chia sẻ tài liệu, lịch, quản lý công việc, danh bạ và email. Theo dõi vấn đề và sự quản lý nguồn tài nguyên bị trì trệ bên cạnh các công cụ thương mại như Clarizen, và nó có thể sử dụng một ứng dụng di động giống như của Basecamp. Nhưng khả năng sử dụng tốt và quản lý dễ dàng làm cho Feng Office trở thành một giải pháp mà bạn có thể xây dựng. -- James R. Borck

ProjectLibre ProjectLibre là một giải pháp quản lý dự án dựa trên Java cung cấp cho Microsoft Project vận hành cho dự án của họ. Cung cấp một giao diện người dùng giống nhau đủ để dễ dàng chuyển đổi sang thị trường đang dẫn đầu của Microsoft, các gói ProjectLibre trong lịch, theo dõi tài nguyên, quản lý công việc, và các công cụ theo dõi-chi phí. ProjectLibre sản xuất cùng thanh biểu đồ quen thuộc và bảng xếp hạng phương pháp định hướng-quan trọng mà các nhà quản lý dự án dựa vào, và các tập tin dự án của chương trình có thể hoán đổi với Microsoft Project. Nó thì chưa phù hợp với quản lý đa dự án vì sự hỗ trợ cho các tiểu dự án và tổng hợp tài nguyên còn thiếu. Nhưng điều này có thể sớm thay đổi. Điện toán đám mây và phiên bản máy chủ mới trong cùng các mục tiêu. -- James R. Borck

GnuCash GnuCash vẫn là ứng dụng mã nguồn mở miễn phí phổ biến nhất trong các loại tài chính cá nhân. Hệ thống sẽ chạy trên Windows, Mac, hoặc Linux, nhưng nó không được thiết kế cho điện toán đám mây hoặc điện thoại di động và thường được cài đặt và vận hành nội bộ. Dự án đã phát hành một vài cải tiến gia tăng trong năm qua. GnuCash có các tính năng đối chiếu ngân hàng tốt, và nó có thể nhập các giao dịch ngân hàng vào. Nó cũng bao gồm các khả năng theo dõi đầu tư. Mặc dù hệ thống có thể hỗ trợ nhiều người dùng trong một doanh nghiệp rất nhỏ, bạn sẽ phải tìm ở nơi khác nếu bạn có yêu cầu kế toán hoặc các yêu cầu ERP như kiểm soát hàng tồn kho, đơn hàng, thu mua, và theo dõi dự án hoặc theo thời gian. -- Fred Blauer

FrontAccounting FrontAccounting từng bước cải thiện và trưởng thành. Năm qua đã không mang lại bất kỳ thay đổi mang tính cách mạng, nhưng phiên bản hiện tại (2.3.18) hoạt động tốt, và vẫn là một thích hợp cho một công ty nhỏ với nhu cầu khiêm tốn. Hệ thống được xây dựng trên một khung nền PHP với cơ sở dữ liệu MySQL, và rất dễ dàng để sử dụng. Không có tùy chọn lưu trữ có sẵn, do đó bạn phải chạy nó nội bộ hoặc sử dụng một trong những đối tác thương mại nếu bạn muốn triển khai trong điện toán đám mây. Các tích hợp với thương mại điện tử và các ứng dụng CRM có sẵn thông qua các đối tác thương mại. -- Fred Blauer

OrangeHRM Được xây dựng với PHP và triển khai trên một ngăn xếp LAMP (Linux, Apache, MySQL, PHP), OrangeHRM là tương đối dễ dàng để cài đặt và có một số tài liệu hướng dẫn và video minh họa tốt. Chưa có nhiều hoạt động hoặc thay đổi lớn với dự án OrangeHRM trong năm qua; Tuy nhiên, phiên bản 3 cải thiện giao diện người dùng và thêm hỗ trợ tốt hơn cho việc truy cập điện thoại di động, và tích hợp mới với xTuple ERP và kế toán là trong các công trình. Phiên bản cộng đồng của OrangeHRM bao gồm các yếu tố cần thiết từ việc theo dõi ứng viên cho đến quản lý hiệu quả, trong khi các chức năng cao cấp hơn có sẵn thông qua các module add-on và trong phiên bản trực tuyến dựa trên điện toán đám mây. -- Fred Blauer

ERPNext ERPNext là một người mới trong thế giới của tích hợp, mã nguồn mở ERP. Dự án Ấn Độ dựa này nhắm tới mục tiêu các công ty nhỏ hơn nhưng đang quản lý để đóng gói rất nhiều tính năng trong khi vẫn duy trì tương đối để sử dụng và cấu hình dễ dàng. Được xây dựng với Python và JavaScript, ERPNext hoàn toàn dựa trên web và khá toàn diện, gần đây tích hợp thêm một trang web và giỏ mua hàng để bán hàng trực tuyến. Một phiên bản lưu trữ trên phiên bản máy chủ rẻ tiền cũng có sẵn. ERPNext có một diễn đàn thảo luận tốt trên Google Groups, cộng đồng đang phát triển, công ty gần đây đã giới thiệu một chương trình đối tác mới, và các nhóm nòng cốt đưa bài thuyết trình hàng tháng để cập nhật với cộng đồng về các tin tức và chiến lược. Dự án này có một tương lai tươi sáng. -- Fred Blauer

xTuple Dự án xTuple tiếp tục phát triển và đổi mới. Phiên bản cộng đồng mã nguồn mở miễn phí, được gọi là xTuple PostBooks, khá toàn diện và phù hợp với nhiều doanh nghiệp nhỏ. Các phiên bản thương mại mã nguồn mở đưa thêm các chức năng cao cấp cho các nhà sản xuất và nhà phân phối. Các tiện ích bên thứ ba và phần mở rộng có sẵn thông qua cửa hàng ứng dụng của xTuple. Dự án hiện đang giảm dần trong một nền tảng máy khách di động và web, mà chạy đồng thời với Qt GUI client. Dựa trên Enyo, điện thoại di động / Web client sẽ sớm có mặt trên các module CRM, được theo sát bởi các nhân viên bán hàng. Công ty cũng đã công bố tích hợp với OrangeHRM. -- Fred Blauer

Openbravo Hệ thống ERP Openbravo được hỗ trợ bởi các nhà tài trợ thương mại cùng tên. Có một phiên bản mới cho các môi trường cộng tác và các khởi động chia sẻ tài nguyên. Hệ thống quản lý chuỗi bán hàng mới, dựa trên khung Enyo JavaScript, được thiết kế để làm việc trên các thiết bị di động và màn hình cảm ứng. Cách bố trí của màn hình sẽ tự động điều chỉnh và phù hợp với bất kỳ thiết bị khách hàng nào- PC, máy tính bảng, hoặc điện thoại thông minh. Bạn sẽ tìm thấy nhiều phần mở rộng của bên thứ ba có sẵn cho Openbravo, và cộng đồng là khá tích cực. Có tích hợp với một số dự án mã nguồn mở hàng đầu, bao gồm SugarCRM, Magento, và Alfresco. -- Fred Blauer

uniCenta oPOS Openbravo POS là một phần mềm mã nguồn mở phổ biến, để chạy point-of-sale các thiết bị như các máy tính tiền hoặc các máy tính kiểm tra. Các dự án Openbravo POS bị đình trệ trong năm 2011, nhưng mã nguồn mở tồn tại trong một ngã ba rất mạnh mẽ và đẹp mắt, uniCenta oPOS . Các nguồn nhân lực phía sau dự án mới đã vực dậy nó lên với một cái nhìn mới (cùng với 38 giao diện khác nhau), cung cấp hỗ trợ thương mại cho các khách hàng cần nó, và phát hành mã nguồn như GPLv3 để ngăn chặn nó được bán lại như một dịch vụ. Tất cả mọi thứ từ thuế bán hàng tự động cho đến đến quản lý hàng tồn kho, tích hợp quy mô và kiểm soát nhân viên cũng được hỗ trợ. -- Serdar Yegulalp

OpenERP OpenERP là một ứng dụng Web dựa trên Python - mã nguồn mở hoàn toàn, với các phiên bản thương mại cung cấp các vá lỗi, di cư đến các phiên bản mới, và một tùy chọn lưu trữ. OpenERP 7 là một nâng cấp lớn mà đại tu các giao diện người dùng, mà không còn đòi hỏi các cài đặt người dùng đầu cuối, chỉ dùng một trình duyệt Web. OpenERP được nạp với các tính năng và các mô-đun (nhiều hơn 3.000 mà có thể đếm); rất nhiều tiện ích bên thứ ba có sẵn, và hệ thống này là tương đối dễ dàng để tùy chỉnh. Dự án có nguồn gốc ở châu Âu, nhưng đã có tiến bộ đáng kể ở Bắc Mỹ trong năm qua. Cộng đồng lớn và năng động, với nhiều đối tác giá trị gia tăng ở hầu hết các khu vực trên thế giới. -- Fred Blauer

OpenEMR OpenEMR là một EHR (hồ sơ y tế điện tử) - và nền tảng hồ sơ y tế điện tử tuân thủ theo HIPAA (lập kế hoạch, thanh toán, và báo cáo) và cổng thông tin bệnh nhân. Lặp lại chiến thắng này gần đây đã thêm phần quản lý tốt hơn của các kết quả phòng thí nghiệm, công cụ ghi chống trùng lắp cần thiết, và mã hóa giao hàng điện tử của các hồ sơ y tế để hỗ trợ các dự án trực tiếp mới (một phần của hệ thống Mạng thông tin Y tế toàn quốc). OpenEMR chạy trên Windows và Linux, và nó có sẵn trong một XAMPP cài đặt sẵn gói(X, Apache, MySQL, PHP, Perl) hoặc thiết bị VMware, hạ thấp thanh bar để bắt đầu. Dự án có một cộng đồng năng động và một số tùy chọn hỗ trợ của bên thứ ba. Trả một ai đó để làm đẹp lên giao diện và bạn có một bộ EMR rất tùy chỉnh phù hợp cho hầu hết các cơ sở y tế nhỏ. -- James R. Borck

Pentaho BI Suite Pentaho là công cụ BI của sự lựa chọn cho nhiều tích hợp hệ thống ERP mã nguồn mở lớn hơn bao gồm OpenERP, xTuple, và Openbravo. Một kinh doanh thông minh và nền tảng tích hợp dữ liệu mạnh mẽ mà đã chứng tỏ trong các tổ chức lớn, Pentaho cung cấp báo cáo và các công cụ tích hợp cơ bản trong một ấn bản cộng đồng miễn phí. Nó đóng gói nhiều tính năng tinh vi hơn - bao gồm các bảng điều khiển, báo cáo tương tác, trực quan dữ liệu, và các khách hàng điện thoại di động - vào các phiên bản chuyên nghiệp và doanh nghiệp. Phiên bản mới nhất 4.8 thêm các tính năng phân tích dữ liệu lớn, mà đang trở thành phổ biến hơn khi các công ty thu thập ngày càng nhiều dữ liệu từ các nguồn trong và bên ngoài. -- Fred Blauer

Colosa ProcessMaker Cho các doanh nghiệp nhỏ và các dự án của phòng ban, Colosa ProcessMaker có thể là lựa chọn thông minh cho quy trình làm việc dựa trên chứng nhận. Phiên bản 2.5 phát hành năm nay mang lại tuỳ biến WYSIWYG dễ dàng hơn của các mẫu và báo cáo. Xác nhận cú pháp mới cho các mẫu ngăn cản XML cơ bản của bạn từ sự rối tung - một nỗi đau để khắc phục sự cố trong quá khứ. ProcessMaker thiếu khả năng giám sát và tối ưu hóa quá trình mở rộng, cũng không cung cấp công cụ cho BPMN 2.0 (mô hình và ký hiệu quá trình kinh doanh) mô hình, xác nhận quá trình, hoặc gỡ lỗi. Nhưng ngăn xếp LAMP/PHP (Linux, Apache, MySQL, PHP) này rất dễ dàng để bắt đầu. Ngoài các phiên bản cộng đồng, các ProcessMaker có sẵn trong các phiên bản đám mây lưu trữ và doanh nghiệp, trong đó có một phiên bản mà cài đặt giống như là một module SugarCRM. -- James R. Borck

Activiti Activiti là một dự án độc lập được tài trợ bởi Alfresco và SpringSource bộ phận của Pivotal. Việc thi hành có nguồn gốc BPMN 2.0 (mô hình và ký hiệu quá trình kinh doanh) và một giấy phép Apache tự do, Activiti đưa ra như là một công cụ BPM "như tờ giấy trắng" trong năm 2010. Được dẫn dắt bởi các nhà phát triển cũ của Red Hat chịu trách nhiệm về jBPM, bộ máy được khởi động lại quá trình này kết hợp nhiều tính năng được tìm thấy trong việc triển khai BPM thương mại và bao gồm các plug-in cho các cỗ máy mã nguồn mở như Liferay Portal, Mule ESB, và Spring. Hệ thống bao gồm một hình thức xây dựng mô hình cho công việc của con người, tích hợp LDAP, và một hàm API REST để đưa mọi thứ gần lại vào trong. -- Steven Nuñez

Bonita BPM Nhiều năm trong việc thực hiện, Bonita BPM 6 là đáng để chờ đợi. Phiên bản mới đưa ra một động cơ chạy nhanh hơn dựa trên dịch vụ theo thời gian và một API REST. Nó cũng tóm tắt các thông số cấu hình từ các ứng dụng cho việc triển khai bản cập nhật mà không cần khởi động lại. Một thiết kế lại kiểu dáng đẹp của cổng thông tin người sử dụng cải thiện khả năng tiếp cận và hỗn hợp trong điện thoại di động. Bonita BPM Studio vẫn khiến cho công việc dễ dàng chỉnh sửa các mẫu và mô hình hóa quá trình. Với phiên bản mới, dòng chảy song song hoạt động như mong đợi dưới thông số BPMN 2.0. Các tính năng cao cấp nhiều hơn như công việc phụ và quản lý lỗi yêu cầu phải đăng ký thương mại. Giám sát hoạt động và quản lý các quy tắc kinh doanh có thể mạnh mẽ hơn, nhưng các bản cập nhật mới nhất và một danh mục đầu tư vững chắc của các kết nối giúp cho Bonita là tốt nhất trong BPM mã nguồn mở. -- James R. Borck

Mule ESB Mule ESB đã trải qua một số thay đổi trong năm nay. Mule Studio bây giờ có sẵn như là một plug-in Eclipse và không còn đòi hỏi một thiết lập chuyên dụng. Các nhà phát triển sẽ thích bộ lọc DataSense mới nhiều hơn. Công cụ mới này sẽ xem xét một nguồn tài nguyên dữ liệu và các tùy chọn cấu hình mặc định với kiểu dữ liệu và cấu trúc thông tin thiết bị đầu cuối cụ thể - một cải tiến lớn đối với quá trình hệ thống dây điện. Mule cũng loại bỏ một nút cổ chai quan trọng đã ảnh hưởng hiệu suất bằng cách thêm hỗ trợ cho việc xử lý tập tin cùng lúc. Mule kết hợp một dấu vết nhẹ, khả năng mở rộng tốt, và một con đường phát triển dễ dàng. Nó thiếu các quy tắc kinh doanh và các công cụ quản lý quy trình cần thiết cho các dự án tích hợp tiên tiến hơn, nhưng nó tỏa sáng như một ESB độc lập hoặc để hỗ trợ cho các nền tảng phức tạp hơn đã được đặt ra. -- James R. Borck

SwitchYard Không phải tất cả dự án tích hợp đều đòi hỏi tin nhắn XA-đáng tin cậy hoặc các khả năng quản lý các quy định kinh doanh mạnh mẽ. Đối với những điều này, thế hệ tiếp ESB của Red Hat, SwitchYard , trở thành một sự lựa chọn tuyệt vời. SwitchYard đại diện cho một sắp xếp lại của thời gian chạy dịch vụ xe buýt truyền thống để đặt trọng tâm nơi mà nó thuộc về: vào ứng dụng. Bạn có thể gọi nó là "ESB plus." SwitchYard đã nhúng thiết bị đầu cuối dịch vụ - sự phối hợp, POJO (các đối tượng Java đơn giản cũ), quy trình công việc, và các thành phần định tuyến - trực tiếp trong ứng dụng của bạn. Thay vì sử dụng các cổng và lắng nghe, nó cho thấy các dịch vụ thông qua các ràng buộc hợp đồng. Tóm lại, SwitchYard giúp làm sạch mới từ kiến trúc truyền thống để làm cho kiến trúc hướng dịch vụ ngày càng tích hợp nhiều dịch vụ theo định hướng và ứng dụng nhanh hơn, đơn giản hơn, và linh hoạt hơn. -- James R. Borck

Service Stack Bắt đầu vào năm 2008 như là một sự thay thế bằng mã nguồn mở cho dịch vụ Windows Communication Foundation, tích hợp ngăn xếp .Net này hoàn thành xong, cũng được thiết kế và vận hành nhanh. Service Stack đơn giản để thêm vào một dự án thông qua NuGet, và các dịch vụ dễ dàng cho phép bạn sử dụng các đối tượng XML, JSON, hoặc SOAP. NoSQL, nhắn tin, nhật ký, tất cả các công việc thông suốt với nhau. Có một cộng đồng năng động, với nhiều người sử dụng trên StackOverflow để giải quyết vấn đề. Cuối cùng, dự án nhắm đến mục tiêu thiết kế để hỗ trợ Mono, vì vậy bạn có thể sử dụng dịch vụ của mình trên cả Windows và Unix. -- Steven Nuñez

Open edX Một mục đích phi lợi nhuận được thành lập bởi học tập trực tuyến Harvard và MIT, edX tạo ra một sự náo nhiệt bằng cách phát hành mã nguồn LMS dựa trên Python (hệ thống quản lý học tập) trong năm nay. Chạy trên Ubuntu Open edX kết hợp LMS, các công cụ triển khai và cấu hình, các mô-đun chương trình học, và một môi trường sáng tác được gọi là Studio. Một số tiện ích cung cấp cho một giao diện nhắn tin, các phân tích dựa trên JavaScript, và các đánh giá chấm điểm dựa trên máy học tập (một công việc trong tiến trình, để đảm bảo). Phần mềm này có sẵn cho các nhà phát triển tìm cách để đóng góp trở lại. Edx chưa được cung cấp dịch vụ hỗ trợ hoặc lưu trữ cho bất cứ ai ngoài các đối tác ký kết của Edx. -- James R. Borck

inBloom Hệ thống trường học ở Mỹ mua điểm của gói phần mềm, mỗi trong đó có đại diện riêng của mỗi học sinh và dữ liệu của họ. Tuy nhiên, các hệ thống trường học không có khả năng của một dự án tích hợp CNTT điểm - điểm cho kết hợp độc đáo về phần mềm. inBloom tạo ra một nền tảng chung cho phép các nhà cung cấp để viết đến một dữ liệu API. Mục đích là để không chỉ tránh chi phí tích hợp dữ liệu, mà còn để mở rộng thị trường cho phần mềm nhằm vào các hệ thống trường học K-12. inBloom là một hệ thống dựa trên tận dụng lại MongoDB, và duy trì kiểm soát địa phương của dữ liệu học sinh. Vài gói đầu tiên đã được phát hành trên GitHub và càng có nhiều hơn nữa. -- Andrew C. Oliver

BigBlueButton BigBlueButton là một hệ thống hội nghị Web mã nguồn mở miễn phí cho phép đa luồng âm thanh và video với bảng trắng được tích hợp, trò chuyện và chia sẻ máy tính để bàn. Nó phù hợp cho các học thuật, nhưng có khả năng hữu ích cho bất cứ ai. Máy chủ cài đặt trên Ubuntu (hướng dẫn chi tiết có sẵn), nhưng nó dễ dàng hơn để tải về và cài đặt các VMware ảnh. Hiệu suất khá tốt. Tôi có thể kết nối bốn người sử dụng đồng thời - tất cả các luồng video - với máy chủ BigBlueButton chạy trong một máy ảo trên máy tính xách tay icore7 2.33GHz với bộ nhớ 8GB mà không có bất kỳ vấn đề nào. Các khách hàng cần một trình duyệt hiện đại với phiên bản mới nhất của Flash. Một máy chủ demo trực tuyến có sẵn cho bạn và bạn bè của bạn để thử. -- Joseph Roth

TurnKey Linux TurnKey Linux là một dự án dành cho việc xây dựng miễn phí, dễ dàng cài đặt, sẵn sàng để chạy, các thiết bị phần mềm dựa trên Debian. Hiện nay có hơn 100 thiết bị - bao gồm Tomcat, LAMP, LAPP, MySQL, PostgreSQL, Django, Rails, Drupal, WordPress, và các máy chủ khác - có sẵn để tải về, cấu hình sẵn với một hệ điều hành nhẹ và đóng gói trong nhiều định dạng xây dựng và một Live CD cho phép cài đặt. Xây dựng có sẵn cho VMware, OVF, OpenStack, OpenVZ và Xen. Sau khi triển khai, các ứng dụng TurnKey nhận được cập nhật và bản vá lỗi bảo mật tự động. -- High Mobley

Tham khảo

• Các ứng dụng mã nguồn mở tốt nhất năm 2013
• Các công cụ phát triển ứng dụng mã nguồn mở tốt nhất năm 2013
• Phần mềm Dữ liệu Trung tâm (Data center) và Điện toán đám mây mã nguồn mở tốt nhất năm 2013
• Ứng dụng desktop và phần mềm trên di động mã nguồn mở tốt nhất năm 2013
• Phần mềm mạng và bảo mật mã nguồn mở tốt nhất năm 2013
• Các công cụ quản trị mã nguồn mở tốt nhất năm 2013
• Các công cụ dữ liệu lớn mã nguồn mở tốt nhất năm 2013

Nguồn tham khảo http://www.infoworld.com

Giao thức SIP, H323, MGCP, MEGACO là gì? - Tìm hiểu về SIP, H323, MGCP, MEGACO

Tìm hiểu giao thức SIP

SIP (Session Initiation Protocol) là một giao thức được sử dụng trong việc truyền thông đa phương tiện thông qua mạng IP. Cung cấp một khuôn khổ để thiết lập voice, video truyền theo kiểu point-to-point, hội nghị và thông điệp kiểu văn bản.

Đây là một chuẩn của IETF để thiết lập các kết nối VoIP. Nó là một giao thức điều khiển lớp ứng dụng để tạo mới, chỉnh sửa và kết thúc các session. Cấu trúc của SIP giống như HTTP(client-server protocol). Các Request được tạo ra bởi các máy Client và gửi tới Server. Server xử lý các Request và gửi một Response lại cho Client. Một Request và Response là một yêu cầu để tạo ra một tương tác qua lại. SIP cũng có các thông điệp INVITE và ACK. SIP tạo ra sự giả định nhỏ nhất về cơ bản của giao thức truyền tải. Giao thức này chính nó cung cấp độ tin cậy và nó không phụ thuộc vào độ tin cậy của TCP. SIP phụ thuộc vào Session Description Protocol (SDP) trong việc mang ra ngoài các thỏa thuận để xác minh codec. SIP hỗ trợ việc mô tả các session mà cho phép các bên tham gia có thể đồng ý thiết lập các kiểu phương tiện tương thích.

SIP cung cấp các dịch vụ như:

• User Location: Xác định hệ thống cuối cùng để sử dụng cho việc truyền thông.
• Call Setup: Ringing và thiết lập các thông số cho call tại hai bên Called và Calling.
• User Availability: Xác định sự hài lòng của bên gọi để cam kết trong truyền thông.
• User Capabilities: Xác định phương tiện và các thông số của phương tiện được sử dụng.
• Call handling: Chuyển giao và kết thúc Call.

Chức năng và nét đặc trưng của giao thức SIP

Hai thành phần chính trong hệ thống SIP bao gồm: SIP User Agents và SIP Network Servers .

SIP User Agent (UA)

Mục đích của SIP là làm cho các session có thể thiết lập giữa các UA. Một UA là một hệ thống cuối cùng hoạt động trên danh nghĩa của người dùng. Một UA phải có khả năng thiết lập một session của phương tiện này với các UA khác.

Một UA phải duy trì trạng thái trên các cuộc gọi mà nó khởi tạo hoặc tham gia vào. Một trạng thái nhỏ nhất của các cuộc gọi được thiết lập bao gồm: các thẻ Local và Remote, Call-ID, các trường Local và Remote CSeq, cùng với việc thiết lập hướng và các thông tin cần thiết của các phương tiện. Remote Cseq thì lưu trữ các thông tin cần thiết để phân biệt giữa một Re-INVITE và một Re-Transmission. Một Re-INVITE được sử dụng để thay đổi các tham số session của một cuộc gọi đã thực hiện hoặc chưa xử lý. Nó sử dụng như một Call-ID nhưng CSeq thì được gia tăng bởi vì nó là một Request mới. Một INVITE được truyền lại chứa Call-ID và CSeq giống như INVITE trước. UA duy trì trạng thái của một cuộc gọi trong thời gian tối thiểu là 32 giây.

Một UA chứa một ứng dụng Client và một ứng dụng Server. Hai thành phần trên là một User Agent Client (UAC) và một User Agent Server (UAS). UAC bắt đầu các Request trong khi UAS thì tạo ra các Response. Trong một session, UA thường điều khiển cả UAC và UAS.

Phóng to hình

Một SIP User Agent cũng phải hỗ trợ SDP để mô tả Media.

Một UA phải hiểu rõ danh sách các trường nhu cầu mở rộng trong một Request. Nếu không biết các trường này có thể bị lờ đi bởi một UA.

SIP Server

SIP servers là các ứng dụng mà nó chấp nhận các SIP Request và Response đến chúng. Không nên lẫn lộn SIP Server với một User Agent Server hoặc Client-Server. Một SIP Server là một kiểu khác biệt của thực thể. Bởi vì SIP Server cung cấp các dịch vụ và chức năng với UA, chúng sẽ hỗ trợ cả TCP, TLS và UDP để truyền tải.

SIP Operation in Redirect mode and Proxy Mode

SIP server proxy

Một SIP Proxy Server nhận một SIP Request từ một User Agent hoặc một Proxy khác và hành động trên nhân danh của User Agent trong Forwarding hoặc Responding tới Request. Một Proxy không phải là B2BUA vì nó chỉ cho phép chỉnh sửa các Request và chấp nhận các Response để thiết lập các qui tắc bên ngoài trong RFC 3261. Các quy tắc này thì duy trì theo khoảng cách End-To-End của tín hiệu SIP trong khi đó vẫn còn cho phép các proxy server thực hiện các dịch vụ và chức năng với User Agent.

Một Proxy Server phải có truy xuất đến các database hoặc vị trí các dịch vụ để giúp đỡ nó trong quá trình xử lý các Request. SIP Protocol thì không xác định giao diện giữa proxy và vị trí dịch vụ. Proxy có thể sử dụng nhiều kiểu database trong quá trình xử lý các Request. Database có thể chứa SIP Registration, các thông tin hiện hữu, và nhiểu kiểu khác của thông tin về nơi mà User được chỉ định.

Một Proxy Server khác biệt với một User Agent hoặc Gateway ở ba điểm sau:

• Một Proxy Server không đưa ra các Request, nó chỉ đáp ứng các Request từ một User Agent (A CANCEL Request là một ngoại lệ trong quy tắc này).
• Một Proxy Server không có khả năng về Media.
• Một Proxy Server thì không phân tích các thông điệp, mà chỉ dựa vào các Header Field.

SIP Operation in Proxy Mode

Các bước cần thiết trong mô hình proxy để mang một cuộc gọi hai hướng.

Mô hình Proxy của Operation (Source:Henning Schulzrinne, Columbia University )

Proxy Server chấp nhận INVITE Request từ Client.

Proxy Server liên hệ với Location Server để yêu cầu địa chỉ của UA đã gọi. Location Server xác định vị trí của UA đã gọi và cung cấp địa chỉ của Server đích. INVITE Request được tiếp tới một địa chỉ của vị trí mà nó được trở lại. Proxy phải thêm vào một Record-Route Header tới thông điệp INVITE để chắc chắn rằng tất cả các thông điệp đến sau đều được định tuyến thông qua Proxy. Điều này thì cần thiết để thống kê các mục đích hoặc các ứng dụng khác.

Called UA cảnh giác các User. User trả lời cuộc gọi.
UAS trở về một 200 OK biểu thị tới yêu cầu Proxy Server.
200 OK Response được tiếp tới từ Proxy Server tới Calling UA.
Calling UA xác nhận của 200 OK bằng cách đưa ra một ACK Request được gửi tới Proxy(khi mà Proxy chèn vào đầu Record-Route trong thông điệp INVITE) hoặc gửi trực tiếp tới Called UA.
Proxy chuyển tiếp ACK tới Called UA.

Tìm hiểu một ví dụ về Forking Proxy Operation

Redirect Servers

Một redirect server (hình bên dưới)như là một kiểu của SIP Server mà đáp ứng tới, nó không forward các request.

Schroedinger thừa nhận response:

Chú ý rằng ACK request sử dụng lại các nhánh ID giống nhau như là INVITE và Response 302. Bởi vì một ACK đến một Response Non-2xx cuối cùng đều nghĩ tới các phần của các giao tác giống nhau như là INVITE. Chỉ một ACK gửi trong một Response được đến một 200 OK được tính đến việc tách rời các giao tác với một nhánh ID độc nhất. Một ACK đến một Response 200 OK cuối cùng là một Hop-by-Hop Response, không phải là End-to-End Response.

Vì vậy một INVITE mới được tạo ra với một Call-ID mới và gửi trực tiếp tới các vị trí vẫn được sử dụng từ các trường Contact Header trong một Response 302, từ Redirect Server:

Các bước trong mô hình redirect để mang đi một call two-way:

Redirect server chấp nhận INVITE request từ calling party UA. Redirect Server liên hệ với Location Services để lấy địa chỉ của Called Party UA. Location Services trở về địa chỉ của Called Party UA.
Sau khi user được chỉ định, Redirect Server trở lại địa chỉ trực tiếp tới Calling Party trong một thông điệp 3xx, với danh sách được cập nhật: vị trí đầu tới đích mới. Không giống như Proxy Server, Redirect Server không forward tới INVITE.
UAC gửi một ACK tới Redirect Server báo nhận Response 3xx.
UAC gửi một Request INVITE trực tiếp tới Contact: địa chỉ trở lại bởi Redirect.
CalledParty UA cảnh báo các user, user trả lời cuộc gọi. Called Party UA cung cấp một chỉ báo thành công(200 OK) tới UAC.
UAC gửi một ACK tới UAS báo đã nhận Response 200 OK. Mô hình Redirect Server của Operation.
(Source:Henning Schulzrinne, Columbia University)

Registration Servers

Một Registration Server được biết như là một Registrar, chấp nhận các Request của SIP REGISTER ;tất cả các Request nhận một Response:501 Not Implemented. Thông tin liên quan từ Request làm cho các SIP Server có sẳn bên trong giống Administrator Domain, chẳng hạn như Proxies và Redirect Server. Trong một Resistration Request, trường TO Header chứa tên của tài nguyên bắt đầu Registed, và trường Contact Header chứa địa chỉ khác hoặc Aliases. Registration Server tạo ra một liên kết tạm giữa Address Of Record (AOR) URI trong TO và thiết bị URI trong Contact Courier.

Registration Server thường yêu cầu các User Agent đăng ký để xác thực, vì vậy các cuộc gọi đi vào không bị chiếm đoạt bởi các User không được xác thực. Phụ thuộc vào sự hiện diện của các trường, Register Request có thể được sử dụng bởi một User Agent để lấy lại một danh sách của các Registration hiện thời, làm sạch tất cả Registrations, hoặc thêm vào một Registration URI.

Để bảo vệ Registration, TLS phải được sử dụng như HTTP Digest không cung cấp nhu cầu bảo vệ toàn vẹn.

SIP Messages có thể được phân chia rộng rải trong SIP Requests và Responses, hơn nữa nó được xác định trong các session.

SIP Request

SIP Requests là các thông điệp được gửi từ các máy Client đến các Server để cần khẩn một SIP Operation. RFC 3261 xác định các SIP Request hoặc Method làm cho UA và Proxy có thể tới vị trí của các User và khởi đầu, sửa đổi, Tear-down các session.

INVITE:chỉ ra rằng các Recipient User hoặc các service bị cuốn vào trong một session. Bạn có thể sử dụng method mày để sửa đổi cấu thành của các session được thiết lập trước. Thân của Message INVITE phải bao gồm phần mô tả các Media Session được thiết lập hoặc chỉnh sửa, mã hóa trên SDP. Một Response thành công (200 OK Response)chỉ ra sự sẳn sàng của các Called Party khi tham gia vào kết quả của một session media. Nó bắt đầu một session.

ACK: xác nhận UAC đã nhận được Response cuối cùng đến một Request INVITE. ACK được sử dụng chỉ với các Request INVITE. ACK gửi End-To-End cho một 200 OK Response. Proxy trước hoặc UAC thì gửi các ACK cho các Response cuối cùng khác. ACK Request có thể bao gồm một thông điệp với phần mô tả các session cuối cùng nếu Request INVITE không chứa phần mô tả các session này.

OPTION: UA sử dụng Request OPTION để truy vấn một UAS về khả năng của nó. Nếu UAS có khả năng truyền các session tới các User, nó đáp ứng khả năng thiết lập của UAS.

BYE: sử dụng BYE để yêu kết thúc các session được thiết lập trước.

CANCEL: làm cho các UAC và Network Server có thể hủy một yêu cầu tiến trình bên trong, như INVITE. Điều này không ảnh hưởng đến việc hoàn thành các Request mà UAS đã gửi đi các Response cuối cùng.

REGISTER: client sử dụng REGISTER Request để đăng ký với các thông tin tương ứng AOR của người dùng và SIP servers.

PRACK: đảm bảo độ tin cậy tạm thời của các Response lớp 1xx.

UPDATE: cập nhật tạm thời các session.

REFER: chuyển giao call đến bên thứ ba sử dụng các thông tin liên quan được cung cấp trong các Request.

SUBSCRIBE: báo cáo một sự kiện vừa diễn ra, ví dụ như cập nhật sự hiện của các user.

NOTIFY: sử dụng để thông báo sự kiện đã diễn ra.

MESSAGE: một phương thức để chỉ việc mang đi một message.

SIP Respone: Một server gửi SIP Response tới một Client để chỉ ra trạng thái của một SIP Request mà Client trước đó đã gửi tới Server. UAS hoặc Proxy thì tạo ra các SIP Responses trong Response đến một SIP Request mà UAC khởi đầu. SIP Response là các con số từ 100 đến 699. SIP Responses là một nhóm giống như 1xx,2xx đến 6xx. SIP Response được phân loại như Provisional và Final.

Một Provisional Response chỉ ra tiến trình bởi server nhưng nó không chỉ ra các kết quả cuối cùng giống như kết quả quá trình xử lý các SIP Request. Lớp 1xx của SIP Response chỉ ra trạng thái tạm thời. Response cuối cùng chỉ ra phần kết thúc và trạng thái cuối cùng của SIP Request. Tất cả các lớp 2xx,3xx,4xx,5xx và 6xx đều là cuối cùng,riêng biệt: Lớp 1xx(Information)chỉ ra trạng thái của các call trước khi hoàn thành.

Lớp 2xx(Success)chỉ ra quá trình xử lý thành công của SIP Request

Lớp 3xx(Redirection)chỉ ra SIP Request cần phải gửi một lần nữa đến UAS khác để thực hiện tiến trình xử lý.

Lớp 4xx(Client-error)Request bị hỏng bởi Client. Client có thể thực hiện lại Request.

Lớp 5xx(server failure)Request bị hỏng do Server. Request có thể thử lại tại các Server khác. Lớp 6xx(Global failure) Request bị hỏng và không nên thử lại Request tại Server này hoặc Server khác.

SIP Message structure

Một SIP message gồm có các phần sau:

• Một Start-Line.
• Một hoặc nhiều header field.
• Một dòng rỗng để chỉ ra kết thúc header field.
• Một tùy chọn phần thân của thông điệp.
• Bạn phải kết thúc Start-Line,mổi dòng Message-Header,và một dòng rỗng bằng trình tự
• Carriage return Line Feed(CRLF).

Start-Line cho một SIP Request là một Request-line. Start-line cho một SIP Response là Status-line. Request-line chỉ rõ SIP Method, Request-URI và phiên bản của SIP. Status-line thì mô tả phiên bản của SIP, mã của SIP Response và một tùy chọn Reason Phrase. Reason Phrase là một nguyên văn mô tả của mã 3 ký từ SIP Response.

Bảng thể hiện các thành phần của 1 SIP Request Message:

Thông tin trong bảng được lấy từ RFC 3261

Bảng thể hiện cấu trúc của một SIP Respone Message:

Thông tin trong bảng được lấy từ RFC 3261

SIP header

Một thông điệp SIP được soạn ra từ các Header Field mà nó truyền tín hiệu và thông tin Routing đến các thực thể SIP Network. SIP có hình thức giống như HTTP Header(RFC 2616). Các Header Field được xác định kiểu như Header Field. Mô tả chức năng của các SIP Header:

From: chỉ ra sự giống nhau lúc bắt đầu của các SIP Request. Từ Header thường là AOR của bên gửi. Nó chứa một SIP hoặc các SIP URI và một tùy chọn hiển thị tên.

To: cho biết mong muốn có người nhận của một SIP Request. Đi đến Header là một AOR của người nhận. Nó cũng chứa SIP hoặc SIP URI và tùy chọn hiển thị tên.

Call-ID: trường này nhận ra một dãy serie của một message. Call_ID phải giống hệt nhau để tất cả các SIP rRequest và SIP Response gửi đi bằng các UA khác nhau với cùng một dialog.

Cseq: được soạn ra của một giá trị số nguyên và tên method. Trường này nhận ra Orders và tiếp tục các SIP Request trong một dialog. Cseq cũng có sự khác biệt trong việc gửi lại một message và một message mới.

Via: chỉ ra cách lấy đường dẫn bởi một request và xác định nơi mà response cần gửi đi.

Contact: nhận biết một SIP hoặc SIP URI nơi mà UA muốn nhận một SIP Request mới.

Allow: cho phép danh sách Header của SIP Method nhận hỗ trợ của UA mà tạo ra message.

Supported: tất cả phần mở rộng của SIP hỗ trợ bởi UA. Phần mở rộng của SIP là các RFC khác và RFC 3261. Miêu tả các thẻ option giống như 100rel trong RFC 3262.

Require: về nghĩa nó giống như Supported Header, nhưng sự hỗ trợ của phần mở rộng SIP ở các UA từ xa phải đến các giao tác để được xử lý.

Content-type: chỉ ra kiểu của thân message mà đính kèm với SIP Request hoặc Response phải được hiện ra nếu SIP Message có một thân.

Content-Length: xác định kích thước của thân message. SIP Request và SIP Response cũng chứa các Header Field.

Related Protocol SIP là một phần của bộ giao thức. Gồm có:SDP, RTP và RTCP.

SDP-Session Description Protocol: SDP được định nghĩa bởi RFC 2327, được phát triển bởi IETF MMUSIC. Mục đích ban đầu là mô tả việc thiết lập các Multicast Session thông qua MBONE. Ứng dụng đầu tiên của SDP là giao thức Session Announcement Protocol(SAP)sử dụng các port và nhận các thông báo của các MBONE session. SDP chứa các thông tin về media session:IP Address(IPv4 address hoặc host name). Port Number(sử dụng UDP hoặc TCP để truyền tải). Media type(audio,video,tương tác whiteboard,…). Media Encoding scheme(PCM A-Law,MPEG II video,…). SDP còn chứa các thông tin: chủ đề của các session. Bắt đầu và kết thúc mọi thời điểm. Liên hệ thông tin về các session. Giống như SIP, SDP dử dụng mã hóa văn bản. Một SDP Message được soạn là một series của các dòng, các trường Called, và nó yêu cầu Order để dễ dàng phân tích. SDP thì không được gán để có thể mở rộng dễ dàng, và phân tích các quy tắc một cách chính xác. Một người phân tích SDP không phải để ý tới các trường chưa biết đến, các trường missing, hoặc một dòng out-of-sequence.

Ví dụ một SIP Message chứa nhiều các Fields tùy chọn được hiển thị ở đây:

Thông tin trong bảng được lấy từ RFC 3261

Biểu mẫu của một SIP Message:X=parameter1 parameter2...parameter N.

Danh sách các SDP field trong Required của chúng.

Dòng bắt đầu với một chữ thường ký tự x. Không có khoảng trống giữa các ký tự và dấu =, chính xác là có một khoảng trắng giữa mỗi ký tự. Mỗi trường có một xác định của các tham số. Mỗi dòng kết thúc với một CRLF. RTP Audio Video Profiles được định nghĩa bởi RFC 3551 được liệt kê trong bảng:

Audio voideo profiles

Tài liệu hiện trạng đặc tả RTP:

UDP được sử dụng để ưu tiên truyền tải.

Số port của RTP luôn chẳn, tương ứng số port RTCP kế tiếp là lớn nhất, luôn luôn là số lẻ. Không có Header mở rộng nào được sử dụng.

Thông tin trong ba cột đầu tiên nó cũng chứa trong SDP a=rtpmap:field, thể hiện vì sao các thuộc tính được tùy chọn.

PSTN Protocols: Ba kiểu giao thức truyền tín hiệu PSTN: Circuit Associate Signaling(CAS),Integrated Services Digital Network(ISDN),và ISDN User Part(ISU).

Circuit Associate Signaling: đây là kiểu lâu nhất mà PSTN còn sử dụng. Thông tin sử dụng giống như chuyển mạch audio, như đường dẫn voice, với các ký số và ký từ trình bày bởi các tín hiệu số audio. Các tín hiệu số được gọi đến MT(Multifrequency Tone). Chúng giống như một tín hiệu số giữa một điện thoại và một trung tâm chuyển mạch, nó là tín hiệu số DTMF. Vì vậy CAS dễ bị gian lận, một tín hiệu không trung thực có thể được tạo ra bởi một Caller để làm cho cuộc gọi được miễn phí. Kiểu truyền tín hiệu này phổ biến giữa các văn phòng trung tâm và trao đổi giữa các chi nhánh riêng của tập đoàn(PBX).

ISUP Signaling: ISDN User Part là giao thức sử dụng giữa chuyển mạch điện thoại trong PSTN. Nó sử dụng thông qua một mạng Packet-Switched chuyên dụng mà sử dụng hệ thống Signaling System #7(SS7)để truyền tải. Phương thức này được phát triển để khắc phục sự trì hoãn và các vấn đề bảo mật trong CAS.

SDN Signaling: ISDN được phát triển để tất cả các hệ thống điện thoại số kết nối với PSTN. Kiểu phổ biến nhất dựa trên BRI(Basic Rate Interface)và PRI(Primary Rate Interface). Một BRI có thể chứa hai kênh truyền B 64-Kbps đến các voice khác hoặc dữ liệu và một kênh D 16-Kbps. BRI có thể được sử dụng thông qua các đường dây điện thoại quy ước nhưng nó yêu cầu một ISDN telephone hoặc một bộ tích hợp cuối cùng. PRI sử dụng một liên kết 1.544Mbps gọi tới một T-1 hoặc một DS-1 được chia sẻ bên trong 23 kênh B và một kênh D, với mỗi kênh là 64Kbps.

Tìm hiểu về H323

Những giao thức VoIP có thể được phân loại tùy theo vai trò của chúng trong suốt quá trình chuyển giao thông điệp. H323 và SIP là những giao thức báo hiệu, các giao thức này dùng để thiết lập, ngắt và thay đổi cuộc gọi. RTP và RTCP cung cấp chức năng mạng vận chuyển End-To-End cho những ứng dụng truyền dữ liệu mà yêu cầu thời gian thực (real-time) như là âm thanh và video. Những chức năng đó bao gồm nhận diện loại dữ liệu, số trình tự, tham số thời gian và giám sát tiến trình gửi. TRIP,SAP,STUN, TURN… bao gỗm một nhóm các giao thức hỗ trợ có liên quan đến VoIP. Sau cùng, bởi vì VoIP gían tiếp dựa vào tầng vận chuyển bên dưới để di chuyển dữ liệu nên đòi hỏi nhiều giao thức như là TCP/IP,DNS,DHCP,SNMP,RSVP, và TFTP.

Đặc điểm kĩ thuật của giao thức H323

Bộ giao thức H323 cho phép những thiết bị kết nối khác nhau có thể liên kết với nhau. H323 được phổ biến bởi tổ chức ITU. Giao thức này ban đầu được phát triển cho những ứng dụng đa phương tiện, các thực thể của H323 cung cấp những tiến trình liên quan đến vấn đề đồng bộ như thoại, video và kết nối dữ liệu. Hỗ trợ cho thoại là chủ yếu, hỗ trợ cho video, kết nối dữ liệu chỉ là phần mở rộng của H323.

Đặc điểm kỹ thuật của H323 định nghĩa bốn thực thể H323 khác nhau như là các đơn vị chức năng của mạng H323 hoàn chỉnh, những thành phần này của hệ thống H323 bao gồm thiết bị đầu cuối, gateway, gatekeeper và các đơn vị điều khiển đa điểm (MCUs). Thiết bị đầu cuối (điện thoại, softphones, IVRs, thư thoại, máy quay phim,v.v…) là những thiết bị điển hình tác động qua lại với người dùng cuối. Phần mềm MS Netmeeting là một ví dụ của thiết bị đầu cuối. Các thiết bị đầu cuối chỉ cung cấp thoại hoặc đa phương tiện như là video và sự cộng tác ứng dụng thời gian thực.

Gateways giải quyết điều khiển tín hiệu và truyền dẫn phương tiện, và là thành phần mở rộng. Điển hình của gateway là cung cấp giao diện cho những mạng khác nhau như là ISDN, PSTN hoặc những hệ thống H323 khác. Bạn có thể nghĩ chức năng của H323 như là cung cấp một "bộ dịch". Ví dụ như là một gateway H323 sẽ điều khiển sự đàm thoại của H323 với SIP hoặc H323 với ISUP(ISDN User Part) chỉ rõ tính chất thủ tục tín hiệu xen kẽ cho việc điều khiển cuộc gọi. Nghĩ một cách khác thì một gateway cung cấp một giao diện giữa mạng chuyển gói(ví dụ như VoIP) và mạng chuyển mạch (ví dụ như PSTN). Nếu Gatekeeper tồn tại, Gateway VoIP đăng ký với Gatekeeper đó và Gatekeeper sẽ tìm ra Gateway tốt nhất cho phiên giao dịch chi tiết.

Gatekeeper cũng là phân mở rộng của H323, điều khiển việc giải quyết địa chỉ và cho vào mạng H323. Chức năng quan trọng nhất của nó là biên dịch địa chỉ giữa địa chỉ ký danh tượng trưng và địa chỉ IP.

Ví dụ: với sự có mặt của Gatekeeper nó có khả năng gọi tới địa chỉ có tên là "Tom" thay vì phải gọi tới địa chỉ IP 192.168.10.10. Gatekeeper cũng quản lý các thiết bị đầu cuối truy cập vào các thiết bị, tài nguyên mạng, và mở rộng hơn là có thể cung cấp các dịch vụ phụ. Chúng cũng giám sát việc sử dụng dịch vụ và cung cấp băng thông có giới hạn. Một Gatekeeper thì không đòi hỏi một hệ thống H323. Tuy nhiên nếu có sự hiện diện của Gatekeeper, các thiết bị đầu cuối muốn sử dụng được thì cần phải có sự phục vụ của Gatekeeper. RAS định nghĩa khái niệm này là sự biên dịch địa chỉ, điều khiển sự đi vào, điều khiển băng thông, sự quản trị miền. Các chức năng của Gatekeeper và Gateway thường được hiện diện trên những thiết bị vật lý đơn giản.

MCUs hỗ trợ hội nghị nhiều bên giữa ba hay nhiều thiết bị đầu cuối.

Chuẩn H323 cho phép nhiều kịch bản đàm thoại đặc biệt, hoặc tập trung hay phân quyền.

Base-end servers (BES) là một chức năng bổ sung quan trọng trong hạ tầng H323. BES có thể cung cấp những dịch vụ cho việc chứng thực người sử dụng, sự ủy quyền dịch vụ, tài chính, nạp điện và hóa đơn, và các dịch vụ khác. Trong một mạng đơn giản thì Gatekeeper và Gateway cung cấp những dịch vụ như thế.

Những giao thức có liên hệ với H323

H323 có đặc điểm kỹ thuật giống như một chiếc dù chứa đựng một số lượng lớn bộ máy chính trị có tác động qua lại với nhau bằng nhiều cách thức khác nhau dựa vào bộ dạng, sự vắng mặt, mối quan hệ mô hình của những thực thể tham gia và loại session (ví dụ như là audio và video). Có nhiều giao thức con bên trong đặc điểm của giao thức H323. Để mà có thể hiểu được toàn bộ những luồng thông điệp bên trong một giao tác VoIP của giao thức H323, bản thân chúng ta sẽ tự quan tâm đến những giao thức chung nhất có liên quan đến công nghệ VoIP.

H323 định nghĩa một tập hợp tổng quát việc thiết lập cuộc gọi và những thủ tục đàm phán- quan trọng nhất trong các ứng dụng VoIP ngày nay là các giao thức H.225, H.235, H.245 và các bộ phận của dãy tín hiệu Q.900. Các phương pháp vận chuyển dữ liệu cơ bản được định nghĩa bởi giao thức thời gian thực RTP và RTCP. H323 cũng chỉ rõ một nhóm audio codes cho sự liên kết VoIP, dãy G.700:

H.225/Q.931 định nghĩa tín hiệu cho việc thiết lập và ngắt cuộc gọi, bao gồm địa chỉ IP nguồn và địa chỉ IP đích, cổng, mã vùng, và thông tin cổng của giao thức H245.H.225.0/RAS chỉ rõ thông điệp mà mô tả tín hiệu, và thông tin dòng media.H.245 chỉ rõ thông điệp và thông tin kênh logic cho dòng phương tiện. Real Time Protocol (RTP) mô tả vận chuyển End-To-End của dữ liệu thời gian thực Real Time Control Protocol (RTCP) mô tả việc giám sát End-To-End của việc chuyển dữ liệu, chất lượng dịch vụ của thông tin cung cấp như là Jitter và sự thất lạc trung bình của packet.

Codecs G.700 series được sử dụng cho VoIP bao gồm:

G.711 Một trong số codecs lâu đời nhất, G.711 không sử dụng sự nén, vì thế giọng nói có chất lượng tuyệt vời.Codec này tiêu thụ nhiều dải thông nhất.Đây là codec tương tự được dùng bởi PSTN và ISDN.

G.723.1 Codec này được thiết kế cho tổ chức hội nghị video/ kỹ thuật điện thoại thông qua các đường điện thoại tiêu chuẩn và được tối ưu hóa cho việc mã hóa và giải mã nhanh chóng, chất lượng thoại thuộc loại trung bình.

G.729 codec này được sử dụng chủ yếu trong những ứng dụng VoIP bởi vì nhu cầu băng thông của nó thấp.

So sánh giữa SIP và H323

SIP và H.323 đều được phát triển với mục đích và nhu cầu khác biệt. H.323 được phát triển bởi ITU. Nó được thiết kế để thực hiện trong background của PSTN, sử dụng sự mã hóa binary và sử dụng lại vai trò của ISDN.

SIP được phát triển bởi IETF với một phối cảnh Internet, được thiết kế để thay đổi tỉ lệ thông qua Internet và làm việc bên trong domain thì rất tiện dụng vì nó tập hợp đầy đủ các chức năng và tiện ích Internet.

Trong khi H.323 được phát triển sớm trong VoIP, các ứng dụng IP Video Conferencing, SIP với hạ tầng Internet tạo đà phát triển và nổi lên như là một chuẩn trong việc truyền tín hiệu của truyền thông IP trong tương lai, như IP telephone.

Bảng so sánh giữa SIP và H.323

Bảng so sánh giữa SIP và H.323

Tìm hiểu giao thức MGCP

MGCP là giao thức ở mức ứng dụng dùng để điều khiển các gateway thoại từ các thiết bị điều khiển cuộc gọi, được gọi là MGC (Media Gateway Controller) hoặc CA (Call Agent). MGCP là sự bổ sung của cả hai giao thức SIP và H.323, được thiết kế đặc biệt như một giao thức bên trong giữa các MG và các MGC cho việc tách hoá kiến trúc GW. Trong đó, MGC xử lý cuộc gọi bằng việc giao tiếp với mạng IP qua truyền thông với một thiết bị báo hiệu địa chỉ giống như H.323 GK hoặc SIP Server và với mạng chuyển mạch kênh qua một GW báo hiệu tuỳ chọn. MGC thực hiện đầy đủ chức năng của lớp báo hiệu trong H.323 và như một H.323 GK. MG có nhiệm vụ chuyển đổi giữa dạng tínhiệu analog từ các mạch điện thoại, với các gói tin trong mạng chuyển mạch gói. MGCP hoàn toàn tương thích với VoIP GW. Nó cung cấp một giải pháp mở cho truyền thông qua mạng và sẽ cùng tồn tại với H.323 và SIP.

Kiến trúc và thành phần của MGCP

Giao thức điều khiển cổng đa phương tiện MGCP được coi là giao thức điều khiển trong quan hệ Client/Server. Trong đó MGC đóng vai trò Server thực hiện quản lý trạng thái cuộc gọi và định hướng cho MG từng bước trong quá trình thiết lập cuộc gọi. Cổng đa phương tiện MG sẽ khôngthực hiện bất cứ một hoạt động nào có liên quan đến cuộc gọi như cung cấp âm mời quay số, chuông nếu như không có yêu cầu của MGC. Quan hệ giữa MG và MGC (hay CA) được mô tả trên hình bên dưới. MGC thực hiện báo hiệu cuộc gọi, điều khiển MG. MGC và MG trao đổi lệnh với nhau thông qua MGCP. Quá trình thiết lập giữa hai đầu cuối tại các gateway cùng được quản lý bởi MGC diễn ra như sau:

+ MGC gửi CreatConnection tới GW đầu tiên. GW sẽ định vị các tài nguyên cần thiết và gửi trả các thông tin cần thiết cho kết nối như địa chỉIP, cổng UDP, các tham số cho quá trình đóng gói. Các thông tin này được chuyển tiếp qua MGC.
+ MGC gửi CreatConnection tới GW thứ hai chứa các thông tin chuyển tiếp trên. GW này trả về các thông tin mô tả phiên của nó.
+ MGC gửi lệnh ModifyConnection tới đầu cuối thứ nhất. Quá trình kết nối thành công sau khi hoàn tất các bước trên.

Vị trí giao thức MGCP trong mối quan hệ MGC và MG

Thiết lập cuộc gọi qua giao thức MGCP

Mô hình thiết lập cuộc gọi giữa A và B qua MGCP

Trình tự thiết lập cuộc gọi giữa hai máy điện thoại A điện thoại B như sau:

- Khi máy điện thoại A được nhấc lên Gateway A gửi bản tin cho MGC.
- Gateway A tạo âm mời quay số và nhận số bị gọi.
- Số bị gọi được gửi cho MGC.
- MGC xác định định tuyến cuộc gọi như thế nào :

- MGC gửi lệnh cho Gateway B.
- Gateway B đổ chuông ở máy B.
- MGC gửi lệnh cho Gateway A và B tạo phiên kết nối RTP/RTCP.

Tìm hiểu giao thức MEGACO

MEGACO là giao thức điều khiển cổng phương tiện nói chung, bao gồm cổng nội hạt, trung kế trong mạng PSTN, giao diện ATM, giao diện thoại và dây analog, điện thoại IP, các loại server…

Với tính năng hỗ trợ rộng rãi các ứng dụng một cách mềm dẻo, đơn giản và hiệu quả ở mức chi phí hợp lý, MEGACO sẽ là chuẩn được sử dụng trong mạng thế hệ mới. MEGACO không bị ràng buộc với bất kỳ một giao thức điều khiển cuộc gọi ngang cấp nào (ví dụ SIP hay H.323) và hoàn toàn tuỳ thuộc vào thiết kế của người quản trị mạng. Kiến trúc của MEGACO được thể hiện trên hình bên dưới dựa trên 3 lớp: lớp MGC, lớp MG, lớp MEGACO.

Kiến trúc điều khiển của MEGACO

Lớp MGC chứa tất cả các phần mềm điều khiển, xử lý cuộc gọi. Lớp này thực hiện các đặc điểm ở mức cuộc gọi như phát triển cuộc gọi, chuyển cuộc gọi, hội thoại hay hold. Lớp MGC cũng thực hiện giao tiếp với các MGC cũng như các thực thể ngang cấp hay cấp dưới khác, MGC quản lý mọi thuộc tính trong quá trình giao tiếp. Lớp MG thực hiện các kết nối lưu lượng đi và tới các mạng khác, tương tác với các luồng lưu lượng này qua ứng dụng báo hiệu và sự kiện. Lớp MG cũng điều khiển các thuộc tính thiết bị của cổng phương tiện (ví dụnhư giao diện với người dùng). Lớp này không hề biết gì về việc điều khiển các thuộc tính cuộc gọi và hoạt động theo sự điều khiển của lớp MGC. Lớp MEGACO/H.248 quy định cách thức mà lớp MGC điều khiển lớp MG.

Chức năng của giao thức MEGACO

Giao thức MEGACO/H.248 định nghĩa giao diện điều khiển của MGC đối với MG. MEGACO cung cấp các chức năng sau:
- Điều khiển các loại MG khác nhau (TGW, RGW, AGW, MS...)
- Hỗ trợ đàm phán quyết định các thuộc tính cuộc gọi
- Có khả năng xử lý cuộc gọi đa người dùng
- Hỗ trợ QoS và đo lường lưu lượng (các thông tin thống kê sau mỗi kết nối)
- Thông báo lỗi giao thức, mạng, hay các thuộc tính cuộc gọi.

Vị trí của giao thức MEGACO trong mô hình OSI

Giao thức MEGACO thực hiện chức năngcủa mình ở 3 lớp trên cùng trong mô hình OSI: lớp ứng dụng, lớp trình diễnvà lớp phiên.

Giao thức MEGACO trong mô hình OSI

Hoạt động của giao thức MEGACO

Khi một đầu cuối nào đó nhấc máy và đinh thực hiện cuộc gọi, sự kiện này sẽ được phát hiện bởi MG quản lý nó. MG sẽ thông báo sự kiện này tới MGC trực thuộc, MGC sẽ chỉ định MG này bằng một lệnh để gửi âm báo mời quay số tới đầu cuối đó, đồng thời digitmap cũng được MG này cập nhật từ MGC, để phục vụ cho việc thu các chữ số và gửi toàn bộ số được quay về MGC.

Mô tả cuộc gọi MEGACO

iả sử đầu cuối bị gọi thuộc một MG khác nhưng cùng được quản lý bởi MGC trên. Quá trình thiết lập liên kết được tiến hành theo các bước cơ bản sau:

- MGC yêu cầu MG thứ nhất thiết lập một kết nối tại điểm kết cuốithứ nhất. MG này sẽ phân bổ tài nguyên cho kết nối yêu cầu và đáp ứng lại bằng bản tin trả lời. Bản tin trả lời sẽ chứa các thông tin cần thiết để MG thứ hai có thể gửi các bản tin một cách tin cậy tới liên kết vừa thiết lập. Các thông tin này có thể là: địa chỉ IP, tên cổng UDP, TCP hay các thông tin đóng gói bản tin.
- Tương tự, MGC cũng yêu cầu MG thứ hai thiết lập một liên kết ở điểm kết cuối thứ hai. MG này phân bổ tài nguyên cho kết nối này trên cơ sở các thông tin trong bản tin đáp ứng của MG thứ nhất. Tới lượt, MG thứ haicũng đáp ứng lại bằng bản tin chứa các thông tin cần thiết nhằm đảm bảo MG thứ nhất có thể gửi các bản tin một cách tin cậy tới liên kết vừa thiết lập bởi MG thứ hai.
- Các thông tin trong bản tin đáp ứng của MG thứ hai sẽ được gửi tới MG thứ nhất. Khi này liên kết đã được thiết lập, quá trình truyền thông có thể diễn ra theo hai chiều. Lưu lượng được truyền tải nhờ các giao thức RTP hay RTCP.
- Trong trường hợp hai MG được quản lý bởi 2 MGC khác nhau, các MGC này sẽ trao đổi các thông tin báo hiệu thông qua một giao thức báo hiệu từ MGC tới MGC (có thể là SIP hay H.323) để đảm bảo việc đồng bộ trong việc thiết lập kết nối tới hai điểm kết cuối.
- Khi liên kết đã được thiết lập, các tham số của nó được giám sát bởi MGC vàcó thể được thay đổi dưới các lệnh của MGC (ví dụ như thêm một kết cuốivào liên kết).

Các ưu điểm của giao thức MEGACO so với các giao thức điều khiểncổng phương tiện khác

So với giao thức MGCP, phiên bản MEGACO version 3 (gần đây nhất là tháng 6 năm 2004) có các điểm nổi trội sau :

+ Hỗ trợ dịch vụ Multimedia, các dịch vụ hội nghị đa điểm tăngcường.
+ Cải tiến cú pháp lệnh để việc xử lý bản tin hiệu quả hơn.
+ Có khả năng lựa chọn giao thức TCP hay UDP.
+ Chấp nhận cả việc mã hoá văn bản hay nhị phân.
+ Các gói tin của MEGACO chi tiết hơn MGCP, hơn thế nữa các gói tin mới có thể được định nghĩa dựa trên các gói tin cơ sở này.
+ Đưa ra khái niệm context, khái niệm này hỗ trợ kết nối đa dịch vụ, đa điểm.

Vị trí giao thức MGCP trong mối quan hệ MGC và MG

Tham khảo thêm tại http://vi.scribd.com

Tham khảo thêm tại http://vi.wikipedia.org/wiki/VoIP

Tham khảo thêm tại http://en.wikipedia.org/wiki/Media_Gateway_Control_Protocol_(MGCP)

Tham khảo thêm tại http://en.wikipedia.org/wiki/H.323

Nguồn từ http://www.athlsolutions.com