Nghiên cứu về hệ thống phần mềm tổng đài PBX mã nguồn mở ser và sems của viện nghiên cứu Fokus - Đức, nghiên cứu phát triển dịch vụ trả lời tự động (IVR) cho hệ thống Ser-Sems

g người chuyển tiếp thông tin. Stateless server chuyển tiếp thông tin một cách độc lập với nhau. Mặc dù các thông tin được sắp xếp theo kiểu giao dịch nhưng stateless proxies không quan tâm tới vấn đề này. Stateless proxies đơn giản và nhanh hơn stateful Proxy servers. Chúng có thể được sử dụng như các load balancer đơn giản, các người dịch thông tin, và các bộ định tuyến. Một trong những hạn chế của stateless proxies là chúng không có khả năng truyền lại các thông tin và thực hiện công việc định tuyến cao cấp. Stateful servers Phức tạp hơn Stateless server. Trong lúc nhận yêu cầu, stateful proxies tạo ra một trạng thái và giữ nó cho đến khi sự giao dịch là kết thúc. Vì stateful proxies phải đảm bảo trạng thái này trong suốt quá trình giao dịch, nên sự hoạt động của chúng là giới hạn. Khả năng kết hợp các thông tin SIP thành các phiên giao dịch đưa ra cho stateful proxies một vài đặc điểm thú vị. Stateful proxies có thể thực hiện chia nhánh, nghĩa là trong khi nhận một tin thì 2 hoặc nhiều hơn các tin khác sẽ được gửi đi. Stateful proxies có thể “hấp thụ” việc truyền lại bởi vì chúng biết, từ trạng thái của các phiên giao dịch, nếu chúng đã nhận được cùng một thông tin rồi. Stateful proxies có thể thực hiện các phương pháp phức tạp hơn để tìm ra các user. Ví dụ, khi gọi đến điện thoại đặt ở văn phòng mà không thấy nhấc máy thì có thể tự động chuyển hướng cuộc gọi sang máy di động. Stateless proxy không thể làm được như vậy vì nó không có cách nào để biết được khi nào thì kết thúc phiên gọi đến điện thoại ở văn phòng(sau một khoảng thời gian không nhấc máy thì sẽ tự động kết thúc phiên). Hầu hết các SIP proxies ngày nay là stateful vì cấu hình của chúng thường là rất phức tạp. Chúng thường thực hiện việc tính toán, chia nhánh, và tất cả những đặc trưng đó đòi hỏi một stateful proxy. Cách dùng Proxy Server Một cấu hình đặc trưng là mỗi một thực thể quản lý trung tâm (ví dụ như một công ty) bản thân chúng đều có proxy server SIP và được sử dụng bởi tất cả các tác nhân user trong thực thể đó. Ví dụ có 2 công ty A và B và mỗi công ty đều có proxy server. Hình 5. Lời mời phiên Hình 5 chỉ ra một lời mời phiên từ nhân viên Joe của công ty A đưa tới nhân viên Bob của công ty B nhu thế nào. Joe sử dụng địa chỉ sip:bob@b.com để gọi tới Bob. Tác nhân user của Joe không biết làm thế nào để định tuyến lời mời nhưng nó được cấu hình để gửi tất cả lưu lượng tới SIP proxy server proxy.a.com. Và Proxy server này sẽ tính toán là user có địa chỉ sip:bob@b.com đang ở trong một công ty khác và rồi nó tìm kiếm SIP Proxy server của B sau đó gửi lời mời đến đó. Proxy server của B có thể hoặc được cấu hình trước tại Proxy.a.com hoặc proxy tại A sẽ sử dụng DNS SRV để tìm proxy server của B. Lời mời tới được proxy.b.com. Proxy này biết rằng Bob hiện nay đang ngồi tại cơ quan và có thể tới được thông qua điện thoại trên bàn của anh ta, mà điện thoại này có địa chỉ IP là 1.2.3.4, vì vậy proxy tại B sẽ gửi lời mời tới đó. SIP Gateway SIP gateway là một ứng dụng dùng để kết nối một mạng SIP đến một mạng mà sử dụng giao thức báo hiệu khác. Trong các thuật ngữ của giao thức SIP, gateway chỉ là một trường hợp đặc biệt của UA. Tuy nhiên sự khác nhau giữa gateway và UA nằm ở chỗ số lượng người dùng mà chúng có thể hỗ trợ. Trong khi một UA thông thường chỉ có thể hỗ trợ duy nhất một người dùng thì gateway lại có thể hỗ trợ từ hàng trăm đến hàng ngàn người dùng. Gateway sẽ ngắt luồng báo hiệu và cũng có thể ngắt luôn cả luồng media, nhưng điều này không phải lúc nào cũng xảy ra. Ví dụ, gateway SIP/PSTN sẽ ngắt đồng thời cả luồng báo hiệu và luồng media, vì luồng báo hiệu và media trong mạng SIP được truyền đi dưới dạng các gói tin, còn trong mạng PSTN luồng báo hiệu và media được truyền đi dưới dạng các tín hiệu tương tự. Mặt khác, một gateway SIP/H-323 sẽ ngắt luồng báo hiệu SIP và chuyển đổi dạng báo hiệu sang dạng H-323, nhưng SIP UA và H-323 terminal vẫn có thể trao đổi luồng thông tin media RTP trực tiếp với nhau mà không cần phải đi qua gateway. Gateway đôi khi được phân tách thành hai thành phần: Media Gateway (MG) và Media Gateway Controller (MGC). Sự phân tách này hoàn toàn trong suốt đối với SIP. MGC đôi khi cũng được gọi là tác nhân gọi (call agent) vì nó quản lý các giao thức điều khiển cuộc gọi (hay báo hiệu), trong khi đó MG lại quản lý việc kết nối media. Giao thức SIP có thể hoạt động song song với một số giao thức PSTN thông thường như: Mạng số tích hợp đa dịch vụ ISDN (Intergrated Service Digital Network), ISDN User Part (ISUP), và một số giao thức báo hiệu kênh kết hợp (CAS) khác. Hình 6. SIP Gateway Registrar Chúng ta đã đề cập đến SIP proxy tại proxy.b.com biết vị trí hiện thời của Bob nhưng không đề cập đến làm thế nào để có thể biết được vị trí hiện thời của một người dùng nào đó. User agent của Bob (điện thoại SIP) phải đăng ký với Registrar. Registrar này là một thực thể SIP đặc biệt, chúng nhận những đăng ký từ các users, trích ra những thông tin về vị trí như địa chỉ IP, cổng, hay username… và lưu trữ những thông tin này vào trong 1 vùng cơ sở dữ liệu(được gọi là Location Database – Cơ sở dữ liệu định vị). Mục đích của vùng cơ sở dữ liệu này là ánh xạ sip:bob@b.com thành một kiểu địa chỉ URI khác, ví dụ như sip:bob@1.2.3.4:5060. Cơ sở dữ liệu định vị sau đó được sử dụng bởi proxy server của B. Khi Proxy này nhận được một lời mời cho sip:bob@b.com, nó sẽ tìm kiếm trong cơ sở dữ liệu định vị. Nó tìm ra sip:bob@1.2.3.4:5060 và gửi lời mời tới đó. Registrar thường chỉ là một thực thể logic. Bởi sự kết nối chặt chẽ với các proxy registrar, cho nên thường thì Registrar được đặt cùng với cả các proxy servers. Hình 7. Tổng quan về đăng ký Hình 6 chỉ ra một kiểu đăng ký SIP điển hình. Một thông tin đăng ký mang theo địa chỉ của bản ghi sip:jan@iptel.org và liên hệ với địa chỉ jan@1.2.3.4:5060 mà ở đó 1.2.3.4 là địa chỉ IP của điện thoại, được gửi tới Registrar. Registrar trích thông tin này ra và lưu trữ nó vào trong vùng cơ sở dữ liệu. Nếu mọi chuyện đều thuận lợi thì Registrar gửi một đáp ứng là 200 OK tới điện thoại và quá trình đăng ký được kết thúc. Mỗi đăng ký đều có một vòng đời giới hạn. Trường header expire hoặc tham số expire trong trường header của Contact xác định khoảng thời gian mà đăng ký còn có giá trị. Nếu trong khoảng thời gian đó mà người dùng không sử dụng thì nó sẽ hết hạn và người dùng đó phải đăng ký lại mới dùng được. Redirect Server Thực thể mà nhận yêu cầu và gửi trả lại câu trả lời với 1 danh sách vị trí hiện tại của một user đặc biệt được gọi là redirect server. Một Redirect server nhận yêu cầu và tìm kiếm người nhận trong cơ sở dữ liệu định vị, sau đó nó tạo ra một danh sách các vị trí hiện thời của user và gửi chúng tới người tạo yêu cầu bên trong lớp 3xx. Người tạo yêu cầu sau đó trích một danh sách các đích và gửi các yêu cầu khác một cách trực tiếp đến chúng. Hình 8. Chuyển hướng SIP Khi một user agent hay một proxy server nhận được 1 request nó sẽ gửi đáp ứng response. Mỗi một request phải có một đáp ứng ngoài trừ các request ACK. Transaction (phiên giao dịch) Mặc dù nói các bản tin SIP được gửi đi một cách độc lập qua mạng, nhưng thực tế chúng thường được sắp xếp vào các transaction bởi các user agent và một số kiểu proxy server nào đó. Do đó có thể nói giao thức SIP là một giao thức hỗ trợ transaction. Một transaction là một luồng các bản tin SIP được truyền đi một cách tuần tự giữa các phần tử mạng. Một transaction chứa thông tin yêu cầu và tất cả các thông tin phản hồi cho thông tin yêu cầu đó hoặc thậm chí nhiều hơn các thông tin phản hồi cuối(final response). Ví dụ như bản tin INVITE được phản hồi bởi nhiều hơn 1 thông tin phản hồi cuối khi một proxy chuyển hướng yêu cầu đó. Nếu một transaction được khởi tạo bởi bản tin yêu cầu INVITE thì transaction đó cũng bao gồm cả bản tin ACK nếu như phản hồi cuối không phải là kiểu 2xx. Nếu như thông tin phản hồi cuối là kiểu 2xx thì bản tin ACK sẽ không được xem là một thành phần trong transaction. Như vậy chúng ta có thể thấy rằng ở đây có sự cư xử không được công bằng – ACK được coi là một thành phần trong transaction với một lời từ chối ở phản hồi cuối, trong khi nó lại không phải là một thành phần của transaction khi được chấp nhận ở phản hồi cuối. Lý do cho sự phân biệt này là sự quan trọng của tất cả cả các bản tin 200 OK. Không những nó thiết lập một session mà bản tin 200 OK còn được sinh ra bởi các thực thể khi một proxy server chuyển hướng yêu cầu và tất cả các proxy server đó phải chuyển bản tin 200 OK về đến User agent. Do đó trong trường hợp này user agent phải lãnh trách nhiệm và truyền lại bản tin 200 OK cho đến khi chúng nhận được bản tin ACK. Một lưu ý khác nữa là chỉ có bản tin INVITE là được truyền lại. Các thực thể SIP có khái niệm về transaction được gọi là stateful. Các thực thể này tạo một trạng thái kết nối với một transaction được lưu trong bộ nhớ trong suốt khoảng thời gian diễn ra transaction. Khi có thông tin yêu cầu hay phản hồi đến, một thực thể stateful sẽ cố gắng kết nối yêu cầu(hoặc phản hồi) đó tới một transaction đã tồn tại sẵn. Để có khả năng làm được điều đó nó phải lấy thông tin xác định tính duy nhất của transaction(gọi là identifier) trong bản tin đó và so sánh với tất cả các identifier trong các transaction mà nó lưu giữ. Nếu như một transaction tồn tại thì trạng thái của nó sẽ được cập nhật từ bản tin đó. Hình 9. SIP transaction Dialog(Hội thoại) Ở trên chúng ta đã được biết đến transaction, đó là một transaction bao gồm bản tin INVITE và các bản tin phản hồi, một transaction khác bao gồm bản tin BYE và thông tin phản hồi(200 OK) khi một phiên làm việc kết thúc. Nhưng chúng ta có thể thấy rằng cả 2 transaction này có liên quan đến nhau và cùng thuộc một hội thoại(dialog). Một dialog đặc trưng cho mối quan hệ SIP ngang hàng giữa 2 user agent. Một dialog tồn tại trong một khoảng thời gian và nó là một khái niệm rất quan trọng đối với các user agent. Dialog thích hợp dễ dàng với việc sắp xếp tuần tự và định tuyến cho các bản tin SIP giữa các thiết bị cuối. Dialog được xác định bằng Call-ID, thẻ From và thẻ To. Các bản tin mà có cùng 3 identifier trên thì thuộc về cùng một dialog. Trường header Cseq được dùng để sắp xếp thứ tự các bản tin trong một dialog. Chỉ số Cseq phải được tăng tuần tự từng đơn vị một cho mỗi bản tin trong một dialog, nếu không các user agent sẽ xử lý nó như là các yêu cầu không được sắp xếp hoặc là sẽ gửi lại bản tin đó. Trong thực tế số Cseq xác định một transaction bên trong một dialog bởi chúng ta đã nói ở trên là các yêu cầu và các thông tin phản hồi của nó được gọi là một transaction. Điều đó có nghĩa là chỉ có duy nhất một transaction hoạt động tại một thời điểm trong dialog. Do đó cũng có thể gọi dialog là một tập tuần tự của các transaction. Hình vẽ dưới đây minh họa các bản tin truyền đi bên trong một dialog. Hình 10. Luồng cuộc gọi trong một Dialog SIP Một vài bản tin dùng để thiết lập ra một dialog. Nó cho phép biểu diễn rõ ràng, chi tiết mối quan hệ giữa các bản tin và còn dùng để gửi các bản tin mà không liên quan đến các bản tin khác đến các bản tin nằm ngoài một dialog. Điều đó được thực hiện một cách dễ dàng bởi user agent không lưu trạng thái của dialog. Lấy ví dụ, bản tin INVITE thiết lập một dialog, bởi sau đó sẽ có bản tin yêu cầu BYE dùng để kết thúc dialog tạo ra bởi bản tin INVITE ở trên. Bản tin BYE này được gửi bên trong dialog được thiết lập bởi bản tin INVITE. Nhưng nếu user agent gửi một bản tin yêu cầu MESSAGE, đó là một yêu cầu không thiết lập bất cứ dialog nào. Khi đó bất cứ các bản tin theo sau bản tin đó (kể cả bản tin MESSAGE) cũng được gửi đi một cách độc lập với bản tin trước đó. Dialog Facilitate Routing (Định tuyến dễ dàng dialog) Ở trên chúng ta đã nói rằng dialog còn dùng để định tuyến bản tin giữa các user agent, vậy hãy mô tả nó chi tiết hơn ở đây. Giả sử rằng người dùng sip:bob@a.com muốn nói chuyện với sip:pete@b.com. Anh ta biết địa chỉ SIP của anh kia (sip:pete@b.com) nhưng địa chỉ này không định vị được vị trí hiện thời của anh Pete này, do vậy Pop không biết gửi yêu cầu này đến host nào để xử lý. Do vậy bản tin INVITE sẽ được gửi đến một proxy server. Yêu cầu này sẽ được gửi từ proxy server này đến proxy server khác cho đến khi nào nó tới được một proxy server mà biết được vị trí hiện thời của Pete. Quá trình xử lý đó được gọi là định tuyến. Một khi yêu cầu được chuyển tới người được gọi, user agent ở phía người được gọi sẽ tạo bản tin phản hồi gửi ngược trở lại cho người gọi. User agent phía người được gọi cũng đồng thời đặt trường header Contact vào trong bản tin phản hồi – nó chứa vị trí hiện thời của người được gọi. Bản tin yêu cầu gốc cũng chứa trường header Contact, do vậy cả 2 đều biết được vị trí của nhau. Bởi vì cả 2 đều đã biết được vị trí của nhau nên không cần thiết phải gửi các bản tin sau qua các proxy đó nữa mà nó có thể gửi trực tiếp giữa 2 user agent với nhau. Đó chính là cách định tuyến trong dialog. Các bản tin sau bên trong dialog được gửi trực tiếp giữa 2 user agent, điều đó làm tăng đáng kể hiệu năng bởi khi đó chỉ phải gửi duy nhất bản tin đầu tiên (bản tin INVITE) qua các proxy, còn các bản tin sau được gửi trực tiếp giữa các user agent. Hình vẽ dưới đây minh họa một bản tin bên trong một dialog (bản tin BYE) được truyền trực tiếp không qua các proxy. Hình 11. Định tuyến dễ dàng trong dialog Dialog Identifiers (Các định danh xác định một Dialog) Chúng ta đã chỉ ra ở trên các định danh dùng để xác định một dialog. Đó là Call-Id, thẻ From và thẻ To, nhưng chưa hiểu rõ cách thức làm sao mà các định danh trên được tạo ra và sự đóng góp của từng thành phần đó vào việc định danh một Dialog. Call-ID còn được gọi là call identifier(định danh cuộc gọi). Nó phải là một chuỗi ký tự duy nhất dùng để định danh một cuộc gọi. Một cuộc gọi có thể có một hoặc nhiều dialog. Nhiều user agent có thể phản hồi cho một yêu cầu khi một proxy là một nút trong tuyến đường mà yêu cầu đi qua(định tuyến cho bản tin trình bày ở phần trên). Mỗi một user agent gửi bản tin dạng 2xx để thiết lập một dialog riêng với người gọi(ví dụ như trong ứng dụng hội thảo conference khi có nhiều hơn 2 người tham gia vào). Tất cả các dialog đó đều là một thành phần trong cùng một cuộc gọi và cùng có số Call-ID giống nhau. Thẻ From được sinh ra bởi người gọi và nó dùng để phân biệt các dialog ở phía user agent của người gọi. Thẻ To được sinh ra bởi người được gọi và nó cũng được định danh một cách duy nhất, giống như thẻ From, thẻ To dùng để định danh ở phía user agent của người được gọi. Việc phân cấp định danh như trên là cần thiết bởi vì một lời mời trong cuộc gọi có thể tạo ra vài dialog và người gọi cần phải biết phân biệt các dialog đó(ví dụ về hội thảo như trên). Các giao thức liên quan đến giao thức SIP SDP ( Session Description Protocol) SDP - Giao thức mô tả phiên, được định nghĩa bởi RFC 2327 và được phát triển bởi IETF MMUSIC. Nó giống cú pháp mô tả hơn là một giao thức . Nó ở ngay trên SIP trong chồng giao thức và được mang ở trong bản tin SIP. Mục đích gốc của SDP là thực hiện các phiên multicast được thiết lập trên mạng đường trục Internet. SDP có thể mang các thông tin sau trong phiên giao dịch của mình: địa chỉ IP, số hiệu port(được sử dụng bởi UDP hay TCP), loại phương tiện kết nối(audio , video…),cơ cấu mã hoá( PCM luật A, Mpeg 3,….). Ngoài ra nó còn có thể mang một số thông tin khác như: tiêu đề phiên , thời gian bắt đầu và kết thúc, thông tin về địa chỉ trong phiên. Hình vẽ 2.7 sẽ chỉ ra mô hình chồng giao thức đa phương tiện giúp ta thấy được vị trí của từng giao thức tương ứng theo mô hình TCP/IP Hình 12.Mô hình chồng giao thức multimedia RTP ( Real Time Transport Protocol) Được dùng làm giao thức hỗ trợ trong ứng dụng thời gian thực như: thoại , video… RTP sử dụng UDP để vận chuyển trong mạng IP vì vậy độ trễ nhỏ . RTP cung cấp các dịch vụ sau: Phân biệt giữa những người gửi trong một luồng RTP multicast. Bảo vệ mối quan hệ định thời giữa các gói. Cho phép đồng bộ về mặt định thời giữa các môi trường truyền dẫn. Đánh số chuỗi đối với dữ liệu để nhận diện các gói bị mất. Nhận dạng kiểu môi trường truyền dẫn. Không cung cấp hoặc đảm bảo về QoS. RCTP (Real Time Control Protocol) RTCP bổ sung cho RTP bằng cách xử lý các khía cạnh về quản trị và báo cáo cho một RTP multicast. RTCP được xác định trong RFC 1889 như là một phần của RTP. Các chức năng chính RTCP thực hiện bao gồm: Báo cáo về người gửi (SR: Sender Report) và báo cáo về người nhận (RR: Receiver Report). Mô tả nguồn (SDES: Source Description). Ngắt kết nối (Bye) Xác định ứng dụng (App): cho phép các thử nghiệm và các mở rộng đối với giao thức này mà không yêu cầu các kiểu gói mới được đăng ký với một kiểu payload/packet. Một vài kịch bản SIP đặc biệt Registration(đăng ký) Người dùng cần phải đăng ký với một registrar server để các user khác có thể xác định được vị trí. Một phiên đăng ký bao gồm bản tin REGISTER theo sau là bản tin 200 OK được gửi bởi registrar nếu như quá trình đăng ký thành công. Quá trình đăng ký thường yêu cầu chứng thực, do vậy một bản tin phản hồi 407 có thể xuất hiện nếu như người dùng không cung cấp chính xác các thông tin xác thực (vaid credentials). Hình 13. Luồng trong một giao dịch đăng ký Session Invitation Một phiên gọi chứa một bản tin yêu cầu INVITE, thông thường bản tin này được gửi đến một proxy. Proxy ngay lập tức gửi bản tin phản hồi 100 Trying để user agent không gửi lại bản tin INVITE và chuyển tiếp yêu cầu đi. Mọi thông tin phản hồi tạm thời được sinh ra bởi user agent phía người được gọi được gửi ngược lại cho người gọi. Bản tin 180 Ringing được gửi đi khi chuông phía người được gọi kêu. Hình 14. Luồng giao dịch INVITE khởi tạo cuộc gọi Một bản tin 200 OK được sinh ra khi người được gọi nhấc máy và được gửi lại bởi user agent phía người được gọi cho đến khi nhận được bản tin ACK phía người gọi thông báo là đã nhận được lời chấp thuận cuộc gọi của người được gọi(giống quá trình bắt tay 3 bước trong giao thức HTTP). Phiên cuộc gọi được thiết lập bắt đầu từ thời điểm này. Session Termination Kết thúc một phiên gọi điện được hoàn thành bằng việc gửi đi bản tin yêu cầu BYE bên trong dialog được thiết lập bởi bản tin INVITE trước đó. Bản tin BYE được gửi trực tiếp giữa 2 user agent mà không thông qua proxy, chỉ trừ trường hợp proxy chỉ ra rằng nó muốn tham gia vào việc truyền các bản tin thông qua Record Routing(đăng ký định tuyến – dùng trong một số trường hợp đặc biệt, như khi phải vượt qua NAT hoặc dùng trong trường hợp tính cước phí cuộc gọi,…). Một trong các bên tham gia vào phiên cuộc gọi muốn kết thúc cuộc gọi gửi đi bản tin BYE đến các bên còn lại. Các bên còn lại gửi bản tin 200 OK phản hồi lại để xác nhận việc chấp thuận việc kết thúc phiên và phiên cuộc gọi kết thúc. Instant Messages(bản tin chat) Instant messages được gửi thông qua bản tin yêu cầu MESSAGE. Bản tin MESSAGE không thiết lập dialog, do đó nó sẽ phải truyền qua các proxy trong suốt quá trình gửi(không giống như các bản tin trong dialog, chỉ duy nhất bản tin INVITE là phải truyền qua proxy). Nội dung của bản tin MESSAGE được đặt trong phần thân (body) của bản tin SIP Hình 15. Luồng bản tin Instant Message trong SIP KIẾN TRÚC CỦA SER (IS-CC) Trong chương này: Chức năng của SER Đặc điểm của SER Cấu trúc bên trong Cách thức hoạt động Cấu trúc module Cách cấu hình SER SER (IS-CC) Được xây dựng với chức năng chính phục vụ cho việc điều khiển cuộc gọi và báo hiệu. Nó có thể thiết lập các cuôc gọi đơn giản giữa hai user agent hoặc chuyển cho SEMS (IS-ME) xử lý đối với các yêu cầu về media như Conferencing, IVR, VoiceMail .. Chức năng Thực hiện chức năng điều khiển cuộc gọi và báo hiệu Bao gồm các modules: Registrar server, Location server (Location Database), Proxy server và Redirect server Có khả năng làm việc dưới cả hai hình thức xử lý các cuộc gọi đa phương tiện: Stateless và Statefull Giao diện quản lý thông qua FIFO File và UNIX Socket Giao tiếp với SEMS thông qua UNIX Socket Chức năng nhận thực và tính cước (AAA - Authentication Authorization and Accounting) bằng nhiều hình thức: thông qua CSDL (MySQL), hoặc giao thức RADIUS và DIAMETER Kết nối với mạng PSTN đơn giản thông qua các Gateway Đặc điểm Tốc độ: Với SER, hàng nghìn cuộc gọi trên giây có thể thực hiện được trên các platform khác nhau với giá thấp. Khả năng cạnh tranh này cho phép thiết lập mạng không tốn kém và dễ dàng quản lý với số lượng các thiết bị thấp, khả năng xử lý dễ dàng các tình huống stress. Tính linh hoạt: SER cho phép các user có thể định nghĩa được các hoạt động của nó.Người quản trị có thể viết các script dưới dạng text để quyết định việc định tuyến bản tin SIP, công việc chính của một proxy server. Họ có thể sử dụng các script này để thiết lập rất nhiều các parameter. Ví dụ , đoạn script có thể xác định đích đến nào tiếp theo cho bản tin SIP, ai sẽ phải nhận thực, transaction nào sẽ được xử lý theo kiểu stateful, yêu cầu nào được redirect?... Có khả năng mở rộng: Khả năng mở rộng của SER cho phép ghép các code C mới vào SER để định nghĩa lại hay mở rộng tính logic của nó. Các code mới này có thể được phát triển một cách độc lập với phần core của SER và nối với nó khi chạy. Plug&Play modules Khả năng thao tác với các hệ thống khác(Interoperability): SER dựa trên chuẩn SIP mở rộng. Nó đã được thử nghiệm và hoạt động tốt với những sản phẩm của các hãng khác nhau (SER có thể dùng để làm một SIP Server cho hệ thống Asterisk). Kích thước nhỏ: Kích thước của phần core là 300k, các module thêm vào khoảng 630k. Chạy trên hệ điều hành LINUX. Hiện thời SER đã được thêm vào các gói package chuẩn trong hệ điều hành Debian (từ bản 3.1 trở lên). Có thể dễ dàng cài đặt SER bằng cách download bản dịch sẵn của SER về cài đặt. Cấu trúc bên trong SER Gồm hai phần : core và module Hình 16. Cấu trúc SER Chú thích: FIFO Interface: giao tiếp FIFO Message Processing: xử lý các bản tin SIP Parse: lấy ra các tham số trong bản tin SIP Routing Engine: định tuyến cho bản tin Module Interface: giao tiếp với các module ngoài phần Core Memory Management: quản lý bộ nhớ Timer: xử lý các sự kiện được đặt trước, có thể cấu hình được Server Loader(Flex, Yacc): Flex và Yacc là 2 ứng dụng dùng đọc file cấu hình để lấy gia các tham số cấu hình. Cách Thức hoạt động của SER Khởi động Server Hàm main trong file main.c là hàm đầu tiên được gọi khi server được khởi động.Mục đích của nó là để khởi tạo server và vào vòng lặp chính. Khởi tạo server Cài đặt phần xử lý các tín hiệu (sig_usr trong main.c) Bước đầu tiên trong quá trình khởi tạo đó là cài đặt phần xử lý các tín hiệu.( Chỉ có duy nhất hàm xử lý các tín hiệu trong hàm sig_usr trong file main.c) Hàm trên xử lý các tín hiệu sau : SIGINT, SIGPIPE, SIGUSR1, SIGCHLD, SIGTERM,SIGHUP và SIGUSR2. Xử lý các parameter trong câu lệnh SER tích hợp hàm getopt để phân tích các parameter trong câu lệnh Khởi tạo parser Khởi tạo khối parser có chức năng đọc và phân tích cấu trúc của bản tin SIP. Khởi tạo Malloc Để cho SER chạy nhanh hơn chúng ta bổ sung thêm thủ tục cấp phát bộ nhớ. Phải được khởi tạo trước khi bất kì một hàm nào được gọi Quá trình khởi tạo chủ yếu là để tạo ra cấu trúc dữ liệu bên trong và cấp phát bộ nhớ Khởi tạo bộ Timer( timer.c, hàm init_timer từ main.c) Nhiều hệ chương trình của server phải được gọi một cách định kì không phụ thuộc vào các request đầu vào.