Gi i thi u
Ngày nay, chúng ta sống trong một thế giới mà Internet và email phát triển mạnh mẽ Hai hình thức giao tiếp phổ biến hiện nay là giao tiếp truyền thống và giao tiếp qua siêu văn bản.
(Hypertext Transfer Protocol) và giao th c truy n t i th đ n gi n (Simple Mail Transfer
Giao thức khởi tạo phiên (Session Initiation Protocol - SIP) đã được quy định để đáp ứng nhu cầu truyền thông đa phương tiện ngày càng đa dạng và yêu cầu kết nối trực tiếp với người dùng ngày càng cao Sự phát triển này cho thấy tầm quan trọng của việc có một giao thức hiệu quả để đảm bảo khả năng giao tiếp liên tục và linh hoạt.
Ph m vi và m c tiêu c a khóa lu n
Giao thức SIP (Session Initiation Protocol) được triển khai vào cuối những năm 1990 và đã nhanh chóng phát triển, được cài đặt trong các phần cứng, ngữ dụng, điện thoại thông minh và các dịch vụ trực tuyến Tuy nhiên, SIP không phải là giải pháp cho mọi vấn đề giao tiếp truyền thông Do đó, việc triển khai và cài đặt mạng lưới sử dụng SIP cần phải hiểu rõ bản chất của giao thức này Khóa học luôn tập trung vào việc tìm hiểu và phân tích giao thức SIP để làm rõ các khái niệm nền tảng, hoạt động, nguyên lý và chức năng của SIP.
Ngoài ra, khóa lu n còn đ c p đ n m t vài giao th c th ng đ c s d ng cùng v i giao th c SIP
Trên c s nh n th c đ c b n ch t, ho t đ ng c a giao th c, chúng em s xây d ng ng d ng l p h c t xa có cài đ t giao th c SIP đ n m v ng và hi u rõ h n các v n đ c a giao th c.
N i dung khóa lu n
- Ph n I: T ng quan Gi i thi u v đ tài, ph m vi và m c tiêu c a khóa lu n
Phần II của bài viết tập trung vào cơ sở lý thuyết về giao thức SIP, bao gồm việc tìm hiểu các vấn đề liên quan đến giao thức này Chương 1 cung cấp cái nhìn tổng quan về SIP, giới thiệu khái niệm, các thực thể và chức năng cần thiết của giao thức Trong khi đó, Chương 2 đi sâu vào phương thức hoạt động, phân tích các thông điệp, các header và các đặc điểm chính để hiểu rõ hơn về hoạt động của giao thức SIP.
Chương 3 tập trung vào cấu trúc và phân tích mô hình giao thức SIP cùng các lớp trong mô hình này Chương 4 giới thiệu về Giao thức mô tả phiên (Session Description Protocol), cung cấp cái nhìn tổng quan về cách thức giao tiếp trong một phiên Chương 5 trình bày về JAIN SIP API, giới thiệu các khía cạnh quan trọng của giao diện lập trình ứng dụng SIP Cuối cùng, Chương 6 đề cập đến Java Media Framework API, giải thích cách sử dụng JMF để phát triển các chức năng đa phương tiện hiệu quả.
- Ph n III: Thi t k , xây d ng h th ng ng d ng l p h c t xa
- Ph n IV: T ng k t T ng k t, đánh giá và đ ngh các h ng nghiên c u, phát tri n trong t ng lai
CH NG 1: T NG QUAN V SIP
Khái ni m SIP
SIP
Giao thức khởi tạo phiên (Session Initiation Protocol - SIP) là một giao thức báo hiệu được định nghĩa bởi IETF (Internet Engineering Task Force) và được sử dụng rộng rãi để thiết lập và điều khiển các phiên truyền thông qua giao thức Internet (IP) Một phiên truyền thông là sự trao đổi dữ liệu giữa các bên tham gia SIP có khả năng thiết lập, sửa đổi và kết thúc các phiên truyền thông đến một điểm (unicast) hoặc nhiều điểm (multicast), tương ứng với cuộc gọi điểm-điểm và cuộc gọi đa điểm.
SIP là giao th c l p ng d ng đ c thi t k đ làm vi c đ c l p v i t ng transport bên d i nên nó có th ch y trên các giao th c TCP, UDP, ho c SCTP
SIP là giao th c d ng ch và s d ng nhi u thành ph n t ng t nh trong giao th c HTTP và SMTP
SIP (Session Initiation Protocol) được sử dụng trong giao tiếp ngang hàng (peer-to-peer), nhưng hoạt động theo mô hình client-server tương tự như giao thức HTTP Trong mô hình này, SIP client gửi yêu cầu đến SIP server, trong khi SIP server xử lý và gửi phản hồi lại cho client.
Giao thức báo hiệu (SIP) không chỉ là giao thức truyền tải nội dung truyền thông, mà còn tích hợp với nhiều giao thức khác như Real-time Transport Protocol (RTP), Real-Time Streaming Protocol (RTSP), Media Gateway Control Protocol (MEGACO), và Session Description Protocol (SDP) Tuy nhiên, chức năng và hoạt động cơ bản của SIP không phụ thuộc vào các giao thức này.
T i sao dùng SIP?
Trong lĩnh vực truyền thông, giao thức SIP (Session Initiation Protocol) đã trở thành một lựa chọn phổ biến bên cạnh giao thức H.323 H.323 chủ yếu được sử dụng cho truyền thông thời gian thực qua mạng (VOIP) và hội nghị video Mặc dù H.323 đã được áp dụng rộng rãi, SIP vẫn nổi bật với những ưu điểm vượt trội, đặc biệt là về tính linh hoạt và khả năng mở rộng, khiến cho nó trở thành một sự thay thế hấp dẫn cho H.323 trong các ứng dụng truyền thông hiện đại.
16 các ng d ng đang d n chuy n sang s d ng SIP B ng 1.1 so sánh gi a giao th c SIP và
Phát tri n b i IETF Phát tri n b i ITU
Tính đ n gi n và m Ph c t p và c ng nh c
S d ng các đ i t ng m ng có s n nh URL,
T đ c t t t c các đ i t ng nó s d ng k c b codec cho media và vi c truy n gói RTP nh d ng ch đ c đ c nh d ng chu i nh phân tr nh tr có th đ n 7-8 giây
CPU x lý thông đi p nh h n CPU x lý nhi u
X lý nhi u phiên h n X lý ít phiên h n
H tr đi u khi n bên th 3 (Third-party
Thu t toán ch ng l p hi u qu h n Thu t toán ch ng l p đ n gi n trong phiên b n
B ng 1.1: So sánh gi a SIP và H.323
a ch SIP
Trong kiến trúc SIP, người dùng thường xác định bằng cách sử dụng một địa chỉ đa ch SIP, gọi là SIP URI (Universal Resource Identifier) SIP URI có vai trò quan trọng trong việc xác định các nguồn tài nguyên truyền thông.
Ví d : sip:khoa.luong@ou.edu.vn
URI SIP bắt đầu bằng “sip:” hoặc “sips:” và được phân tách bằng ký tự ‘@’ Phần trước dấu ‘@’ là phần người sử dụng tùy chọn, xác định tài nguyên trên máy chủ Phần sau dấu ‘@’ bao gồm host và port, xác định nguồn cung cấp tài nguyên, có thể là một tên miền đầy đủ (FQDN) hoặc một địa chỉ IP.
SIP URI có cấu trúc bao gồm các thành phần như user, password, host, port và các tham số uri, ảnh hưởng đến yêu cầu Các tham số này được thêm vào sau phần host và port, và được ngăn cách bằng dấu chấm phẩy Cấu trúc đầy đủ của một SIP URI có thể được biểu diễn như sau: sip:user:password@host:port;uri-parameters?headers.
Thông tin người dùng và mật khẩu chỉ có giá trị khi máy chủ đích không có người dùng hoặc chính máy chủ đó là tài nguyên xác định, và trong trường hợp này sẽ không có dấu “@” Mật khẩu là một khóa của người dùng tương ứng Tuy nhiên, không nên sử dụng mật khẩu trong SIP URI vì mật khẩu sẽ xuất hiện dưới dạng văn bản rõ ràng, do đó là một lỗ hổng bảo mật Các headers là các tiêu đề gửi kèm theo yêu cầu, được phân cách với phần máy chủ và cổng bằng dấu “?”.
SIP sử dụng các URI để xác định tài nguyên, tạo ra một điểm đến cho các dịch vụ truyền thông Điều này cho phép tích hợp các dịch vụ Internet khác như email và web với các dịch vụ truyền thông SIP, nâng cao khả năng giao tiếp và tương tác trên nền tảng trực tuyến.
Ch c n ng
Kh i t o, hi u ch nh và k t thúc phiên
Nh tên g i c a giao th c là kh i t o phiên truy n thông đa ph ng ti n, cho phép ng i dùng tham gia và yêu c u m i phiên truy n thông Ng i dùng có th g i ng c l i nh n l i m i b ng cách g i tr l i ch p nh n.
SIP còn đ c s d ng đ hi u ch nh, thay đ i các tham s c a phiên đang ho t đ ng ví d , đ thêm m t thành ph n media m i vào trong phiên
Cu i cùng là k t thúc phiên Ng i dùng g i yêu c u k t thúc phiên và xác nh n k t thúc phiên b ng tr l i ch p nh n.
Xác đ nh v trí c a ng i dùng
Trong mạng IP, các gói tin được định tuyến đến địa chỉ IP Người sử dụng SIP không biết địa chỉ IP của đối phương mà chỉ biết địa chỉ public thông qua SIP URI Người dùng SIP có thể sử dụng SIP trên nhiều loại thiết bị khác nhau như PC, laptop, hoặc điện thoại di động, và mỗi thiết bị này có một địa chỉ IP riêng biệt.
Do đó, cần có một hệ thống có thể nhận diện địa chỉ IP của người dùng, ánh xạ nó vào địa chỉ công cộng và lưu trữ thông tin đó vào một bảng Trong quá trình thiết lập phiên, cần truy vấn đến bảng thông tin để đảm bảo địa chỉ IP được sử dụng đúng đắn cho các gói tin đến.
Để sử dụng SIP, người dùng cần đăng ký với một máy chủ SIP (Registrar) bằng cách cung cấp địa chỉ IP hiện tại và địa chỉ công cộng của mình Việc đăng ký này cho phép người dùng nhận các cuộc gọi đa phương tiện, và máy chủ sẽ cập nhật địa chỉ vào cơ sở dữ liệu của nó.
Các th c th
User Agent
Trong giao thức SIP, User Agent (UA) là thành phần đầu cuối quan trọng, có nhiệm vụ tạo và quản lý các phiên làm việc thông qua việc gửi yêu cầu và nhận phản hồi Một SIP UA bao gồm hai phần chính: User Agent Client (UAC) và User Agent Server (UAS) UAC chịu trách nhiệm gửi yêu cầu SIP và nhận các phản hồi tương ứng, trong khi UAS có nhiệm vụ nhận yêu cầu và tạo ra các phản hồi thích hợp.
Registrar
Registrar là máy chủ chịu trách nhiệm tiếp nhận yêu cầu đăng ký từ các User Agents (UA) Mỗi UA cần phải đăng ký với registrar trước khi có thể thực hiện cuộc gọi đến một địa chỉ khác Khi registrar nhận yêu cầu đăng ký, nó sẽ lưu trữ thông tin nhận được vào cơ sở dữ liệu được gọi là Location Service.
Location Service không phải là một thực thể SIP, mà là một cơ sở dữ liệu chứa danh sách các ánh xạ giữa Address of Record (AORs) và địa chỉ liên lạc (Contact Address) tương ứng với vị trí của người dùng AORs và Contact Address được thể hiện dưới dạng SIP URI Khi registrar nhận được yêu cầu đăng ký từ một UA, nó sẽ cập nhật Location Service với các thông tin đã nhận.
− Location Service này c ng đ c truy v n b i các proxy server c a m t mi n đ có đ c thông tin v các đ a ch có th có c a ng i s d ng
− Trong nhi u hi n th c cài đ t, Location Service và SIP server đ c đ t trên cùng m t h th ng
Hình 1.2: Ho t đ ng c a Registrar và Location Service
Proxy
Proxy là m t th c th trung gian v a ho t đ ng nh client v a ho t đ ng nh server
Nó chủ yếu đóng vai trò như một router, với chức năng chính là gửi các yêu cầu đến đích hoặc đến các proxy khác gần đích hơn Proxy cũng thực hiện nhiệm vụ áp dụng chính sách, ví dụ như cho phép ai được thực hiện cuộc gọi Proxy sẽ xử lý và thay đổi một số phần của yêu cầu trước khi chuyển tiếp nếu cần thiết.
Có hai loại Proxy trong UAC và UAS để định tuyến các thông điệp SIP, bao gồm outbound proxy và inbound proxy.
− Outbound Proxy: giúp các UA đnh tuy n các yêu c u đi ra Các UA th ng đ c c u hình đ đnh tuy n t t c các yêu c u đ n outbound proxy
− Inbound Proxy: là m t proxy server x lý các yêu c u đi vào mi n mà nó qu n lý
CBN giúp định tuyến các yêu cầu đến các UA trong miền Khi một inbound proxy nhận yêu cầu từ người dùng trong miền quản lý, proxy sẽ truy vấn Location Service để lấy địa chỉ của UA đó và chuyển tiếp yêu cầu đến địa chỉ đã lấy.
Outbound and inbound proxies are essential components within a system that also includes a registrar, often functioning alongside a SIP server These proxies can be categorized based on their operation into two types: stateless proxies and stateful proxies.
Proxy không trạng thái là một loại proxy nhận và xử lý dữ liệu từ thông điệp, sau đó chuyển tiếp thông tin mà không lưu giữ bất kỳ trạng thái hay thông tin nào từ các thông điệp đó Nhờ vào việc không lưu trữ, proxy không trạng thái hoạt động rất nhanh chóng và hiệu quả.
Stateful proxy là một loại proxy lưu trữ thông tin về kết nối và liên kết với các phiên làm việc Nó hỗ trợ các chức năng như kết nối TCP, truyền phát đa điểm multicast và forking, giúp cải thiện hiệu suất và quản lý lưu lượng mạng hiệu quả hơn.
Back-to-back User Agent
B2BUA (Back-to-Back User Agent) là một cơ chế quản lý hoạt động như một UA (User Agent) đối với hai đầu của phiên giao tiếp Nó có nhiệm vụ điều khiển việc truyền tín hiệu SIP giữa hai đầu, từ khi bắt đầu đến khi kết thúc phiên B2BUA nhận yêu cầu và xử lý như một UAS (User Agent Server), đồng thời quyết định cách thức phản hồi yêu cầu, đóng vai trò như một UAC (User Agent Client) để tạo ra các yêu cầu Khác với proxy server, B2BUA duy trì trạng thái của phiên và tham gia vào tất cả các yêu cầu được gửi trong phiên.
M t B2BUA đ c c u thành b i hai UA đ c liên k t v i nhau qua m t h lu n lí
Nó đ c s d ng nh server đ cung c p các ch c n ng nâng cao b ng cách đi u khi n tín hi u trong cu c g i ho c các th c th trong m ng
B2BUA hoạt động trên hai chế độ: chế độ định tuyến và chế độ khởi tạo Ở chế độ định tuyến, nó nhận một yêu cầu khởi tạo phiên, áp dụng một số logic và tạo một cuộc gọi mới Trong chế độ khởi tạo, nó khởi tạo hai cuộc gọi khác nhau và duy trì liên kết tín hiệu giữa chúng.
Hình 1.3: Back-to-back user agent
CH NG 2: PH NG TH C HO T NG SIP
SIP ho t đ ng d a trên vi c trao đ i các thông đi p (message) Thông qua vi c trao đ i Message, client và server thi t l p, ch nh s a và k t thúc các phiên làm vi c.
SIP Message
Tin nhắn SIP (Session Initiation Protocol) là yêu cầu từ client gửi đến server hoặc phản hồi từ server gửi đến client Một tin nhắn SIP bắt đầu với một dòng đầu tiên, tiếp theo là nhiều vùng header, sau đó là một dòng trống để đánh dấu sự kết thúc của các vùng header, và cuối cùng là phần nội dung (Message body).
Ví d sau là thông đi p đ ng ký client g i cho server:
Hình 2.1: C u trúc thông đi p SIP
SIP request
Các Sip Request c b n
UA g i REGISTER thực hiện việc đăng ký với Registrar UA đăng ký đa địa chỉ công cộng cùng với đa địa chỉ IP, đồng thời gửi đi địa chỉ SIP URI cho Registrar Các địa chỉ này được lưu trữ trong Dịch vụ Vị trí.
Tùy thu c vào Contact header và Expire header mà Registrar x lý th t c đ ng kí
Nếu không có tham số "expires" trong request line và không có header "Expire", SIP URI sẽ hết hạn trong 1 giây Nếu có tham số "expires", thì không có header "Expire" và ngược lại Các header khác cũng cần được xem xét.
− Request-URI ch a đa ch c a registrar
− To header ch a Address of Record c a user
− From header ch a SIP URI c a ng i g i yêu c u, th ng là gi ng v i To header
− Call-ID header nên gi ng nhau v i m i th t c đ ng kí
Các header khác nhau đ c s d ng khác nhau tùy t ng lo i request
N u th t c đ ng kí thành công registrar s tr l i b ng thông đi p 200 OK Ng c l i g i tr l i chuy n h ng 3xx ho c th t b i 4xx
Hình 2.2: Ho t đ ng đ ng ký b INVITE:
Sử dụng phương thức INVITE trong giao thức SIP cho phép gửi yêu cầu đến các UA (User Agents) khác nhau Yêu cầu này nhằm mục đích thiết lập kết nối với UA đích thông qua địa chỉ Request-URI, có thể được truyền trực tiếp từ UAC (User Agent Client) đến UAS (User Agent Server) hoặc đi qua một hoặc nhiều proxy.
Trong giao thức SIP, thông tin về phiên và người gọi được lưu trữ trong thân thông điệp Một phiên được coi là thiết lập khi các thông điệp INVITE – 200 OK – ACK được trao đổi giữa UAC và UAS Khi một phiên được thiết lập, một mối quan hệ ngang hàng giữa hai UA sẽ được tạo ra gọi là Dialog INVITE là lệnh duy nhất có khả năng tạo Dialog, nhưng trong phần mở rộng của SIP cũng có một số giao thức khác có thể tạo Dialog Phiên kết thúc khi một trong hai bên gửi yêu cầu BYE.
UAC gửi INVITE để thiết lập một dialog, sử dụng Call-ID duy nhất cho cuộc gọi Header To và From chứa thông tin của bên nhận và bên gửi UAC sẽ thêm vào tag From, trong khi UAS sẽ thêm vào tag To Call-ID, tag From và tag To được sử dụng để xác định Dialog.
Hình 2.3: Ho t đ ng kh i t o phiên truy n thông
N u UA2 không ch p nh n l i m i, thì s g i tr l i 487
Yêu cầu INVITE có thể được gửi trong phiên đã thiết lập hoặc trong Dialog Trong trường hợp này, yêu cầu INVITE đó được gọi là re-INVITE Re-INVITE được sử dụng để điều chỉnh các thông số của phiên hoặc làm mới trạng thái của Dialog Nếu re-INVITE bị từ chối, thì phiên đã thiết lập vẫn tiếp tục hoạt động.
Dùng đ thông báo nh n đ c final response t ng đ tin c y khi dùng UDP d CANCEL:
Dùng đ h y yêu c u đang ch tr l i Ví d , UA dùng CANCEL đ h y yêu câu INVITE, proxy dùng CANCEL đ h y các yêu c u đ n các UA trong quá trình forking e CANCEL:
Trong quá trình xử lý yêu cầu, nếu UA1 muốn kết thúc yêu cầu, nó sẽ gửi yêu cầu CANCEL Nếu UA2 nhận được yêu cầu CANCEL, nó sẽ trả về 200 OK để xác nhận yêu cầu hủy và trả về 487 để thông báo rằng quá trình khởi tạo phiên làm việc đã bị hủy.
Cu i cùng UA1 s g i ACK Request thông báo k t thúc quá trình INVITE (hình 2.4)
Hình 2.4: H y l i m i f BYE: c s d ng đ ch m d t phiên truy n thông
Để truy vấn chức năng của UA hoặc server, cần lấy thông tin về các chức năng hiện tại, bao gồm thông tin về phương thức hỗ trợ, kiểu nội dung, mã hóa, các bộ codec, và hơn thế nữa Proxy không tạo yêu cầu OPTIONS, mà chỉ nhận hoặc chuyển đến proxy khác.
Các Sip Request m r ng
Trong giao thức SIP, header Refer-To được sử dụng khi một User Agent (UA) muốn yêu cầu một UA khác truy cập vào một địa chỉ cụ thể Địa chỉ này có thể là một SIP URI hoặc một trang web Nếu yêu cầu này được chấp nhận, UA sẽ nhận được phản hồi 202 Accepted Đối với yêu cầu SUBSCRIBE, khi một UA muốn nhận thông báo về các sự kiện mong muốn xảy ra, nó sẽ gửi một SUBSCRIBE Request kèm theo header Events, chứa tên sự kiện và header Expires, chỉ định thời gian hết hạn Nếu server hỗ trợ các sự kiện trong yêu cầu SUBSCRIBE, nó sẽ phản hồi bằng 200 OK Khi có sự thay đổi, server sẽ gửi NOTIFY Request để thông báo cho UA đã đăng ký.
Trong giao thức SIP, có một số loại thông điệp quan trọng được sử dụng để giao tiếp giữa các User Agent (UA) Đầu tiên, thông điệp NOTIFY được sử dụng khi một UA muốn thông báo cho các UA khác về một yêu cầu INVITE hoặc một sự kiện nào đó mà các UA khác đã đăng ký lắng nghe thông qua SUBSCRIBE Nội dung thông báo được chứa trong phần thân thông điệp và định dạng theo XML Thứ hai, MESSAGE được dùng để gửi tin nhắn nhanh giữa các UA, với nội dung tin nhắn nằm trong phần thân MESSAGE Tiếp theo, PUBLISH là yêu cầu gửi lên Server để thông báo trạng thái của một sự kiện, với thông tin trạng thái chứa trong Message Body định dạng XML Khi Server nhận PUBLISH Request, nó sẽ gửi NOTIFY Request để thông báo cho các UA đã đăng ký theo dõi sự kiện Khác với NOTIFY, PUBLISH không cần sử dụng Dialog Cuối cùng, UPDATE được dùng để cập nhật trạng thái của một phiên làm việc mà không cần thiết lập Dialog, thường được sử dụng để điều chỉnh âm thanh hoặc thực hiện QoS.
Dùng khi m t UA mu n g i thông tin báo hi u cu c g i cho m t UA đang đ c thi t l p m t phiên làm vi c INFO Request không bao gi đ c t o b i Proxy h PRACK
Là m t Request dùng đ xác nh n đã nh n đ c các Response t m th i (1xx) PRACK Request đ c áp d ng cho t t c các Response t m th i ngoài Response 100 Trying
SIP response
Là thông đi p UAS dùng đ tr l i cho các yêu c u c a UAC Trong thông đi p tr l i, dòng b t đ u g i là dòng tr ng thái
Protocol-versionStatus-CodeReason-phrase
− Protocol version: phiên b n c a giao th c SIP
− Status Code: Mã tr ng thái
− Reason phrase: ý ngh a c a mã tr ng thái
1xx T m th i Nh n đ c yêu c u, ti p t c x lý yêu c u
2xx Thành công Nh n s ki n thành công, hi u và ch p nh n
3xx Chuy n h ng Thêm các s ki n c n th c hi n đ hoàn thành yêu c u
4xx L i client L i sai cú pháp ho c không th th c hi n t i server này
5xx L i server Server không th hoàn thành yêu c u h p l
6xx Th t b i hoàn toàn Yêu c u không th hoàn thành t i b t kì server nào
B ng 2.1: Phân lo i các tr l i
SIP Header
Các header bắt đầu bằng dòng b t đầu trong thông điệp, cung cấp thông tin về yêu cầu học trả lời và nội dung của thông điệp Mỗi header có tên và giá trị được phân cách bằng dấu ‘:’ Header chứa các tham số, với mỗi tham số có tên và giá trị phân cách bằng dấu ‘=’; vùng header và vùng tham số được phân cách bằng dấu ‘;’ Các thông điệp không phân biệt các header.
Cú pháp: field-name: field-value; parameter-name _ parameter-value
Các header quan tr ng:
Trong phần tiêu đề (From header) của thông điệp, có thể chứa tên hiển thị của người gửi (UA) Nếu tiêu đề này bao gồm một thẻ hoặc tên hiển thị, thì địa chỉ SIP URI sẽ được định dạng trong cặp dấu '< >'.
− VD: From: khoa.nguyen ; tag3i5h8sdshj88d
− To: AoR c a n i nh n thông đi p To header không thay đ i To header có th ch a display name t ng t From header
− Call-ID: mã nh n d ng các thông đi p trong phiên, đ c dùng đ xác đnh dialog
T t c các request và response trong dialog ph i có cùng Call-ID c t o t đ ng b i
− Via: l u đ ng đi c a yêu c u đ g i tr l i ng c l i
− Contact: ch a đa ch SIP URI c a UA dùng đ , g i thông đi p trong dialog tr c ti p mà ko qua proxy
Route và Record Route là hai yếu tố quan trọng trong giao thức SIP, giúp xác định đường đi của thông điệp Trong khi Route xác định đường đi của thông điệp, Record Route được thêm vào bởi các proxy để ghi lại đường đi này Điều này cho phép các thông điệp trong một cuộc hội thoại được chuyển tiếp qua các proxy thông qua header Contact.
− CSeq: dùng s p x p và phân bi t các yêu c u trong phiên M i thông đi p t o ra trong dialog s t ng Cseq lên 1 giá tr
− Max-Forward: s hop t i đa Gi m d n đ n 0 thì thông đi p b t ch i
− Content-Type: lo i n i dung ch a trong ph n thân Có d ng type/subtype N u header này không xu t hi n thì giá tr m t đnh là application/sdp
T ng quan
Chức năng SIP được cấu trúc thành các lớp, nghĩa là các hành động của giao thức được chia thành tập hợp các giai đoạn xử lý đặc lấp Các giai đoạn xử lý này có thể được xem như các lớp Mỗi lớp sử dụng dịch vụ của lớp bên dưới và cung cấp dịch vụ cho lớp bên trên.
H ng ti p c n theo l p ch nh m m c đích trình bày và không b t bu c trong các cài đ t SIP
Khi nói m t ph n t ch a m t l p có ngh a là ph n t đó đ c cài đ t theo các quy đnh c a l p đó Không ph i t t c các l p đ u có trong t t c các thành ph n trong giao th c
− SIP core sublayer: Các logic d ch v c a các th c th SIP đ c cài đ t l p này
Có n m thành ph n g i là các lõi (core) t ng ng v i các th c th SIP: UAC, UAS, registrar, stateful proxy, stateless proxy
− SIP transaction sublayer: L p cài đ t quá trình x lý giao tác (transaction) Nó ch a m t logic d ch v mà đ c s d ng b i các th c th SIP Bao g m hai thành ph n: client transaction và server transaction
− SIP transport sublayer: ch u trách nhi m g i và nh n thông đi p SIP Có hai thành ph n: client transport và server transport
− SIP syntax and encoding function : không nh m t l p, l p này đ i di n cho ch c n ng mã hóa/gi i mã các thông đi p khi đ c g i ho c nh n thông qua giao di n TCP/IP socket
Hình 3.1: Mô hình theo l p c a SIP
SIP Core sublayer
Transaction sublayer
Nh n thông đi p t transaction user và chuy n xu ng l p d i là transport sublayer và ng c l i
Request và Response là hai thành phần quan trọng trong giao thức SIP, đặc biệt đối với proxy, nơi cần xử lý nhiều giao tác đồng thời Do đó, việc nhận biết thông điệp và xác định giao tác tương ứng là rất cần thiết.
− Chuy n phát tin c y: Transaction sublayer cài đ t c ch g i l i đ t ng đ tin c y khi s d ng UDP
Giao dịch không INVITE là các giao tác mà không yêu cầu INVITE, hoạt động dựa trên việc gửi và nhận thông tin giữa hai bên Trong quá trình này, client sẽ thực hiện giao dịch liên tục và nhận thông điệp theo thời gian nhất định cho đến khi nhận được phản hồi cuối cùng.
Giao tác INVITE là một quá trình bao gồm ba bước chính Khi nhận được yêu cầu từ client, server sẽ bắt đầu một timer để theo dõi thời gian phản hồi Sau khi gửi phản hồi cuối cùng, server cũng sẽ khởi động timer; nếu timer hết thời gian mà chưa nhận được ACK từ giao tác client, server sẽ tiếp tục gửi lại phản hồi cuối cho đến khi nhận được ACK.
Các giao tác bao gồm hai phần: phía client và phía server Phía client được gọi là giao tác của client, trong khi phía server được gọi là giao tác của server Giao tác của client thực hiện yêu cầu và nhận phản hồi, trong khi giao tác của server nhận yêu cầu và gửi trả lại kết quả.
Hình 3.3: Ho t đ ng gi a các l p trong UA
Transport sublayer
L p này ch u trách nhi m g i/nh n yêu c u và tr l i
− i u khi n transport layer g i và nh n thông đi p
− Forward các response đ n Transaction User t ng ng
Các l p bên trên mà s d ng SIP transport sublayer g i là transport user L p này đ c chia làm hai ph n:
Client Transport chịu trách nhiệm nhận và truyền tải các yêu cầu từ người dùng Khi nhận được phản hồi từ Client Transport, nó sẽ tìm kiếm Client Transaction tương ứng Nếu tìm thấy, nó sẽ truyền lại thông tin cho Client Transaction đó; nếu không, thông tin sẽ được truyền thẳng đến SIP Core.
− Server Transport: ch u trách nhi m nh n yêu c u và truy n t i transport user N u dùng v n chuy n tin c y thì tr l i đ c g i qua k t n i mà yêu c u đ c g i đ n, n u k t n i ko t n t i thì t o m t k t n i m i N u dùng v n chuy n ko tin c y tr
36 l i đ c g i đ n đa ch trong vùng received n u ko có received thì g i đ n đa ch trong sent-by c a via header
CH NG 4: SESSION DESCRIPTION PROTOCOL
Ngu n g c
SDP (Session Description Protocol) được sử dụng để mô tả các phiên truyền thông đa điểm (multicast) Mỗi phiên SDP được phân phối đến các bên tham gia thông qua giao thức thông báo phiên (Session Announcement Protocol - SAP) SDP chứa thông tin về đa ch truyền thông, bao gồm các codec được sử dụng trong phiên Giao thức này được áp dụng trong nhiều trường hợp, như streaming và giao tiếp IP.
T ng quan
SDP đ c đ c t trong RFC 4566 SDP không th t s là m t giao th c, nó là m t ngôn ng đ th hi n các tham s chính đ mô t phiên truy n thông đa ph ng ti n
SDP có d ng v n b n đ c đ c M t thông đi p SDP bao g m t p h p các dòng có d ng:
= là m t kí t đ n, m i kí t có m t ý ngh a riêng, giá tr c a
có c u trúc tùy thu c vào
M t thông đi p SDP ch a ba t ng thông tin:
− Mô t c p phiên: ch a các dòng mô t đ c tính c a toàn b phiên
− Mô t th i gian: ch a các dòng mô t các v n đ liên quan đ n th i gian
− Mô t ph ng ti n truy n thông (media): ch a các dòng mô t lo i truy n thông trong phiên
Field Description Required v Protocol version R o Originator and session identifier R s Session name R i Session information u URI of description
38 e Email address p Phone number c Connection information(*) b Bandwidth information z Time zone adjustments k Encryption key a Session attribute R: b t bu c có trong mô t
(*) không b t bu c n u có trong c p media
B ng 4.1: Các dòng mô t c p phiên
Field Description R/O t Time the session is active R r Repeat time
B ng 4.2: Các dòng mô t c p th i gian
Field Description R/O m Media name and transport addr R i Media title R c Connection information(*) R
39 b Bandwidth information k Encryption key a Attribute line
B ng 4.3: Các dòng mô t c p media
Các dòng mô t quan tr ng
− Phiên b n giao th c (v): Dòng mô t “v” ch a phiên b n c a SDP Th ng mang giá tr 0 cho phiên b n hi n t i
Dòng mô t “o” trong giao thức SIP xác định thông tin bên gọi, bao gồm các tham số như username, session id, session version, network type, address type, và unicast address Tham số username thể hiện tên của bên gọi, trong khi session id là chuỗi duy nhất cho phiên, sử dụng giá trị từ NTP timestamp Session version cũng dựa trên NTP timestamp để xác định phiên bản dữ liệu Network type được chỉ định là “IN” cho Internet, và address type có thể là IP4 hoặc IP6 Cuối cùng, unicast address là địa chỉ IP của người gọi.
Tên phiên (s) là dòng mô tả tên hoặc đặc điểm của phiên, có ý nghĩa quan trọng trong truyền thông đa điểm Trong giao tiếp IP, phiên không có tên, do đó dòng này được định nghĩa với giá trị "s=".
VD: s− Thông tin k t n i (c): o Dòng mô t “c” ch a các thông tin v đa ch k t n i ó là đa ch nh n các gói truy n thông đ n
VD: c=IN IP4 1.2.3.4: IN xác định địa chỉ IP, theo sau là địa chỉ Internet, IP4 chỉ ra phiên bản của giao thức IP Dòng mô tả "c" có thể xuất hiện nhiều lần cho các phiên và có hiệu lực cho tất cả các phiên, trong khi dòng "m" chỉ có hiệu lực cho media đó và ghi đè giá trị của phiên trước.
Thời gian (t) là dòng mô tả thời gian chứa thông tin về thời gian của phiên Dòng này chỉ có ý nghĩa khi được sử dụng trong các phiên truyền thông đa điểm Đối với các phiên truyền thông điểm đến điểm, thời gian thường được gán giá trị "0 0".
Dòng mô t "m" trong giao thức truyền thông chứa thông tin về media, cho phép nhiều dòng mô t trong một phiên Mỗi dòng mô t xác định loại truyền thông như âm thanh, video, thông điệp, hình ảnh, v.v Ngoài ra, nó còn chỉ ra sport mà bên nhận muốn nhận các gói truyền thông và phương thức giao thức sử dụng cho việc truyền tải, bao gồm RTP, UDP, TCP, MSRP/TCP, cùng với các thông tin về nhạc nền media.
− B ng thông (b) : Dòng mô t “b” là tùy ch n nó xác đnh b ng thông đ c s d ng b i phiên ho c media
Các thuộc tính trong SDP (Session Description Protocol) rất quan trọng để xác định cách thức truyền thông Một số thuộc tính cơ bản bao gồm: "a=rtpmap" dùng để ánh xạ payload với các tham số như tên mã hóa và tần số xung, ví dụ: "a=rtpmap:96 L8/8000" cho mã hóa L8 với tần số 8000 Hz Ngoài ra, các thuộc tính "a=sendrecv", "a=recvonly", "a=sendonly" và "a=inactive" chỉ định chế độ truyền thông của phiên, từ việc gửi và nhận, chỉ nhận, chỉ gửi, đến không hoạt động.
CH NG 5: GIAO DI N JAIN SIP
Khái ni m Jain SIP
Jain SIP là một Java API được thiết kế cho giao thức khởi tạo phiên, phát triển trong môi trường J2SE Nó cung cấp giao diện phát triển ngữ điệu tiêu chuẩn cho các dịch vụ SIP, tương thích với các đặc điểm kỹ thuật RFC 3261 Jain SIP API chủ yếu cung cấp giao diện để phát triển các ứng dụng liên quan đến SIP.
− Xây d ng và phân tích cú pháp các thông đi p SIP
− S d ng transaction sublayer (đ g i và nh n thông đi p có tr ng thái)
− S d ng transport sublayer (đ g i và nh n thông đi p không tr ng thái)
Hình 5.1: Mô hình phân l p trong giao th c SIP
Thêm vào đó, giao di n c ng cung c p ch c n ng h tr SIP dialog.
Ki n trúc Jain SIP
Peer-provider pattern
Peer có ngh a ch ph n m m có cài đ t b giao th c SIP Provider cung c p các ch c n ng c a SIP đ c hi n th c b ng giao di n SipProvider
Mô hình g m 3 giao di n chính:
Hình 5.2: Mô hình peer-provider trong JAIN SIP
Giao diện chính trong Jain SIP cung cấp dịch vụ cho phép người dùng gửi và nhận tin nhắn SIP không trạng thái Giao diện này đảm bảo việc thực hiện các chức năng cần thiết của tất cả các tin nhắn SIP.
M t s ph ng th c trong SIP Provice:
Giao diện SipStack cho phép lập trình viên quản lý và cấu hình các SIP stack một cách hiệu quả Nó bao gồm các phương thức bắt đầu hoặc ngừng các SIP stack Cấu hình SIP stack được xác định thông qua một tập hợp thuộc tính trong Sipstack Java, bao gồm tên stack, proxy outbound và hỗ trợ dialog.
M t s ph ng th c trong SIP stack:
− ListeningPoint createListeningPoint(String ipAddress,int port, String transport)
ListeningPoint là điểm đến cho socket mà SipProvider sử dụng để gửi và nhận thông điệp SipProvider có khả năng hỗ trợ nhiều ListeningPoint ListeningPoint cho phép người dùng lấy và thiết lập các thông số truyền tải như IP, port và giao thức.
M t s ph ng th c trong ListeningPoint :
Factory pattern
JAIN SIP cung cấp các đối tượng SIP thực hiện các chức năng của giao thức SIP Việc tạo ra các đối tượng này được thực hiện thông qua một nhà máy gọi là SipFactory Mô hình này cũng thường được sử dụng trong các thiết kế hệ thống đối tượng.
M t s ph ng th c trong SIP Factory:
Hình 5.3: S d ng mô hình Factory
Ngoài SipFactory là l p chính, Jain SIP cung c p các Factory khác :
Trong MessageFactory, có hai phương thức chính để tạo thông điệp SIP: createRequest() và createResponse() Những phương thức này không yêu cầu tham số đầu vào, vì chúng có khả năng thực hiện các yếu tố khác của thông điệp SIP như dòng bắt đầu và tiêu đề.
Hình 5.4: Mô hình thông đi p SIP trong JAIN SIP
M t s ph ng th c trong MessageFactory:
Giao di n Message có ch c n ng :
− T o các ch c n ng truy xu t headers
− Truy xu t headers ph n thân
− Các ph ng th c truy c p ph n thân
M t s ph ng th c c a đ i t ng Request :
M t s ph ng th c c a đ i t ng Response:
Giao di n AddressFactory cho phép các ng d ng t o ra đa ch dùng trong SIP
Nó cho phép t o ra các đ i t ng cài đ t theo các giao di n sau:
− Address : s d ng đ đ i di n cho m t đa ch SIP c a ng i dùng Nó bao g m hai y u t : tên hi n th và m t URI
− URI: là đa ch c a ng i dùng, Giao di n URI có hai giao di n: SipURI: đ i di n cho m t URI SIP và TelURL: đ i di n cho m t URL TEL
Hình 5.5: Mô hình Address trong JAIN SIP
M t s ph ng th c trong AddressFactory:
− SipURI createSipURI (String user, String host)
T o ra các đ i t ng làm vi c v i các header
M t s ph ng th c trong HeaderFactory :
− ToHeader createToHeader (Address address, String tag)
− FromHeader createFromHeader (Address address, String tag)
− CSeqHeader createCSeqHeader(int cseq, String method)
Hình 5.6: Mô hình Header trong JAIN SIP
Event-listener pattern
JAIN SIP hoạt động theo mô hình event-listener, trong đó các đối tượng lắng nghe các sự kiện và nhận thông báo khi sự kiện đó xảy ra Mỗi loại sự kiện có một cách xử lý riêng Cụ thể, trong JAIN SIP, khi SIP stack nhận được một SIP message (bao gồm các request và response) từ mạng, SipProvider sẽ truyền thông điệp đó đến một sự kiện mà đối tượng SipListener đang lắng nghe Khi nhận được sự kiện, SipListener sẽ thực hiện phương thức xử lý tương ứng Quy trình này được mô tả trong hình 5.7.
Các s ki n SIP đ i di n cho các thông đi p đ n t m ng vào SIP stack Có hai lo i s ki n:
− RequestEvent: S ki n nh n đ c m t yêu c u SIP
− ResponseEvent: S ki n nh n đ c tr l i SIP
Hình 5.8: i t ng s ki n trong JAIN SIP
CH NG 6: JAVA MEDIA FRAMEWORK API
Java Media Framework (JMF) là một công cụ xử lý dữ liệu đa phương tiện mạnh mẽ, cho phép người dùng dễ dàng tương tác với các định dạng khác nhau JMF không phải là công cụ duy nhất để xử lý dữ liệu đa phương tiện, nhưng nó cung cấp các giao diện lập trình ứng dụng (API) phong phú cho những yêu cầu cao về hiệu suất.
Ch ng này ch t p trung vào m t s ch c n ng chính c a JMF API đ hi u rõ ho t đ ng, ph m vi s d ng và h ng m r ng c a JMF
Java Media Framework (JMF) là một API cho phép xử lý dữ liệu đa phương tiện trong các ứng dụng Java JMF cung cấp các chức năng như thu thập, phát, lưu trữ và xử lý dữ liệu đa phương tiện theo thời gian thực Nó hỗ trợ hầu hết các định dạng đa phương tiện và có khả năng mở rộng để hỗ trợ nhiều loại dữ liệu đa phương tiện khác nhau Đặc biệt, JMF định nghĩa một RTP API để gửi và nhận các luồng RTP.
Mô hình x lý d li u c a JMF:
Hình 6.1: Mô hình x lý d li u c a JMF
Mô hình g m 3 giai đo n: đ u vào (input), x lý (processing), đ u ra (output)
Giai đoạn nhập liệu là quá trình yêu cầu dữ liệu đa phương tiện Dữ liệu đa phương tiện có thể được thu thập từ nhiều nguồn khác nhau, bao gồm thiết bị như microphone và webcam, từ tập tin, hoặc từ mạng Internet thông qua các luồng RTP.
Giai đoạn xử lý dữ liệu là quá trình tiếp nhận thông tin đầu vào và thực hiện các thao tác như multiplexing/demultiplexing, mã hóa/giải mã (encoding/decoding), và đóng gói/tách gói (packetizing/depacketizing).
ど Giai đo n output th c hi n vi c truy n d li u đa ph ng ti n Có th truy n t i: thi t b (loa ho c headphone), t p tin, m ng Internet (truy n d li u theo lu ng RTP).
Lu ng d li u đ a ph ng ti n
Để xử lý dữ liệu đa phương tiện, giai đoạn đầu tiên là nhận diện và lấy được media stream Giai đoạn xử lý sẽ tạo ra một media stream mới, có thể được đưa vào giai đoạn đầu ra để trình diễn hoặc gửi đi Để lấy được media stream trong giai đoạn đầu vào, cần xác định vị trí và phương thức truy cập Địa chỉ URL hoặc mã định danh vị trí dữ liệu đa phương tiện sẽ được sử dụng để thực hiện việc xác định vị trí.
ど M t media stream l y t t p tin c c b có th đ c xác đnh b ng URL d ng
ど M t media stream l y t t p tin web server đ c xác đnh b ng URL d ng
ど M t media stream l y t m ng Internet đ c xác đnh b ng media locator d ng
ど M t media stream l y t card âm thanh đ c xác đnh b ng media locator d ng
Media stream có thể chứa nhiều kênh dữ liệu, được gọi là track, chẳng hạn như audio track và video track Kỹ thuật multiplex cho phép tạo ra media stream với nhiều track khác nhau Quá trình tách các track trong media stream được gọi là demultiplex.
Các đ i t ng trong JMF
Manager
51 l y đ c các đ i t ng JMF nh datasource, player, processor, và datasink, c n ph i thông qua m t đ i t ng trung gian là manager Có 4 lo i manager:
ど Manager: t o ra các đ i t ng Player, Processor, DataSource, và DataSink
ど CaptureDeviceManager: gi m t th ghi (registry) v các thi t b , cung c p danh sách thi t b phù h p v i đnh d ng mong mu n
Data Source
Data source là đ i t ng ch a media stream Trong quá trình x lý d li u, các data source khác nhau có th ch a các media stream các giai đo n khác nhau
Hình 6.2: Data source các giai đo n khác nhau
Data source đ c hi n th c b ng l p tr u t ng DataSource giai đo n input, đ i t ng DataSource có th đ c l y t m t URL ho c m t media locator Ví d sau l y DataSource t m t t p tin:
MediaLocator ml=new MediaLocator("fi le://c:\\music.wav");
DataSource ds= Manager.createDataSource(ml);
DataSource c ng có th đ c l y giai đo n output.
Player
Player ch u trách nhi m x lý và th hi n media stream Player đ c hi n th c b ng giao di n Player Media stream đ c đ a vào Player d i d ng DataSource (hình )
Player cung c p ch c n ng đi u khi n vi c x lý d li u và th hi n d li u
Player có hai trạng thái chính là dừng (Stopped) và chạy (Started) Để Player bắt đầu hoạt động, nó cần trải qua nhiều trạng thái khác nhau để thu thập các tài nguyên cần thiết JMF thông báo sự chuyển đổi trạng thái của Player thông qua mô hình sự kiện của Java, và để nhận được các sự kiện này, cần cài đặt giao diện ControllerListener.
Hình 6.4: Tr ng thái c a Player
Unrealized: Player đã kh i t o nh ng ch a có d li u
Realizing: Player đang trong quá trình l y các tài nguyên c n thi t
Realized: Player đã có d li u và thông tin media
Prefetching: Player đang chu n b th hi n d li u
Processor
Processor có vai trò quan trọng trong việc xử lý media stream, hoạt động như một cầu nối giữa Player và các chức năng điều khiển Nó nhận vào một DataSource và xuất ra một DataSource mới Processor có khả năng multiplex, demultiplex, encode, decode và thực hiện các thao tác trên media stream, đồng thời có thể hiển thị dữ liệu lên thiết bị.
Processor c ng có các tr ng thái nh m t Player, nh ng có thêm hai tr ng thái là Configuring và Configured, xu t hi n tr c tr ng thái Realizing (hình 6.6)
Hình 6.6: Tr ng thái c a Processor
ど Configuring: Processor đang k t n i v i DataSource, x lý d li u đ u vào và xác đnh đnh d ng c a d li u
ど Configured: Processor đã k t n i v i DataSource và đã xác đnh đ c đnh d ng d li u.
Data Sink
Data sink trong media stream là điểm nhận và xử lý dữ liệu mà không cần thiết bị vật lý Cụ thể, Data sink cho phép ghi dữ liệu vào tệp hoặc truyền dữ liệu qua mạng Việc thực hiện Data sink được thực hiện thông qua giao diện DataSink.
Hình 6.7: Datasink trong JMF g i d li u đ n đích c n th c hi n 2 b c:
ど G i hàm open() c a DataSink đ k t n i đ n đ u ra đ c xác đnh b i
ど G i hàm start() đ b t đ u truy n d li u.
SessionManager
Hình 6.8: Session Manager trong JMF
SessionManager đ c s d ng khi g i và nh n RTP Trái v i DataSink,
SessionManager cung c p các ch c n ng đi u khi n trong phiên RTP SessionManager qu n lý các bên tham gia phiên và qu n lý d li u đ c truy n trong phiên RTP
SessionManager c ng đi u khi n RTCP Tóm l i, SessionManager cung c p các ch c n ng:
ど B t đ u và k t thúc phiên RTP
ど T o các lu ng d li u RTP
ど Thêm, b t các bên tham gia
Khi làm vi c v i SessionManager RTPStream là thành ph n r t quan tr ng Có hai ho i RTP stream:
ど ReceiveStream: lu ng RTP g i đ n
ど SendStream: lu ng RTP g i đi
SessionManager s g i các s ki n liên quan đ n các đ i t ng có cài đ t giao di n listener Có 4 lo i listener:
ど SessionListener: l ng nghe các s ki n khi tr ng thái phiên thay đ i
ど SendStreamListener: l ng nghe các s ki n liên quan đ n SendStrean
ど ReceiveStreamListener: l ng nghe các s ki n liên quan đ n ReceiveStream
ど RemoteListener: l ng nghe các thông đi p đi u khi n t bên g i.
Ki n trúc JMF
Mô hình th i gian (Time Model)
JMF tính th i gian theo nano-giây M t th i đi m xác đnh đ c th hi n b i m t đ i t ng Time [6]
Giao diện Clock của JMF quản lý thông tin và thời gian của các luồng dữ liệu đa phương tiện Giao diện này định nghĩa cách thức hoạt động và đồng bộ hóa các luồng media, giúp tối ưu hóa quá trình xử lý và phát lại nội dung đa phương tiện.
55 tính toàn th i gian và các ho t đ ng đ ng b hóa c n thi t đ qu n lý vi c trình di n d li u đa ph ng di n
Mô hình thời gian JMF sử dụng một đồng hồ để điều chỉnh TimeBase, xác định thời gian khi luồng media đang được trình diễn Thời gian dựa trên TimeBase không thay đổi hoặc không động lặp lại, mà thường dựa trên thời gian hệ thống.
Thời gian của điểm đồng hồ (Clock) trong một media stream là khoảng thời gian hiện tại, bắt đầu từ 0 cho đến thời gian lớn nhất Thời gian của media stream (Duration) là khoảng thời gian từ lúc bắt đầu cho đến khi kết thúc Để theo dõi thời gian của dữ liệu media, điểm đồng hồ sử dụng.
ど Time-base start-time: th i gian mà TimeBase tr v khi d li u b t đ u trình di n
ど Media start-time: v trí b t đ u media stream
ど Playback: t c đ đ i t ng Clock ch y cùng v i TimeBase Ví d playback rate 1.0 là t c đ bình th ng c a media stream, playback rate = 2.0 thì t c đ trình di n media stream s nhanh h n g p đôi
Khi b t đ u trình di n, media time đ c ánh x t i time-base time Trong khi trình di n, media time hi n t i đ c tính theo:
Media Time = MediaStartTime + Rate(TimeBaseTime – TimeBaseStartTime)
Khi trình di n k t thúc, media time c ng k t thúc nh ng time-base time v n ti p t c ch y N u trình di n đ c b t đ u l i, media time l i đ c ánh x đ n time-base time hi n t i
Mô hình s ki n (Event Model)
JMF sử dụng cấu trúc làm việc theo cách thông báo sự kiện, cho phép các ứng dụng sử dụng thư viện JMF phản hồi với trạng thái hiện tại của hệ thống media Khi một đối tượng trong JMF thông báo một sự kiện, nó sẽ trả về một đối tượng MediaEvent.
V i m i đ i t ng trong JMF có th tr v đ i t ng MediaEvent, JMF đnh ngh a m t giao di n l ng nghe t i các s ki n đó Các đ i t ng Controller (nh Player và
Processor) và các đ i t ng Control nh GainControl có th phát sinh s ki n media
Mô hình d li u (Data Model)
JMF s d ng DataSource đ qu n lý vi c truy n t i n i dung đa ph ng ti n
DataSource ch a v trí c a d li u và giao th c đ c s d ng đ truy n t i d li u Khi s d ng, DataSource đó không th đ c s d ng l i đ g i đi n i khác
DataSource đ c xác đnh b ng m t MediaLocator ho c b ng m t URL
DataSource qu n lý m t t p h p các đ i t ng SourceStream JMF đnh ngh a m t s lo i DataSource:
D li u đa ph ng ti n có th đ c l y t các ngu n khác nhau nh các t p tin c c b ho c t p tin trên m ng Các ngu n d li u có th đ c phân chia theo cách d li u đ c t o:
Pull Data Source là nguồn dữ liệu được sử dụng để truy xuất và điều khiển dòng dữ liệu Các giao thức thường sử dụng với nguồn dữ liệu này bao gồm HTTP và FILE JMF định nghĩa hai loại Pull Data Source là PullDataSource và một loại khác.
Push Data Source là một phương thức truyền dữ liệu từ server, cho phép điều khiển dòng dữ liệu hiệu quả Các loại push data source bao gồm truyền thông phát sóng (broadcast media), truyền thông đa điểm (multicast media) và video theo yêu cầu (VOD) JMF xác định hai loại push data source chính là PushDataSource và PushBufferDataSource.
JMF đnh ngh a hai lo i data source đ c bi t là CloneableDataSource và
ど CloneableDataSource có th đ c s d ng đ t o các b n sao c a m t
ど MergingDataSource đ c s d ng đ k t h p các SourceStream t m t s
58 nh d ng c a m t đ i t ng đ c hi n th c b ng đ i t ng Format Format không chỉ chứa tham số mã hóa hay thông tin về thời gian, mà còn bao gồm tên mã hóa của Format và kiểu dữ liệu mà Format yêu cầu.
Hình 6.12: nh d ng media trong JMF
AudioFormat các thu c tính nh sample rate, bits per sample, và s kênh
VideoFormat ch a thông tin liên quan t i d li u video
PH N III: THI T K NG D NG
Ngày nay, sự phát triển của công nghệ và mạng Internet đã mang đến nhiều chức năng và tiện ích cho người sử dụng Người dùng có thể dễ dàng xem phim, nghe nhạc, đọc báo và mua sắm chỉ với vài cú click chuột Tuy nhiên, nhu cầu của người sử dụng ngày càng cao; ngoài việc giải trí, họ còn muốn đáp ứng nhu cầu học tập Việc học tập tại nhà với chỉ một chiếc máy tính ngày càng trở nên phổ biến, giúp tiết kiệm thời gian và chi phí cho người học.
D a trên th c tr ng đó và ki n th c đã tìm hi u, chúng em đã xây d ng m t ng d ng hi n th c mô hình l p h c t xa s d ng giao th c SIP
ど Trang web đ ng ký h c tr c tuy n: đ c xây d ng trên n n ASP.NET
ど ng d ng: đ c xây d ng theo ki n trúc Client-Server s d ng ngôn ng Java
Website cung cấp chức năng cho học viên quản lý thông tin cá nhân, đăng ký lớp học và theo dõi các lớp đã đăng ký Giảng viên có thể quản lý thông tin cá nhân và xem lịch phân công giảng dạy Người quản trị có nhiệm vụ tổ chức các lớp học và phân công giảng viên cho từng lớp.
ど Ng i s d ng dùng ng d ng tham gia các l p đã đ ng ký Khi l p h c b t đ u có th th y đ c hình nh và l i c a gi ng viên tr c ti p gi ng d y
ど Ng i s d ng có th xem l i bài gi ng khi không tham gia l p h c tr c ti p
ど Có th trò chuy n v i b n bè qua ch c n ng chat text, voice call ho c video call
ど Ch c n ng chia s file.
Website
Mô hình ý ni m
Hình III.1: Mô hình ý ni m website ILearning
S đ l p
Hình III.2: S đ thi t k l p website Ilearning
Chi ti t website
3.3.1 Các trang chung cho các user: a Trang đ ng nh p:
Hình III.3: Trang đ ng nh p
Hình III.4: L u đ x lý đ ng nh p
Hình III.5: X lý đ ng nh p b Trang qu n lý thông tin cá nhân:
Hình III.6: Trang qu n lý thông tin cá nhân
Hình III.7: L u đ c p nh t thông tin user
Hình III.8: X lý c p nh t thông tin c Trang đ i m t kh u
3.3.2 Các trang c a H c viên: a Trang qu n lý l p h c đã đ ng ký:
Hình III.11: Trang qu n lý l p h c đã đ ng ký
Hình III.12: L u đ x lý tìm ki m
Hình III.13: X lý tìm ki m l p h c đã đ ng ký
Hình III.14: X lý xóa l p đã đ ng ký b Trang thông tin l p h c:
Hình III.15: Trang thông tin l p h c
ど Nút h y đ ng ký x lý t ng t quá trình x lý xóa l p đã đ ng ký trên (hình III.15)
Hình III.16: Trang đ ng ký l p h c
ど X lý nút tìm t ng t quá trình tìm l p h c trên (hình III.13)
Hình III.17: L u đ x lý đ ng ký l p h c
Hình III.18: X lý đ ng ký l p h c
3.3.3 Các trang c a Gi ng viên: a Trang l ch gi ng d y:
Hình III.19: Trang l ch gi ng d y
ど X lý nút tìm ki m t ng t nh trên (hình III.13) b Trang chi ti t l p h c:
Hình III.20: Trang chi ti t l p h c
3.3.4 Các trang c a qu n tr viên:
Hình III.21: Trang qu n lý user
ど L u đ tìm ki m t ng t nh trên (hình III.13)
Hình III.22: X lý tìm ki m user
Hình III.23: X lý c p nh t quy n user
Hình III.24: X lý xóa user b Trang qu n lý l p h c:
Hình III.25: Trang qu n lý l p h c
ど X lý tìm ki m t ng t quá trình tìm ki m l p h c trên (hình III.13)
ど Mô hình x lý xóa l p h c:
ng d ng
Ho t đ ng Client-Server
ng d ng ho t đ ng theo mô hình Client-Server Client g i các yêu c u và Server g i tr l i t ng ng Ho t đ ng t ng tác đó đ c mô t qua các s đ sau:
REGISTER đ c s d ng trong hai tr ng h p:
Để thực hiện cuộc gọi, người dùng cần đăng nhập vào hệ thống và gửi yêu cầu REGISTER, trong đó phần tiêu đề From và To chứa địa chỉ SIP URI của người dùng kèm theo UserID Tiêu đề Expire phải có giá trị lớn hơn 0, và mật khẩu được chứa trong phần thân của thông điệp Máy chủ sẽ phản hồi bằng ngôn ngữ tương ứng và có thể kèm theo thông tin trong phần thân như mô tả trong hình III.31.
Hình III.30: Ho t đ ng đ ng nh p
ど Tr ng h p th hai là khi User đ ng xu t kh i h th ng, User c ng g i yêu c u REGISTER nh ng v i Expire header có giá tr b ng 0 Server nh n đ c s g i tr l i 200 OK
Hình III.31: Ho t đ ng đ ng xu t
INVITE c ng đ c s d ng trong hai tr ng h p:
Khi một người dùng (User 1) gửi yêu cầu INVITE kèm theo thông tin phiên đến một máy chủ, máy chủ sẽ chuyển tiếp yêu cầu INVITE đó đến người dùng khác (User 2) User2 nhận yêu cầu và có thể chấp nhận bằng cách gửi phản hồi 200 OK, hoặc từ chối với mã lỗi 4xx Phản hồi sẽ được truyền theo hướng ngược lại với yêu cầu INVITE ban đầu.
Hình III.32: Ho t đ ng g i l i m i thi t l p phiên
Khi có hai người dùng tham gia, một người dùng gửi lời mời để tham gia vào lớp học Hoạt động tự động diễn ra trong lớp học đó Khi có một người dùng mới tham gia, server sẽ gửi yêu cầu thông báo đến các người dùng khác trong lớp học.
Hình III.33: Ho t đ ng tham gia vào l p h c
MESSAGE đ c s d ng trong hai tr ng h p:
ど M t là, m t user g i tin nh n chat đ n m t user khác (khi ch a thi t l p phiên truy n thông) Server ch đ n gi n chuy n ti p đ n user nh n
Hình III.34: Ho t đ ng g i thông đi p chat
ど Hai là, user g i tin nh n chat trong l p h c Server nh n đ c s chuy n ti p đ n các user khác trong l p h c
Hình III.35: Ho t đ ng g i thông đi p chat trong l p
User g i yêu c u BYE khi thoát kh i l p h c Server s g i tr l i 200 OK và thông báo
NOTIFY cho các user khác bi t
Hình III.36: Ho t đ ng r i kh i l p h c
Client
Client ho t đ ng theo mô hình tr ng thái đ c mô t trong hình sau:
Hình III.37: B máy tr ng thái c a ng d ng phía client
91 Client có các tr ng h p s d ng đ c mô t trong hình III.39 :
Hình III.38: Mô hình s d ng ng d ng ILearning
Hình III.39: L u đ x lý đ ng nh p
Hình III.40: S đ l p x lý đ ng nh p e Change Presence:
Hình III.41: L u đ x lý thay đ i tr ng thái
Hình III.44: L u đ x lý chat text
Hình III.45: S đ l p x lý chat text i Chat Voice/Video:
Hình III.46: L u đ x lý chat voice/video
Hình III.47: S đ l p x lý chat voice/video
Hình III.48: L u đ x lý tham gia l p h c
Hình III.49: S đ l p x lý tham gia l p h c k Leave Class:
Hình III.52: L u đ x lý gi ng viên b t đ u l p h c
Hình III.53: S đ l p x lý gi ng vien b t đ u l p h c
Hình III.54: L u đ x lý gi ng viên k t thúc l p h c
Hình III.55: S đ l p x lý gi ng viên k t thúc l p h c
Hình III.56: L u đ x lý chia s t p tin
Server
Server có các ho t đ ng x lý thông đi p g i đ n nh mô t trong l u đ bên d i (hình)
Hình III.57: L u đ x lý thông đi p g i đ n server a X lý thông đi p REGISTER:
Hình III.58: L u đ x lý thông đi p REGISTER
Hình III.59: S đ l p x lý thông đi p REGISTER khi user đ ng nh p
Hình III.60: S đ l p x lý thông đi p REGISTER khi user đ ng xu t
Hình III.61: L u đ x lý thông đi p INVITE
Hình III.62: S đ l p x lý INVITE g i đ n m t user khác
Hình III.63: S đ l p x lý INVITE vào l p h c
Hình III.66: L u đ x lý thông đi p MESSAGE
Hình III.67: S đ l p x lý thông đi p MESSAGE
Hình III.68: L u đ x lý thông đi p BYE
Hình III.69: S đ l p x lý thông đi p BYE
Nh n xét
Khóa luận đã đề cập đến những khái niệm cơ bản của giao thức khóa phiên (SIP) như chức năng, phương thức hoạt động và cấu trúc của giao thức này Những điểm đáng chú ý bao gồm vai trò của SIP trong việc thiết lập và quản lý phiên giao tiếp, cũng như cách thức nó tương tác với các giao thức khác trong hệ thống mạng.
ど SIP là giao th c l p ng d ng có đ c đi m đ n gi n, linh đ ng và d dàng phát tri n
ど Ch c n ng c b n và quan tr ng nh t c a giao th c SIP là kh i t o và qu n lý các phiên truy n thông
ど SIP ho t đ ng theo mô hình client-server, client và server giao ti p v i nhau b ng cách trao đ i các thông đi p SIP: client g i yêu c u và server g i tr l i t ng ng
SIP không giới hạn quy tắc đối với các vấn đề liên quan đến truyền thông Do đó, khóa luôn có thể được cập nhật với một số giao thức và thủ viện liên quan, giúp kiến thức khởi đầu có thể xây dựng các ngữ điệu phức tạp và có giá trị thực tiễn cao.
Nội dung khóa luận tập trung vào các khái niệm cơ bản cần thiết trong giao thức SIP, nhấn mạnh tiềm năng phát triển và ứng dụng trong tương lai Giao thức SIP không chỉ có khả năng mở rộng mà còn đối mặt với nhiều vấn đề liên quan đến việc xây dựng một hệ thống sử dụng giao thức này, bao gồm các chức năng và dịch vụ cần thiết.
ど SIP m r ng: t ng đ tin c y c a tr l i t m th i, kh n ng di chuy n và m r ng c a UA, Globally Routable User Agent URIs (GRUUs),…
ど Thi t k k t h p v i m ng PSTN/PLMN
ど Ki m soát ch t l ng d ch v (Quality of Service – QoS)
Giao tiếp truyền thông đa phương tiện đóng vai trò quan trọng trong việc nâng cao hiệu quả tìm hiểu và tiếp cận thông tin Nó giúp cải thiện khả năng giao tiếp và tương tác trong lĩnh vực truyền thông, đặc biệt là thông qua việc sử dụng giao thức SIP.
K t qu hi n th c ng d ng
Website : ã xây d ng đ c các ch c n ng c b n h tr cho user nh :
ど Qu n lý thông tin user
ど Theo dõi thông tin l p h c
ど Qu n lý l p h c ng d ng : ã hi n th c đ c m t s ch c n ng:
ど ng nh p, đ ng xu t ng d ng
ど Giao ti p v i b n bè b ng v n b n, voice, video
ど Gi ng viên có th gi ng d y tr c tuy n thông qua webcam và micro
ど Gi ng viên có th ghi l i bài gi ng.
H n ch
ど Ch t l ng truy n video và audio v n còn th p
ど Ch a hoàn thi n t t c các ch c n ng
ど Ch a có h th ng qu n lý đào t o.
H ng phát tri n
ど Xây d ng m t h th ng qu n lý đào t o hoàn thi n
ど Nâng cao ch t l ng video và audio truy n
ど Nâng c p các ch c n ng c
Để nâng cao hiệu quả học tập trong lớp học, giáo viên có thể áp dụng một số phương pháp như: tổ chức các hoạt động thực nghiệm trước khi giảng dạy, đánh giá chất lượng bài học, đặt câu hỏi để kích thích tư duy, chia sẻ tài liệu trong lớp, truyền tải hình ảnh từ màn hình desktop, và xem lại bài giảng để củng cố kiến thức.
