LỜI CẢM ƠN Trước hết em xin gửi lời lời cảm ơn chân thành tới quý quý thầy cô trong trường Đại Học Sư Phạm Hà Nội, quý thầy cô trong Khoa Công Nghệ Thông Tin đã hết lòng dạy bảo, giúp đỡ em trong suốt bốn năm học đại học, giúp em có những kiến thức và kinh nghiệm quý báu trong chuyên môn và cuộc sống. Những hành trang đó là một tài sản vô giá nâng bước cho em tới được những những thành công trong tương lai. lai. Đặc biệt em xin gửi tới TS. Trần Công Nhượng lời cảm ơn chân thành và sâu sắc nhất, thầy đã trực tiếp hướng dẫn chỉ bảo tận tình em trong suốt quá trình em làm bài khóa luận này. Cuối cùng xin chân thành cảm ơn sự giúp đỡ, động viên và chỉ bảo rất nhiệt tình của các bạn, những người đã giúp đỡ em hoàn thành khóa luận này. Hà Nội, Ngày 04 tháng 05 năm 2009 Sinh viên thực hiện Đào Xuân Dương
Mục Lục Chương 1. Tổng quan về mạng VOIP......................... .................................................................. ......................................... ...... 9 1.1. Tổng quan về mạng VOIP........................ ................................................... .......................................... ........................... ............... ...9 1.2. 1. 2. Kỹ thuật chu chuy yển mạch kê kênh (Cir ircu cuit it Sw Swit itc chi hing ng)): ............................................. 9 Một đặc trưng nổi bật c ủa k ĩ thu ật này là hai tr ạm mu ốn trao đ ổi thông tin v ới nhau thì giữa chúng sẽ được thiết l ập m ột “ kênh” (circuit) c ố đ ịnh, kênh k ết n ối này nà y được duy trì và dành ri riê êng cho ha haii trạm cho t ới khi cu ộc truyền ti tin kết thúc úc. . Thông tin cuộc gọi là trong suốt. Quá trình thi ết l ập cu ộc g ọi ti ến hành g ồm 3 giai đoạn........................... ...................................................... ...................................................... ..................................................... ...................................... ..............9 1.3. 1. 3. Kỹ thuật chu huy yển mạch gó góii (P (Pac acke kett Sw Swit itc chi hing ng)) ....... ............... ................ ................ ............... ............. .......... .... 10 1.4. Đặc tính c ủa m ạng VoIP........................... .................................................................. ....................................... ............ ............... ... 11 11 1.5. Yêu c ầu chất lượng đ ối v ới VoIP ....... ............... ............... ............... ................ ................ ............... ............... .............. ......... ... 13 Chương 2. Các giao th ức truyền tải trong VOIP .............................................. ......... 14 14 2.1. 2. 1. Gi Giao ao thứ c IP IP....................... .................................................. ...................................................... ........................................ ....................... .......... 14 2.2. 2. 2. Gi Giao ao thức IP IP phi phiên ên b ản 4 (IP (IPv4 v4)) .......................... ........................................................... ................................. ........... 15 2.3. 2. 3. Gi Giao ao thứ c TCP TCP........................... ...................................................... ...................................................... ........................................ ................ ... 17 2.4. 2. 4. Gi Giao ao thứ c UDP UDP......................... .................................................... ............................................................. .................................. .......... 20 2.5. 2. 5. Gi Giao ao thứ c RTP RTP........................... ...................................................... ...................................................... ....................................... ................ .... 20 2.6. 2. 6. Gi Giao ao thứ c RTC RTCP P .......................... ..................................................... ...................................................... .......................................... ............... 25 Chương 3. Giao thức khởi tạo phiên SIP ........ ................ ............... ............... ................ ............... ............... ................ ............ ......28 3.1. Giới thiệu về giao th ức S IP ......................... .................................................... ..................................................... .......................... 28 Một SIP Transaction được hiểu như là một chu ỗi các b ản tin request/response. Một SIP clients gửi m ột b ản tin request t ới SIP server, và SIP server g ửi tr ả l ại b ản tin respons nse e tương ứ ng.......................... .................................................... ............................................. ............................. .................. ....... 33 3.2. Cá Các lo lo ại bản ti tin SI SIP ........................ ................................................... ................................................................. ...................................... 34 3.3. Cấu tr trúc bản ti tin SI SIP........................... ...................................................... ............................................................. .................................. 43 3.4. SIP Header Fields ........ ................ ................ ............... ............... ................ ............... ............... ................ ................ ............... ........... ....... ... 46 hông ng tin v ề UA UAS S, thô hông ng tin ở đây có th ể là tên ho ặc phiên Được sử dụng để mang thô bản của UAS........................... ..................................................... ...................................................... ....................................... ........................ ................ .... 52 3.5. Session Description Protocol.......................... Protocol ............................................................ .................................. ............ .............. .. 53 53 3.6. Sử dụng NAT tro trong ng SIP ......................... .................................................... ...................................... ...................... .................... ......... 55 Chương 4. Các mô hình cuộc gọi trong SIP.......................... .............................................................. .................................... 58 4.1. 4. 1. Đăng ký v ới SI SIP P se serv rver er......................... .................................................... ........................................................... ................................59 4.2. Thiết lập cu ộc g ọi tr ực ti ếp gi ữa hai UA ........................... .......................................................... ............................... 63 4.3. Thiết lập cu ộc g ọi thông qua proxy ....................... ................................................... ........................................ .............. 66 66
Mục Lục Chương 1. Tổng quan về mạng VOIP......................... .................................................................. ......................................... ...... 9 1.1. Tổng quan về mạng VOIP........................ ................................................... .......................................... ........................... ............... ...9 1.2. 1. 2. Kỹ thuật chu chuy yển mạch kê kênh (Cir ircu cuit it Sw Swit itc chi hing ng)): ............................................. 9 Một đặc trưng nổi bật c ủa k ĩ thu ật này là hai tr ạm mu ốn trao đ ổi thông tin v ới nhau thì giữa chúng sẽ được thiết l ập m ột “ kênh” (circuit) c ố đ ịnh, kênh k ết n ối này nà y được duy trì và dành ri riê êng cho ha haii trạm cho t ới khi cu ộc truyền ti tin kết thúc úc. . Thông tin cuộc gọi là trong suốt. Quá trình thi ết l ập cu ộc g ọi ti ến hành g ồm 3 giai đoạn........................... ...................................................... ...................................................... ..................................................... ...................................... ..............9 1.3. 1. 3. Kỹ thuật chu huy yển mạch gó góii (P (Pac acke kett Sw Swit itc chi hing ng)) ....... ............... ................ ................ ............... ............. .......... .... 10 1.4. Đặc tính c ủa m ạng VoIP........................... .................................................................. ....................................... ............ ............... ... 11 11 1.5. Yêu c ầu chất lượng đ ối v ới VoIP ....... ............... ............... ............... ................ ................ ............... ............... .............. ......... ... 13 Chương 2. Các giao th ức truyền tải trong VOIP .............................................. ......... 14 14 2.1. 2. 1. Gi Giao ao thứ c IP IP....................... .................................................. ...................................................... ........................................ ....................... .......... 14 2.2. 2. 2. Gi Giao ao thức IP IP phi phiên ên b ản 4 (IP (IPv4 v4)) .......................... ........................................................... ................................. ........... 15 2.3. 2. 3. Gi Giao ao thứ c TCP TCP........................... ...................................................... ...................................................... ........................................ ................ ... 17 2.4. 2. 4. Gi Giao ao thứ c UDP UDP......................... .................................................... ............................................................. .................................. .......... 20 2.5. 2. 5. Gi Giao ao thứ c RTP RTP........................... ...................................................... ...................................................... ....................................... ................ .... 20 2.6. 2. 6. Gi Giao ao thứ c RTC RTCP P .......................... ..................................................... ...................................................... .......................................... ............... 25 Chương 3. Giao thức khởi tạo phiên SIP ........ ................ ............... ............... ................ ............... ............... ................ ............ ......28 3.1. Giới thiệu về giao th ức S IP ......................... .................................................... ..................................................... .......................... 28 Một SIP Transaction được hiểu như là một chu ỗi các b ản tin request/response. Một SIP clients gửi m ột b ản tin request t ới SIP server, và SIP server g ửi tr ả l ại b ản tin respons nse e tương ứ ng.......................... .................................................... ............................................. ............................. .................. ....... 33 3.2. Cá Các lo lo ại bản ti tin SI SIP ........................ ................................................... ................................................................. ...................................... 34 3.3. Cấu tr trúc bản ti tin SI SIP........................... ...................................................... ............................................................. .................................. 43 3.4. SIP Header Fields ........ ................ ................ ............... ............... ................ ............... ............... ................ ................ ............... ........... ....... ... 46 hông ng tin v ề UA UAS S, thô hông ng tin ở đây có th ể là tên ho ặc phiên Được sử dụng để mang thô bản của UAS........................... ..................................................... ...................................................... ....................................... ........................ ................ .... 52 3.5. Session Description Protocol.......................... Protocol ............................................................ .................................. ............ .............. .. 53 53 3.6. Sử dụng NAT tro trong ng SIP ......................... .................................................... ...................................... ...................... .................... ......... 55 Chương 4. Các mô hình cuộc gọi trong SIP.......................... .............................................................. .................................... 58 4.1. 4. 1. Đăng ký v ới SI SIP P se serv rver er......................... .................................................... ........................................................... ................................59 4.2. Thiết lập cu ộc g ọi tr ực ti ếp gi ữa hai UA ........................... .......................................................... ............................... 63 4.3. Thiết lập cu ộc g ọi thông qua proxy ....................... ................................................... ........................................ .............. 66 66
4.4. Thực hiện cuộc gọi liên m ạng SIP – PSTN ......................... .................................... ...................... ................... ........ 74 74 Chương 5. Gi Giới thiệu ứng dụng........................ ................................................... ...................................................... ............................. ..80 5.1. Giới thiệu th ư vi ện mã nguồn mở OpenSipStack ............................... ............ ..............80 5.2. Giới thiệu ch chương trình SIMO.......................... ..................................................... ................................................ ..................... 80
DANH MỤC CÁC TỪ VIẾT TẮT Kí hiệu viết tắt
Viết đầy đủ
Ý nghĩa
VoIP
Voice over IP
Công nghệ truyền thoại trên mạng IP
PSTN
Public Switch Telephone Network
Mạng điện thoại công cộng
PCM
Pulse-Code Modulation
Bộ mã hóa mã xung
SIP
Session Initiation Protocol
Giao thức thiết lập phiên
RTP
Real Time Protocol
Giap thức thời gian thực
RTCP
Real Time Control Protocol
Giao thức điều khiển thời gian thực
RFC
Request For Comments
Đề nghị duyệt thảo và bình luận
QoS
Quality of Service
Chất lượng dịch vụ
IP
Internet Protocol
Giao thức Internet
IPv4
IP version 4
Giao thức Internet phiên bản 4
IPv6
IP version 6
Giao thức Internet phiên bản 6
TCP
Transmission Control Protocol
Giao thức điều khiển truyền thông tin
UDP
User Datagram
Giao thức Datagram người dùng
Protocol
ITU-T
International Telecommunication Hiệp hội viễn thông quốc tế Union- Bộ phận chuẩn viễn thông Telecommunication Standardization Sector
IETF
Internet Engineering Task Force
Nhóm đặc nhiệm kỹ thuật thuật Internet
UA
User Agent
Thành phần trong mạng SIP (SIP client)
UAC
User Agent Client
Thành phần trong mạng SI SIP gửi các request
UAS
User Agent Server
Thành phần trong mạng SIP trả lời các request
SDP
Session Description Protocol
Giao thức mô tả phiên
PHỤ LỤC HÌNH Hình 1.Cấu trúc gói IP phiên bản 4...........................................................................15 Hình 2.Cấu trúc đơn vị dữ li ệu TCP...........................................................................18 Hình 3.Cấu trúc đơn vị dữ li ệu UDP...........................................................................20 Hình 4.Ph ần cố định của đơn vị d ữ li ệu RTP..............................................................22 Hình 5.Ví dụ về Cấ u trúc gói RTP ..............................................................................24 Hình 6.Ph ần mở rộng cấu trúc dữ liệu RTP................................................................24 Hình 7.Kiến trúc giao thứ c SIP..................................................................................29 Hình 8.Hoạt động của UA..........................................................................................31 Hình 9.Hoạt động của Proxy server..........................................................................32 Hình 10.Hoạt động của Redirect server....................................................................32 Hình 11.Hoạt động của Registrar server...................................................................33 Hình 12.SIP transaction và SIP dialog.......................................................................34 Hình 13.Trao đổi bản tin Invite.................................................................................35 Hình 14.Thay đổi các thông s ố của cu ộc g ọi (Re-Invite) ...........................................35 Hình 15.Quá trình đăng ký với Registrar server........................................................36 Hình 16.Quá trình trao đổi bản tin BYE.....................................................................37 Hình 17.Quá trình trao đổi bản tin ACK .....................................................................37 Hình 18.Quá trìn trao đổi bản tin CANCEL................................................................38 Hình 19.Quá trình trao đổi bản tin REFER.................................................................39 Hình 20.Quá trình trao đổi bản tin SUBSCRIBE .........................................................40 Hình 21.Cấu trúc bản tin SIP.....................................................................................44 Hình 22.Ví dụ một bản tin request Invite..................................................................45 Hình 23.Ví dụ bản tin response 200 OK ....................................................................46 Hình 24.Bản tin sử dụng trường CSeq.......................................................................47 Hình 25.mô hình cuộc gọi có sử dụng Join trong bản tin Invite .................................50
Hình 26.Quá trình thay đổi địa chỉ trong NAT...........................................................55 Hình 27.Quá trình đăng ký với Registrar server........................................................59 Hình 28.Cuộc gọi trực ti ếp gi ữa hai UA.....................................................................63 Hình 29.Cuộc gọi thông qua Proxy server.................................................................66 Hình 30.Cấu trúc của hệ thống SS7..........................................................................75 Hình 31.Mô hình cuộc gọi SIP – PSTN ........................................................................77 Hình 32.Mô hình cuộc gọi PSTN - SIP ........................................................................79 Hình 33.Giao diện chính của ch ương trình SIMO.......................................................81
Phụ Lục Bảng Bảng 1: Các trường của giao th ức SDP .....................................................................54 Bảng 2: Các thông tin về user agent, proxy server..................................................58 Bảng 3: Các bản tin l ớp ISUP ....................................................................................76
LỜI MỞ ĐẦU Với sự phát triển nhảy vọt của mạng chuyển mạch gói IP hiện nay không chỉ đem lại cho chúng ta những dịch vụ mới đa dạng mà còn là cơ hội cải thiện các dịch vụ viễn thông trước kia với chất lượng tốt hơn và giá thành rẻ hơn. Đã từ lâu, mạng chuyển mạch kênh ghép phân kênh theo thời gian PSTN đã có một vai trò vô cùng quan trọng với sự phát triển của xã hội. Bên cạnh những ưu điểm về chất lượng dịch vụ tốt, vùng dịch vụ rộng lớn trên khắp mọi lãnh thổ,… thì mạng PSTN cũng bộc lộ nhiều hạn chế như số lượng các dịch vụ hạn chế, sử dụng tài nguyên đường truyền không tối ưu, giá thành cao. Trên cơ sở đó, mạng VoIP ra đời và ngày càng đáp ứng tốt hơn các yêu cầu đặt ra như chất lượng dịch vụ, giá thành, số lượng tích hợp các dịch vụ thoại lẫn phi thoại. Cũng như các công nghệ ra đời trong thời gian gần đây, thì vấn đề Giao thức là đặc biệt quan trọng. Việc nắm chắc Giao thức là chìa khóa thành công của việc triển khai mỗi một công nghệ mới vào thực tế. Chính vì vậy, trong nội dung bài khóa luận tốt nghiệp này, em xin được giới thiệu về “Giao thức khởi tạo phiên SIP” một giao thức được sử dụng rất nhiều trong các ứng dụng VOIP hiện nay. Bài khóa luận sẽ bao gồm hai phần, một phần lý thuyết và một phần giới thiệu về ứng dụng do em xây dựng. Phần lý thuyết gồm các nội dung chính sau: Chương 1: Tổng quan về mạng VOIP Chương 2: Các giao thức truyền tải trong mạng VOIP Chương 3: Giao thức báo hiệu SIP Chương 4: Các mô hình cuộc gọi trong SIP Phần giới thiệu ứng dụng: Chương 5: Giới thiệu ứng dụng Em xin trình bày về ứng dụng do em phát triển có sử dụng giao thức SIP để thiết lập các cuộc gọi điểm – điểm giữa hai đầu cuối. Nội dung phần một trong bài khóa luận này em chủ yếu tập trung đi sâu nghiên cứu thông qua các tài liệu quy chuẩn về giao thức SIP (RFC của IETF), đồng thời tham khảo thêm các tài liệu chuyên môn viết về VOIP để làm rõ hơn vấn đề cần giải quyết.
Phần Một: Lý thuyết Chương 1. Tổng quan về mạng VOIP 1.1. Tổng quan về mạng VOIP Đầu năm 1995 công ty VOCALTEC đưa ra thị trường sản phẩm phần mềm thực hiện cuộc gọi thoại qua Internet đầu tiên trên thế giới. Sau đó có nhiều công ty đã tham gia vào lĩnh vực này. Tháng 3 năm 1996, VOLCALTEC kết hợp với DIALOGIC tung ra thị trường sản phẩm kết nối mạng PSTN và Internet. Hiệp hội các nhà sản xuất thoại qua mạng máy tính đã sớm ra đời và thực hiện chuẩn hoá dịch vụ thoại qua mạng Internet. Việc truyền thoại qua internet đã gây được chú ý lớn trong những năm qua và đã dần được ứng dụng rộng rãi trong thực tế. Có thể định nghĩa: Voice over Internet Protocol (VoIP) là một công nghệ cho phép truyền thoại sử dụng giao thức mạng IP, trên cơ sở hạ tầng sẵn có của mạng Internet. VoIP là một trong những công nghệ viễn thông đang được quan tâm nhất hiện nay không chỉ đối với các nhà khai thác, các nhà sản xuất mà còn cả với người sử dụng dịch vụ. VoIP có thể vừa thực hiện cuộc gọi thoại như trên mạng điện thoại kênh truyền thống (PSTN) đồng thời truyền dữ liệu trên cơ sở mạng truyền dữ liệu. Như vậy, nó đã tận dụng được sức mạnh và sự phát triển vượt bậc của mạng IP vốn chỉ được sử dụng để truyền dữ liệu thông thường. Để có thể hiểu được những ưu điểm của VoIP mang lại, trước hết chúng ta đi vào nghiên cứu sự khác biệt giữa mạng kênh PSTN hiện có với mạng chuyển mạch gói nói chung và mạng VoIP nói riêng. 1.2. Kỹ thuật chuyển mạch kênh (Circuit Switching): Một đặc trưng nổi bật của kĩ thuật này là hai trạm muốn trao đổi thông tin với nhau thì giữa chúng sẽ được thiết lập một “ kênh” (circuit) cố định, kênh kết nối này được duy trì và dành riêng cho hai trạm cho tới khi cuộc truyền tin kết thúc. Thông tin cuộc gọi là trong suốt. Quá trình thiết lập cuộc gọi tiến hành gồm 3 giai đoạn •
Giai đoạn thiết lập kết nối: Thực chất quá trình này là liên kết các tuyến giữa các trạm trên mạng thành một tuyến (kênh) duy nhất dành riêng cho cuộc gọi. Kênh
này đối với PSTN là 64kb/s (do bộ mã hóa PCM có tốc độ lấy mẫu tiếng nói 8kb/s và được mã hóa 8 bit). •
•
Giai đoạn truyền tin: Thông tin cuộc gọi là trong suốt. Sự trong suốt thể hiện qua hai yếu tố: thông tin không bị thay đổi khi truyền qua mạng và độ trễ nhỏ. Giai đoạn giải phóng (huỷ bỏ) kết nối: Sau khi cuộc gọi kết thúc, kênh sẽ được giải phóng để phục vụ cho các cuộc gọi khác. Qua đó, ta nhận thấy mạng chuyển mạch kênh có những ưu điểm nổi bật như chất lượng đường truyền tốt, ổn định, có độ trễ nhỏ. Các thiết bị mạng của chuyển mạch kênh đơn giản, có tính ổn định cao, chống nhiễu tốt. Nhưng ta cũng không thể không nhắc tới những hạn chế của phương thức truyền dữ liệu này như:
•
•
•
Sử dụng băng thông không hiệu quả: Tính không hiệu quả này thể hiện qua hai yếu tố. Thứ nhất, độ rộng băng thông cố định 64k/s. Thứ hai kênh là dành riêng cho một cuộc gọi nhất định. Như vậy, ngay cả khi tín hiệu thoại là “lặng” (không có dữ liệu) thì kênh vẫn không được chia sẻ cho các cuộc gọi khác. Tính an toàn: Do tín hiệu thoại được gửi nguyên bản trên đường truyền nên rất dễ bị nghe trộm. Ngoài ra, đường dây thuê bao hoàn toàn có thể bị lợi dụng để ăn trộm cước viễn thông. Khả năng mở rộng của mạng kênh kém: Thứ nhất là do cơ sở hạ tầng khó nâng cấp và tương thích với các thiết bị cũ. Thứ hai, đó là hạn chế của hệ thống báo hiệu vốn đã được sử dụng từ trước đó không có khả năng tùy biến cao.
1.3. Kỹ thuật chuyển mạch gói (Packet Switching) Trong chuyển mạch gói mỗi bản tin được chia thành các gói tin (packet), có khuôn dạng được quy định trước. Trong mỗi gói cũng có chứa thông tin điều khiển: địa chỉ trạm nguồn, địa chỉ trạm đích và số thứ tự của gói tin,… Các thông tin điều khiển được tối thiểu, chứa các thông tin mà mạng yêu cầu để có thể định tuyến được cho các gói tin qua mạng và đưa nó tới đích. Tại mỗi node trên tuyến gói tin được nhận, nhớ và sau đó thì chuyển tiếp cho tới chạm đích. Điều khó khăn nhất đối với chuyển mạch gói là việc tập hợp các gói tin để tạo bản tin ban đầu, đặc biệt là khi mà các gói tin được truyền theo nhiều con đường khác nhau tới trạm đích. Chính vì lý do trên mà các gói tin cần phải được đánh số thứ tự, điều này có tác dụng, chống lặp, sửa sai và có thể truyền lại khi hiện tượng mất gói xảy ra.
Các ưu điểm của chuyển mạch gói: •
•
•
•
Mềm dẻo và hiệu suất truyền tin cao: Hiệu suất sử dụng đường truyền rất cao vì trong chuyển mạch gói không có khái niệm kênh cố định và dành riêng, mỗi đường truyền giữa các node có thể được các trạm cùng chia sẻ để truyền tin, các gói tin sắp hàng và truyền theo tốc độ rất nhanh trên đường truyền. Khả năng truyền ưu tiên: Chuyển mạch gói còn có thể sắp thứ tự cho các gói để có thể truyền đi theo mức độ ưu tiên. Trong chuyển mạch gói số cuộc gọi bị từ chối ít hơn nhưng phải chấp nhận một nhược điểm vi thời gian trễ sẽ tăng lên. Khả năng cung cấp nhiều dịch vụ thoại và phi thoại. Thích nghi tốt nếu như có lỗi xảy ra: Đặc tính này có được là nhờ khả năng định tuyến động của mạng.
Bên cạnh những ưu điểm thì mạng chuyển mạch gói cũng bộc lộ những nhược điểm như: •
Trễ đường truyền lớn: Do đi qua mỗi trạm, dữ liệu được lưu trữ, xử lý trước khi được truyền đi.
•
Độ tin cậy của mạng gói không cao, dễ xảy ra tắc nghẽn, lỗi mất bản tin
•
Tính đa đường có thể gây ra lặp bản tin, làm tăng lưu lượng mạng không cần thiết.
•
Tính bảo mật trên đường truyền chung là không cao.
1.4. Đặc tính của mạng VoIP
1.4.1.1. Ưu điểm •
Giảm chi phí : Đây là ưu điểm nổi bật của VoIP so với điện thoại đường dài thông thường. Chi phí cuộc gọi đường dài chỉ bằng chi phí cho truy nhập Internet. Một giá cước chung sẽ thực hiện được với mạng Internet và do đó tiết kiệm đáng kể các dịch vụ thoại và fax. Sự chia sẻ chi phí thiết bị và thao tác giữa những người sử dụng thoại và dữ liệu cũng tăng cường hiệu quả sử dụng mạng. Đồng thời kỹ thuật nén thoại tiên tiến làm giảm tốc độ bit từ 64Kbps xuống dưới 8Kbps, tức là một kênh 64Kbps lúc này có thể phục vụ đồng thời 8 kênh thoại độc lập. Như vậy,
lý do lớn nhất giúp cho chi phí thực hiện cuộc gọi VoIP thấp chính là việc sử dụng tối ưu băng thông. •
•
•
•
Tích hợp nhiều dịch vụ: Do việc thiết kế cơ sở hạ tầng tích hợp nên có khả năng hỗ trợ tất cả các hình thức thông tin cho phép chuẩn hoá tốt hơn và giảm thiểu số thiết bị. Các tín hiệu báo hiệu, thoại và cả số liệu đều chia sẻ cùng mạng IP. Tích hợp đa dịch vụ sẽ tiết kiệm chi phí đầu tư nhân lực, chi phí xây dựng các mạng riêng lẻ. Thống nhất: Việc sử dụng thống nhất giao thức IP cho tất cả các ứng dụng hứa hẹn giảm bớt phức tạp và tăng cường tính mềm dẻo. Các ứng dụng liên quan như dịch vụ danh bạ và dịch vụ an ninh mạng có thể được chia sẻ dễ dàng hơn. Vấn đề quản lý băng thông: Trong PSTN, băng thông cung cấp cho một cuộc gọi là cố định. Trong VoIP, băng thông được cung cấp một cách linh hoạt và mềm dẻo hơn nhiều. Chất lượng của VOIP phụ thuộc vào nhiều yếu tố, quan trọng nhất là băng thông. Do đó không có sự bắt buộc nào về mặt thông lượng giữa các thiết bị đầu cuối mà chỉ có các chuẩn tuỳ vào băng thông có thể có của mình, bản thân các đầu cuối có thể tự điều chỉnh hệ số nén và do đó điều chỉnh được chất lượng cuộc gọi. Nâng cao ứng dụng và khả năng mở rộng: Thoại và fax chỉ là các ứng dụng khởi đầu cho VoIP, các lợi ích trong thời gian dài hơn được mong đợi từ các ứng dụng đa phương tiện (multimedia) và đa dịch vụ. Tính linh hoạt của mạng IP cho phép tạo ra nhiều tính năng mới trong dịch vụ thoại. Đồng thời tính mềm dẻo còn tạo khả năng mở rộng mạng và các dịch vụ.
1.4.1.2. Nhược điểm •
Chất lượng dịch vụ chưa cao: Các mạng số liệu vốn dĩ không phải xây dựng với mục đích truyền thoại thời gian thực, vì vậy khi truyền thoại qua mạng số liệu cho chất lượng cuộc gọi không được đảm bảo trong trường hợp mạng xảy ra tắc nghẽn hoặc có độ trễ lớn. Tính thời gian thực của tín hiệu thoại đòi hỏi chất lượng truyền dữ liệu cao và ổn định. Một yếu tố làm giảm chất lượng thoại nữa là kỹ thuật nén để tiết kiệm đường truyền. Nếu nén xuống dung lượng càng thấp thì kỹ thuật nén càng phức tạp, cho chất lượng không cao và đặc biệt là thời gian xử lý sẽ lâu, gây trễ.
•
•
Vấn đề tiếng vọng: Nếu như trong mạng thoại, độ trễ thấp nên tiếng vọng không ảnh hưởng nhiều thì trong mạng IP, do trễ lớn nên tiếng vọng ảnh hưởng nhiều đến chất lượng thoại. Kỹ thuật phức tạp: Truyền tín hiệu theo thời gian thực trên mạng chuyển mạch gói là rất khó thực hiện do mất gói trong mạng là không thể tránh được và độ trễ không cố định của các gói thông tin khi truyền trên mạng. Để có được một dịch vụ thoại chấp nhận được, cần thiết phải có một kỹ thuật nén tín hiệu đạt được những yêu cầu khắt khe: tỉ số nén lớn (để giảm được tốc độ bit xuống), có khả năng suy đoán và tạo lại thông tin của các gói bị thất lạc... Tốc độ xử lý của các bộ Codec (Coder and Decoder) phải đủ nhanh để không làm cuộc đàm thoại bị gián đoạn. Đồng thời cơ sở hạ tầng của mạng cũng cần được nâng cấp lên các công nghệ mới như Frame Relay, ATM,... để có tốc độ cao hơn hoặc phải có một cơ chế thực hiện chức năng QoS (Quality of Service). Tất cả các điều này làm cho kỹ thuật thực hiện điện thoại IP trở nên phức tạp và không thể thực hiện được trong những năm trước đây
Ngoài ra có thể kể đến tính phức tạp của kỹ thuật và vấn đề bảo mật thông tin (do Internet nói riêng và mạng IP nói chung vốn có tính rộng khắp và hỗn hợp, không có gì bảo đảm rằng thông tin cá nhân được giữ bí mật). 1.5. Yêu cầu chất lượng đối với VoIP Từ những nhược điểm chính của mạng chuyển mạch gói đã đặt ra những yêu cầu cho VoIP như sau: •
•
•
Chất lượng thoại phải ổn định, độ trễ chấp nhận được. Mạng IP cơ bản phải đáp ứng được những tiêu chí hoạt động khắt khe gồm giảm thiểu việc không chấp nhận cuộc gọi, mất mát gói và mất liên lạc. Điều này đòi hỏi ngay cả trong trường hợp mạng bị nghẽn hoặc khi nhiều người sử dụng chung tài nguyên của mạng cùng một lúc. Việc báo hiệu có thể tương tác được với báo hiệu của mạng PSTN.
Quản lý hệ thống an toàn, địa chỉ hoá và thanh toán phải được cung cấp, tốt nhất là được hợp nhất với các hệ thống hỗ trợ hoạt động PSTN.
Chương 2. Các giao thức truyền tải trong VOIP 2.1. Giao thức IP Giao thức mạng IP được thiết kế để liên kết các mạng máy tính sử dụng phương pháp truyền thông và nhận dữ liệu dưới dạng gói. Giao thức IP cho phép truyền các gói dữ liệu từ điểm nguồn tới điểm đích có địa chỉ cố định. Đơn vị dữ liệu được trao đổi là các gói dữ liệu. Các chức năng được thực hiện ở IP là: •
•
•
Đánh địa chỉ: tất cả các host trong mạng và trong liên mạng đều được cung cấp một địa chỉ IP duy nhất. Theo giao thức IP version 4, mỗi địa chỉ IP gồm 32bit và được chia làm 5 lớp A,B,C,D,E. Các lớp A,B,C được sử dụng để định danh các host trên các mạng. Lớp D được sử dụng cho quá trình truyền đa điểm còn lớp E để dự phòng. Định tuyến: giúp xác định đường đi (tuyến)cho gói tin khi được truyền trên mạng. Nó giúp lựa chọn đường đi tối ưu cho các gói dữ liệu. Nếu hai host cần liên lạc không nằm trên một subnet thì bảng định tuyến sẽ được sử dụng để quyết định việc chuyển dữ liệu và các bộ định tuyến thường xuyên trao đổi và cập nhật thông tin trong bảng định tuyến tùy thuộc vào phương pháp định tuyến được sử dụng. Truyền đa điểm: Hiện nay có ba cách truyền các gói IP là: o
Truyền một điểm đích (unicast): các gói tin được truyền từ host nguồn đến host đích duy nhất.
o
Truyền quảng bá: gói tin được truyền đến tất cả các host trong mạng.
o
Truyền đa điểm: gói tin được gửi đến một số các host nhất định trong mạng
Ngoài ra, giao thức IP còn cung cấp khả năng phân mảnh dữ liệu lớn thành các gói có kích thước nhỏ hơn để truyền qua mạng.
2.2. Giao thức IP phiên bản 4 (IPv4) Cấu trúc của header IPv4 như sau:
Hình 1. Cấu trúc gói IP phiên bản 4 Ý nghĩa các trường như sau: •
•
•
Version: độ rộng 4 bit mô tả phiên bản IP IP Header Length(IHL): có độ rộng 4 bit, xác định độ rộng của phần tiêu đề của gói tin IP Type of Service: có độ rộng 8 bit, xác định các tham số chỉ dịch vụ sử dụng khi truyền gói tin qua mạng. Rất nhiều mạng cung cấp các dịch vụ về độ ưu tiên lưu thông, đặc biệt khi mạng bị quá tải. Việc lựa chọn này đảm bảo đường truyền đạt ba tiêu chuẩn là thời gian trễ, độ tin cậy, bộ thông suốt của gói tin. Được mô tả cụ thể như sau: o
Quyền ưu tiên (3 bit)
o
o
o
•
•
•
Độ trễ D (1 bit)
D=0: độ trễ bình thường
D=1: độ trễ cao
Thông lượng T (1bit)
T=0: thông lượng bình thường
T=1: thông lượng cao
Độ tin cậy (1bit):
R=0: độ tin cậy bình thường
R=1: độ tin cậy cao
Total Length (16bit): xác định độ dài của gói tin kể cả phần tiêu đề. Có giá trị tối đa là 65535 byte. Thông thường các host chỉ có thể xử lý gói tin có độ dài là 576 byte gồm 512 byte dữ liệu và 64 byte tiêu đề. Các host chỉ có thể gửi các gói tin có độ dài lớn hơn 576 byte khi biết trước là host đích có khả năng xử lý gói này. Indentification: cùng với trường địa chỉ nguồn, đích dùng để định danh duy nhất cho một gói tin trong khoảng thời gian nó tồn tại. Flag : có độ rộng 3 bit, chỉ độ phân đoạn của gói tin o
Bit 0: luôn bằng 0
o
Bit 1 (DF):
o
DF=0: có phân đoạn
DF=1: không phân đoạn
Bit 2 (MF):
MF=0: mảnh cuối cùng
•
MF=1: không phải mảnh cuối cùng
Fragment Offset: độ rộng 13 bit, chỉ rõ vị trí của phân mảnh trong gói tin tính theo đơn vị 64bit.
•
Time to Live: độ rộng 8 bit, quy định thời gian tồn tại của gói tin.
•
Protocol: độ rộng 8 bit, xác định giao thức tầng giao vận. Ví dụ
•
o
Protocol = 6: giao thức TCP
o
Protocol=17: giao thức UDP
Header Checksum: độ rộng 16 bit, mã kiểm tra CRC-16 của phần tiêu đề cho phát hiện lỗi
•
Source Address: độ rộng 32 bit, xác định địa chỉ nguồn.
•
Destination Address: độ rộng 32 bit, xác định địa chỉ đích
•
Option: có độ dài thay đổi để lưu thông tin tùy biến của người dùng
•
Padding: có độ dài thay đổi, đảm bảo độ dài của header luôn là bội 32 bit
•
Data: có độ dài tối đa là 65535 byte chứa dữ liệu lớp cao hơn.
2.3. Giao thức TCP Giao thức TCP là giao thức điều khiển truyền thông hướng kết nối và có độ tin cậy cao. TCP là giao thức được xây dựng phức tạp hơn UDP rất nhiều, ngoài các dịch vụ như UDP, TCP còn cung cấp các dịch vụ khác cho ứng dụng. Dịch vụ quan trọng nhất là truyền dữ liệu có độ tin cậy cao, các cơ chế điều khiển lưu lượng và kiểm soát tắc nghẽn, đánh số thứ tự và số thứ tự bên nhận, bộ định thời,....Cụ thể TCP cung cấp các dịch vụ sau: •
Thiết lập liên kết: TCP là giao thức hướng kết nối, trước khi gửi dữ liệu cần thiết lập trước đường truyền (chính là 1 liên kết lôgic giữa hai thực thể TCP), thủ tục này gọi là thủ tục “bắt tay”. Liên kết được thiết lập phải đảm bảo tính chính xác và độ tin cậy, một liên kết khi không còn đủ độ tin cậy thì sẽ bị huỷ bỏ và thiết lập lại. Khi quá trình truyền tin hoàn thành thì kết nối được giải phóng .
•
•
•
Cung cấp đường truyền hai chiều (song công - full duplex). Đảm bảo độ tin cậy: Giao thức TCP cung cấp các tham số kiểm tra cùng với số thứ tự (Sequence number), xác nhận (ACKnowledge ) và kiểm tra lỗi tổng (Checksum). Các segment được đánh số tuần tự, cách làm này nhằm mục đích loại bỏ các segment bị trùng lặp hay không đúng yêu cầu. Tại bên thu, khi nhận được các segment thực hiện việc kiểm tra nhờ trường checksum. Nếu segment nhận được không lỗi hay lặp, tín hiệu ACK sẽ được gửi trả lại bên phát để khẳng định dữ liệu nhận tốt. Ngược lại nếu segment nhận được bị lỗi hay bị trùng lặp thì segment này sẽ được loại bỏ và bên thu sẽ gửi một tín hiệu yêu cầu bên phát phát lại segment bị lỗi đó, bằng cơ chế này sẽ đảm bảo tính chính xác và độ tin cậy cho dữ liệu. Cung cấp các dịch vụ (chức năng) kiểm tra đường truyền, cho phép điều khiển luồng và điều khiển tắc nghẽn.
Trong ứng dụng VoIP, giao thức TCP được sử dụng làm giao thức truyền báo hiệu chứ không phục vụ việc truyền tín hiệu thoại. Lý do là vì phần header của TCP lớn
Hình 2.
Cấu trúc đơn vị dữ liệu TCP
Ý nghĩa các trường như sau: •
Source Port: độ dài 16 bit, xác định số hiệu cổng của trạm nguồn
•
Destination Port: độ dài 16 bit, xác định số hiệu cổng của trạm đích
•
Sequence Number: độ dài 32 bit. Số hiệu của byte đầu tiên của segment từ khi bit SYN được thiết lập. Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần tự khởi đầu (ISN) và byte dữ liệu đầu tiên là ISN+1
•
•
•
•
•
•
•
•
•
ACK Number: độ dài 32 bit, xác định số hiệu của segment tiếp theo mà trạm nguồn đang chờ được xác nhận Data Offset: độ dài 4 bit, xác định vị trí bắt đầu của khối dữ liệu lớp trên trong đơn vị dữ liệu TCP. Control bit: o
URG: vùng Urgent Pointer có hiệu lực
o
ACK: vùng ACK có hiệu lực
o
PSH: chức năng Push
o
RST: khởi động lại liên kết
o
SYN: đồng bộ hóa các số hiệu tuần tự
o
FIN: không còn số liệu từ trạm cuối
Window: cấp phát thẻ bài để kiểm soát luồng dữ liệu theo cơ chế cửa sổ. Đây chính là số lượng các byte dữ liệu bắt đầu từ byte được chỉ ra trong vùng ACK mà trạm nguồn sẵn sàng nhận. Checksum: mã CRC-16 Urgent Pointer: con trỏ trỏ tới số hiệu tuần tự của byte đi sau dữ liệu khẩn, cho bên nhận biết được độ dài của dữ liệu khẩn. Vùng này có hiệu lực khi bit URG được thiết lập. Option: có độ dài thay đổi, khai báo các lựa chọn của TCP trong đó có độ dài tối đa của vùng dữ liệu trong một đơn vị dữ liệu segment. Padding: đảm bảo phần tiêu đề của TCP luôn là bội 32 bit. TCP data: chứa dữ liệu lớp trên có giá trị tối đa là 536 byte. Giá trị này có thể thay đổi nhờ khai báo trong Option
2.4. Giao thức UDP UDP là giao thức lớp Giao vận đơn giản nhất, được mô tả trong RFC 768. Ứng dụng gửi bản tin tới socket UDP, sau đó được đóng gói thành một UDP datagram và được truyền xuống lớp IP để gửi tới đích. Gói tin UDP được truyền mà không đảm bảo rằng nó có thể tới đích, giữ đúng thứ tự và đến đích một lần. Vấn đề của người lập trình mạng với UDP là đảm bảo tính tin cậy. Nếu datagram tới đích nhưng trường kiểm tra tổng (checksum) có lỗi hay gói tin bị drop ở trên mạng thì nó sẽ được truyền lại. Nếu muốn xác định được rằng gói tin đã tới đích thì cần rất nhiều tính năng trong ứng dụng: ACK từ đầu cuối khác, điều khiển việc truyền lại,.. Mỗi một UDP datagram có chiều dài và được truyền lên cùng với dữ liệu cho lớp ứng dụng. Điều này khác với TCP là giao thức luồng byte (byte-stream protocol). Chúng ta cũng có thể nói: UDP cung cấp dịch vụ không hướng kết nối. Ví dụ, client UDP có thể tạo một socket và gửi datagram tới server này và sau đó gửi một datagram khác cũng tới server khác. Cũng giống như server UDP có thể nhận nhiều datagram trên một socket UDP từ các client khác nhau.
Hình 3. Cấu trúc đơn vị dữ liệu UDP 2.5. Giao thức RTP RTP là một giao thức dựa trên giao thức IP tạo ra các hỗ trợ để truyền tải các dữ liệu yêu cầu thời gian thực với các yêu cầu:
Liên tục: Các gói tin phải được sắp xếp theo đúng thứ tự khi chúng đến bên nhận, các gói đến có thể không theo thứ tự và nếu gói tin bị mất thì bên nhận phải dò tìm hay bù lại sự mất các gói tin này.
Sự đồng bộ trong các phương thức truyền thông: Các khoảng lặng trong tiếng nói được triệt và nén lại để giảm thiểu băng thông cần thiết, tuy nhiên khi đến bên nhận, thời gian giữa các khoảng lặng này phải được khôi phục một cách chính xác.
Sự đồng bộ giữa các phương thức truyền thông: Có thể tín hiệu thoại sử dụng một phương thức truyền thông trong khi tín hiệu video lại sử dụng một phương thức
truyền thông khác, các tín hiệu tiếng và hình phải được đồng bộ một cách chính xác, gọi là sự đồng bộ tiếng - hình.
Sự nhận diện phương thức truyền tải: Trong Internet, thông thường cần thay đổi sự mã hoá cho phương thức truyền tải (payload) trên hành trình truyền để hiệu chỉnh thay đổi độ rộng băng thông sẵn sàng hoặc đủ khả năng cho người dùng mới kết nối vào nhóm. Một vài cơ chế cần được sử dụng để nhận diện sự mã hoá cho mỗi gói đến. Các dịch vụ cung cấp bởi RTP bao gồm:
Đa phát đáp thân thiện: (multicast – friendly): RTP và RTCP là kỹ thuật cho đa phát đáp, cung cấp khả năng mở rộng cuộc hội thoại nhiều bên. Trên thực tế, chúng được thiết kế để có thể hoạt động trong cả các nhóm đa phát đáp nhỏ, phù hợp cho các cuộc điện đàm ba bên. Đối với các nhóm lớn, chúng sử dụng đa phát đáp quảng bá (broadcasting).
Độc lập thiết bị: RTP cung cấp các dịch vụ cần thiết chung cho phương thức truyền thông thời gian thực nói chung như thoại, video hay bất kì một bộ mã hoá, giải mã cụ thể nào có sự định nghĩa các phương thức mã hoá và giải mã riêng bằng các thông tin tiêu đề và định nghĩa.
Mã hoá thành mật mã: Các dòng phương thức truyền thông RTP có thể mã hoá thành mật mã dùng các khoá, việc mã hoá đảm bảo cho việc thông tin trên mạng được an toàn hơn. Các gói tin truyền trên mạng Internet có trễ và jitter không dự đoán được. Nhưng các ứng dụng đa phương tiện yêu cầu một thời gian thích hợp khi truyền các dữ liệu và phát lại. RTP cung cấp các cơ chế bảo đảm thời gian, số thứ tự và các cơ chế khác liên quan đến thời gian. Bằng các cơ chế này RTP cung cấp sự truyền tải dữ liệu thời gian thực giữa các đầu cuối qua mạng.
Bản thân RTP không cung cấp một cơ chế nào cho việc bảo đảm phân phối kịp thời các dữ liệu tới các trạm mà nó dựa trên các dịch vụ của tầng thấp hơn để thực hiện điều này. RTP cũng không đảm bảo việc truyền các gói theo đúng thứ tự. Tuy nhiên, số thứ tự trong RTP header cho phép bên thu xây dựng lại đúng thứ tự các gói của bên phát. Hoạt động của RTP được hỗ trợ bởi một giao thức khác là RTCP để nhận các thông tin phản hồi về chất lượng truyền dẫn và các thông tin về thành phần tham dự các phiên hiện thời. Không giống như các giao thức khác là sử dụng các trường trong header
để thực hiện các chức năng điều khiển, RTP sử dụng một cơ chế điều khiển độc lập trong định dạng của gói tin RTCP để thực hiện các chức năng này. Khuôn dạng bản tin RTP: RTP header bao gồm một phần cố định có ở mọi gói RTP và một phần mở rộng phục vụ cho các mục đích nhất định. Phần cố định:
Hình 4. •
•
Version (2 bits): Chỉ ra version của RTP, hiện nay là version 2. Padding (1 bit): Nếu bit này được đặt, sẽ có thêm một vài octets thêm vào cuối gói dữ liệu. Các octets này không phải là thông tin, chúng được thêm vào để nhằm mục đích: o
o
•
•
•
•
Phần cố định của đơn vị dữ liệu RTP
Phục vụ cho một vài thuật toán mã hoá thông tin cần kích thước của gói cố định. Dùng để cách ly các gói RTP trong trường hợp có nhiều gói thông tin được mang trong cùng một đơn vị dữ liệu của giao thức ở tầng dưới.
Extension (1 bit): nếu bit này được đặt, thì theo sau phần header cố định sẽ là một header mở rộng. Contributing Sources Count (4 bits): số lượng các thành phần nhận dạng nguồn CSRC nằm trong phần header gói tin. Số này lớn hơn 1 nếu các gói tin RTP đến từ nhiều nguồn. Marker (1 bit): mang ý nghĩa khác nhau, tuỳ theo từng trường hợp cụ thể, được chỉ ra trong profile đi kèm. Payload Type (7 bits): chỉ ra loại tải trọng mang trong gói. Các mã sử dụng trong trường này ứng với các loại tải trọng được quy định trong một profile đi kèm.
•
•
Sequence Number (16 bits): mang số thứ tự của gói RTP. Số này được tăng thêm 1 sau mỗi gói RTP được gửi đi. Có thể được sử dụng để phát hiện được sự mất gói và khôi phục mất gói tại đầu thu. Giá trị khởi đầu của trường này là ngẫu nhiên. Time stamp (tem thời gian, 32 bits): Phản ánh thời điểm lấy mẫu của octet đầu tiên trong gói RTP. Thời điểm này được lấy từ một đồng hồ tăng đều đặn và tuyến tính theo thời gian để cho phép việc đồng bộ và tính toán độ jitter. Tần số đồng hồ này không cố định, tuỳ thuộc vào loại tải trọng. Giá trị khởi đầu được chọn ngẫu nhiên. Một vài gói RTP có thể mang cùng một giá trị “Tem thời gian” nếu như chúng được phát đi cùng lúc về mặt logic. Nếu gói dữ liệu được phát ra đều đặn thì “tem thời gian” được tăng một cách đều đặn. Trong trường hợp khác thì giá trị “tem thời gian” tăng không đều. “Tem thời gian” là thành phần thông tin quan trọng nhất trong các ứng dụng thời gian thực. Người gửi thiết lập các “tem thời gian” ngay thời điểm octet đầu tiên của gói được lấy mẫu. “Tem thời gian” tăng dần theo thời gian đối với mọi gói. Sau khi nhận được gói dữ liệu, bên thu sử dụng các “tem thời gian” này nhằm khôi phục thời gian gốc để chạy các dữ liệu này với tốc độ thích hợp. Ngoài ra, nó còn được sử dụng để đồng bộ các dòng dữ liệu khác nhau (chẳng hạn như giữa hình và tiếng). Tuy nhiên RTP không thực hiện đồng bộ mà các ứng dụng phía trên sẽ thực hiện sự đồng bộ này.
•
•
Synchronization Source Identifier (SSRC, 32 bits): chỉ ra nguồn đồng bộ của gói RTP, số này được chọn ngẫu nhiên. Trong 1 phiên RTP có thể có nhiều hơn một nguồn đồng bộ. Mỗi một nguồn phát ra một luồng RTP. Bên thu nhóm các gói của cùng một nguồn đồng bộ lại với nhau để phát lại tín hiệu thời gian thực. Contributing Source Identifier (CSRC, từ 0-15 mục, mỗi mục 32 bits): chỉ ra những nguồn đóng góp thông tin vào phần tải trọng của gói. Giúp bên thu nhận biết được gói tin này mang thông tin của những nguồn nào.
Hình 5.
Ví dụ về Cấu trúc gói RTP
Phần mở rộng: có độ dài thay đổi. Sự tồn tại phụ thuộc vào bit Extension của phần cố định.
Hình 6. •
•
Phần mở rộng cấu trúc dữ liệu RTP
16 bit đầu tiên được sử dụng với mục đích riêng cho từng ứng dụng được định nghĩa bởi profile. Thường được dùng để phân biệt các loại header mở rộng. Length (16 bits): giá trị chiều dài phần header mở rộng tính theo đơn vị 32 bit, không bao gồm 32 bit đầu tiên của phần header mở rộng.
Cơ chế mở rộng của RTP cho phép các ứng dụng riêng lẻ của giao thức RTP thực hiện được với những chức năng mới đòi hỏi những thông tin thêm vào phần header của gói. Cơ chế này được thiết kế để một vài ứng dụng có thể bỏ qua phần header mở rộng này (mà vẫn không ảnh hưởng tới hoạt động) trong khi một số ứng dụng khác lại có thể sử dụng được phần đó. Bộ phận nhận dạng tải xác định kiểu định dạng của tải tin cũng như cách mã hoá và nén. Từ các bộ phận định dạng này, các ứng dụng phía thu biết cách phân tích và chạy các dòng dữ liệu tải tin. Tại một thời điểm bất kỳ trong quá trình truyền tin, các bộ phát RTP chỉ có thể gửi một dạng của tải tin cho dù dạng của tải tin có thể thay đổi trong thời gian truyền (thay đổi để thích ứng với sự tắc nghẽn của mạng).
Một chức năng khác của RTP là xác định nguồn: cho phép phía thu biết được dữ liệu đến từ đâu. Ví dụ trong thoại hội nghị, từ thông tin nhận dạng nguồn một người sử dụng có thể biết được ai đang nói. RTP được cố tình để cho không hoàn thiện. Nó chỉ cung cấp các dịch vụ phổ thông nhất cho hầu hết các ứng dụng truyền thông hội nghị đa phương tiện. Mỗi một ứng dụng cụ thể đều có thể thêm vào RTP các dịch vụ mới sao cho phù hợp với các yêu cầu của nó. Các khả năng mở rộng này được mô tả trong một profile đi kèm. Profile này còn chỉ ra các mã tương ứng sử dụng trong trường PT (Payload Type) của phần tiêu đề RTP ứng với các loại tải trọng mang trong gói. RTP nằm ở phía trên UDP, sử dụng các chức năng ghép kênh và kiểm tra của UDP. Sở dĩ UDP được sử dụng làm thủ tục truyền tải cho RTP là bởi vì 2 lý do: •
Thứ nhất, RTP được thiết kế chủ yếu cho việc truyền tin đa đối tượng, các kết nối có định hướng, có báo nhận không đáp ứng tốt điều này.
Thứ hai, đối với dữ liệu thời gian thực, độ tin cậy không quan trọng bằng truyền đúng theo thời gian. Hơn nữa, sự tin cậy trong TCP là do cơ chế báo phát lại, không thích hợp cho RTP. Ví dụ khi mạng bị tắc nghẽn một số gói có thể mất, chất lượng dịch vụ dù thấp nhưng vẫn có thể chấp nhận được. Nếu thực hiện việc phát lại thì sẽ gây nên độ trễ rất lớn cho chất lượng thấp và gây ra sự tắc nghẽn của mạng. Thực tế RTP được thực hiện chủ yếu trong các ứng dụng mà tại các mức ứng dụng này có các cơ chế khôi phục lại gói bị mất, điều khiển tắc nghẽn. •
Mạng Internet hiện nay vẫn chưa thể đáp ứng được đầy đủ các yêu cầu của các dịch vụ thời gian thực. Các dịch vụ RTP yêu cầu băng thông cao có thể làm giảm chất lượng các dịch vụ khác trong mạng đến mức nghiêm trọng. Trong quá trình triển khai phải chú ý đến giới hạn băng thông sử dụng của các ứng dụng trong mạng. 2.6. Giao thức RTCP RTCP (Real-time Transport Control Protocol) là giao thức hỗ trợ cho RTP cung cấp các thông tin phản hồi về chất lượng truyền dữ liệu. Các dịch vụ mà RTCP cung cấp là: •
Giám sát chất lượng và điều khiển tắc nghẽn: Đây là chức năng cơ bản của RTCP. Nó cung cấp thông tin phản hồi tới một ứng dụng về chất lượng phân phối dữ liệu. Thông tin điều khiển này rất hữu ích cho các bộ phát, bộ thu và giám sát. Bộ phát
có thể điều chỉnh cách thức truyền dữ liệu dựa trên các thông báo phản hồi của bộ thu. Bộ thu có thể xác định được tắc nghẽn là cục bộ, từng phần hay toàn bộ. Người quản lý mạng có thể đánh giá được hiệu suất mạng. •
•
•
Xác định nguồn: Trong các gói RTP, các nguồn được xác định bởi các số ngẫu nhiên có độ dài 32 bít, các số này không thuận tiện đối với người sử dụng. RTCP cung cấp thông tin nhận dạng nguồn cụ thể hơn ở dạng văn bản. Nó có thể bao gồm tên người sử dụng, số điện thoại, địa chỉ e-mail và các thông tin khác. Đồng bộ môi trường: Các thông báo của bộ phát RTCP chứa thông tin để xác định thời gian và nhãn thời gian RTP tương ứng. Chúng có thể được sử dụng để đồng bộ giữa âm thanh với hình ảnh. Điều chỉnh thông tin điều khiển: Các gói RTCP được gửi theo chu kỳ giữa những người tham dự. Khi số lượng người tham dự tăng lên, cần phải cân bằng giữa việc nhận thông tin điều khiển mới nhất và hạn chế lưu lượng điều khiển. Để hỗ trợ một nhóm người sử dụng lớn, RTCP phải cấm lưu lượng điều khiển rất lớn đến từ các tài nguyên khác của mạng. RTP chỉ cho phép tối đa 5% lưu lượng cho điều khiển toàn bộ lưu lượng của phiên làm việc. Điều này được thực hiện bằng cách điều chỉnh tốc độ phát của RTCP theo số lượng người tham dự. Mỗi người tham gia một phiên truyền RTP phải gửi định kỳ các gói RTCP đến tất cả những người khác cũng tham gia phiên truyền. Nhờ vậy mà có thể theo dõi được số người tham gia.
Gói RTCP góp phần làm tăng nghẽn mạng. Băng thông yêu cầu bởi RTCP là 5% tổng số băng thông phân bổ cho phiên. Khoảng thời gian trung bình giữa các gói RTCP được đặt tối thiểu là 5s. Các loại thông báo điều khiển chính được RTCP cung cấp là: •
•
SR (Sender Report): chứa các thông tin thống kê liên quan tới kết quả truyền như tỷ lệ tổn hao, số gói dữ liệu bị mất, khoảng trễ. Các thông báo này phát ra từ phía phát trong 1 phiên truyền thông. RR (Receiver Report): Chứa các thông tin thống kê liên quan tới kết quả nhận, được phát từ phía thu trong 1 phiên truyền thông.
•
SDES (Source Description): thông số mô tả nguồn (tên, vị trí…)
•
APP (Application): cho phép truyền các dữ liệu ứng dụng
•
BYE: chỉ thị sự kết thúc tham gia vào phiên truyền.
Giá trị của trường PT (Packet Type) ứng với mỗi loại gói được liệt kê trong bảng sau.
Mỗi gói thông tin RTCP bắt đầu bằng 1 phần tiêu đề cố định giống như gói RTP thông tin. Theo sau đó là các cấu trúc có chiều dài thay đổi theo loại gói nhưng luôn bằng số nguyên lần 32 bit. Các gói thông tin RTCP có thể gộp lại với nhau thành các hợp gói (compound packet) để truyền xuống lớp dưới mà không phải chèn thêm các bit cách ly. Số lượng gói trong hợp gói tuỳ thuộc vào chiều dài đơn vị dữ liệu lớp dưới. Mọi gói RTCP đều phải được truyền, ngay cả khi chỉ có một gói duy nhất. Khuôn dạng hợp gói được đề xuất như sau: •
•
•
Encription Prefix (32 bit): Được dành khi hợp gói cần mã hoá. Giá trị trong trường này cần tránh trùng với 32 bit đầu tiên trong gói RTP Gói đầu tiên trong hợp gói luôn là SR hoặc RR. Nếu không thu nhận thông tin, hoặc hợp gói chỉ có một gói BYE thì một gói RR rỗng được dẫn đầu trong hợp gói. Nếu số lượng các nguồn lớn hơn 31 (không vừa trong một gói SR hoặc RR) thì các gói RR thêm vào sẽ theo sau gói thống kê đầu tiên. Việc bao gồm gói thống kê (RR hoặc SR) trong mỗi hợp gói nhằm thông tin thường xuyên về chất lượng thu của những người tham gia. Việc gửi hợp gói đi được tiến hành một cách đều đặn và thường xuyên theo khả năng cho phép của băng thông.
•
Trong hợp gói có gói SDES nhằm thông báo về nguồn phát.
•
Các gói APP nằm ở vị trí bất kỳ trong hợp gói.
•
Gói BYE nằm ở vị trí cuối cùng.
Chương 3. Giao thức khởi tạo phiên SIP 3.1. Giới thiệu về giao thức SIP
3.1.1.1. Giới thiệu SIP (Session Initiation Protcol ) là giao thức báo hiệu điều khiển lớp ứng dụng được dùng để thiết lập, duy trì, kết thúc các phiên truyền thông đa phương tiện (multimedia). Các phiên multimedia bao gồm thoại Internet, hội nghị, và các ứng dụng tương tự có liên quan đến các phương tiện truyền đạt (media) như âm thanh, hình ảnh, và dữ liệu. SIP sử dụng các bản tin mời (INVITE) để thiết lập các phiên và để mang các thông tin mô tả phiên truyền dẫn. SIP được IETF đưa ra trong RFC 3261. Nó là một giao thức dựa trên ý tưởng và cấu trúc của HTTP (HyperText Transfer Protocol) giao thức trao đổi thông tin của World Wide Web và là một phần trong kiến trúc multimedia của IETF. SIP có thể hoạt động kết hợp với các giao thức báo hiệu khác như H.323. SIP là một giao thức theo thiết kế mở do đó nó có thể được mở rộng để phát triển thêm các chức năng mới. Sự linh hoạt của các bản tin SIP cũng cho phép đáp ứng các dịch vụ thoại tiên tiến bao gồm cả các dịch vụ di động.
Hình 7. Kiến trúc giao thức SIP
3.1.1.2. Địa chỉ SIP (SIP URI) Trong giao thức SIP, các users được nhận diện thông qua một địa chỉ SIP URI(Universal Resource Identifier), nó tương tự như địa chỉ Email. Ví dụ 1 địa chỉ SIP URI: sip:
[email protected]. Một địa SIP URI có cấu trúc như sau: bắt đầu bằng sip: tiếp theo gồm có 2 phần được ngăn cách bởi dấu “@” (
[email protected]). Phần trước dấu @ là phần user part, để nhận diện ra một tài nguyên xác định tại địa chỉ host, phần sau dấu @ là phần host part, cái này có thể là tên domain(dhsphn.edu.vn) hoặc một địa chỉ IP. SIP URI có thể có thêm một vài tham số, các tham số này được thêm vào sau phần host và được ngăn cách bởi dấu chấm phẩy (;). Vd: sip:
[email protected];transport=tcp Một SIP URI cũng có thể được sử dụng để biểu diễn cho một địa chỉ SIP server Vd: Sip:proxy1.abc.com hoặc Sip:192.168.1.40
3.1.1.3. Chức năng của SIP Giao thức SIP có 4 chức năng chính đó là: •
Thiết lập một phiên truyền thông đa phương tiện
•
Thay đổi một phiên đã tồn tại
•
Hủy bỏ một phiên
•
Định vị người sử dụng
3.1.1.3.1. Thiết lập một phiên SIP sử dụng bản tin mời (Invite) để yêu cầu thiết lập một phiên truyền thông, bản tin Invite được gửi từ đầu cuối tới đầu cuối hoặc từ đầu cuối tới proxy server.
3.1.1.3.2. Thay đổi một phiên đang tồn tại Khi một phiên đang tồn tại, một đầu cuối mong muốn thay đổi các thông số của phiên đó, đầu cuối đó sẽ gửi lại bản tin Invite với ID trùng với ID của phiên cũ, nhưng nội dung mới. Chẳng hạn, hai đối tác đang trò chuyện và muốn thêm vào một người thứ ba. Một trong hai sẽ mời người thứ ba với địa chỉ multicast mới và đồng thời gửi bản tin INVITE đến đối tác thứ hai với sự mô tả phiên multicast mới , ngoại trừ số ID của cuộc gọi là cũ.
3.1.1.3.3. Hủy bỏ một phiên Khi một phiên đang tồn tại, một đầu cuối mong muốn kết thúc phiên đó sẽ gửi một bản tin BYE tới các đầu cuối khác để yêu cầu thoát khỏi phiên. Ví dụ, hai đối tác đang trò chuyện, một bên muốn kết thúc cuộc nói chuyện sẽ gửi bản tin BYE tới bên kia yêu cầu kết thúc cuộc gọi.
3.1.1.3.4. Định vị người sử dụng Những người sử dụng cuối có thể sẽ luôn di động, và địa chỉ IP của họ là không cố định, các đầu cuối có thể đăng ký với một SIP server thông qua bản tin REGISTER, SIP server sẽ lưu lại địa chỉ IP của đầu cuối đăng ký. Khi có một yêu cầu thiết lập một cuộc gọi tới sip server, SIP server sẽ tìm địa chỉ của người bị gọi và forward bản tin Invite tới người bị gọi. Hoặc trong trường hợp hai đầu cuối muốn thực hiện một cuộc gọi trực tiếp với nhau mà không phải thông qua SIP server đầu cuối gọi sẽ thông qua Redirect server để lấy địa chỉ IP của đầu cuối bị gọi, qua đó gửi bản tin Invite trực tiếp tới đầu cuối bị gọi bằng địa chỉ IP mà Redirect server trả về.
3.1.1.4. Các thành phần trong mạng SIP Một mạng SIP bao gồm 4 thành phần: •
User Agents
•
Proxy Server
•
Redirect Server
•
Registrar Server
Mỗi thành phần thực hiện những chức năng khác nhau và độc lập với các thành phần khác trong mạng. các thành phần proxy server, redirect server, registrar server là các thành phần tùy chọn chúng có thể không xuất hiện, tuy nhiên trong thực tế để đảm bảo tính bảo mật thì các cuộc gọi trước khi diễn ra đều phải thông qua quá trình chứng thực cuộc gọi, lúc này cần có sự xuất hiện của proxy server để làm nhiệm vụ chứng thực, các thành phần như redirect server, registrar server, location server thường được tích hợp luôn vào trong proxy server. Mỗi thành phần trong mạng SIP được xác định thông qua một địa chỉ URI(Uniform Resource Information).
3.1.1.4.1. User Agent(UA) User agent là các đầu cuối trong mạng SIP, nó đại diện cho phía người sử dụng để khởi tạo một yêu cầu tới SIP server hoặc user agent server. Trong user agent có user agent client(UAC) và user agent server(UAS). UAC có trách nhiệm tạo ra các yêu cầu(requests) và nhận các phản hồi từ các yêu cầu đó, còn UAS có trách nhiệm nhận các yêu cầu và tạo ra các phản hồi(response) tương ứng với các yêu cầu đó.
Hình 8.
Hoạt động của UA
3.1.1.4.2. Proxy Server Là thực thể trong mạng SIP làm nhiệm vụ chuyển tiếp các SIP request tới thực thể khác trong mạng. Như vậy, chức năng chính của nó trong mạng là định tuyến cho các bản tin đến đích. Proxy server cũng cung cấp các chức năng xác thực trước khi cho khai thác dịch vụ. có 2 kiểu proxy server là stateful và stateless proxy. Stateful proxy lưu các bản tin request được gửi tới, cùng với các bản tin response tương ứng và các bản tin request được nó gửi tới các user agents và proxy khác. Một Stateless proxy không lưu trữ bất kỳ thông tin nào.
Hình 9. Hoạt động của Proxy server
3.1.1.4.3. Redirect Server Một redirect server là một user agent server nhận các bản tin request từ user agent client và trả về bản tin response ở lớp 300 tương ứng để thông báo cho user agent client chuyển hướng bản tin tới địa chỉ khác – tự liên lạc thông qua địa chỉ trả về.
Hình 10. Hoạt động của Redirect server
3.1.1.4.4. Registrar server Là server nhận bản tin SIP REGISTER và cập nhật các thông tin mà user agents cung cấp từ bản tin Register(địa chỉ IP, port…) vào location database
Hình 11. Hoạt động của Registrar server
3.1.1.5. SIP Transactions và SIP Dialogs 3.1.1.5.1. SIP Transactions Một SIP Transaction được hiểu như là một chuỗi các bản tin request/response. Một SIP clients gửi một bản tin request tới SIP server, và SIP server gửi trả lại bản tin response tương ứng.
3.1.1.1.1. SIP Dialogs Một SIP Dialogs duy trì một mối quan hệ ngang hàng giữa 2 User Agent(UA), mối quan hệ này được thể hiện thông qua việc trao đổi các bản tin giữa 2 UA. Một SIP Dialog sử dụng giá trị của trường header CALL-ID để phân biệt với một dialog khác, giá trị của trường CALL-ID là duy nhất.
Alice
John Invite 180 Ringing
Transaction 1
200 OK
Dialog 1
BYE Transaction 2
200 OK
Hình 12. SIP transaction và SIP dialog 3.2. Các loại bản tin SIP
3.2.1.1. Bản tin yêu cầu (Request) Được gửi từ client tới server. RFC 3261 định nghĩa 6 kiểu bản tin request cho phép UA và proxy có thể xác định người dùng, khởi tạo, sửa đổi, hủy một phiên, ngoài ra trong các phiên bản RFC khác còn định nghĩa thêm một số bản tin mở rộng của SIP.
3.2.1.1.1. Bản tin INVITE Được UAC sử dụng để yêu cầu thiết lập một cuộc gọi với UAS. Khi một UA muốn thiết lập một cuộc gọi với một UA khác, nó sẽ gửi bản tin INVITE tới địa chỉ của UA kia, trong bản tin INVITE này sẽ chứa các thông tin như địa chỉ SIP (SIP URI) của phía gọi, hoặc các thông tin mô tả phiên nằm trong phần message body các thông tin này thường được mô tả bằng giao thức SDP(Session Description Protocol), các thông tin mô tả phiên thường là các thông tin như các chuẩn mã hóa âm thanh, hình ảnh (codecs), các thông tin cần thiết để mở các kênh logic. Bản tin INVITE có thể được gửi trực tiếp giữa UAC và UAS hoặc là thông qua một vài Proxy Server. UAS khi nhận được bản tin INVITE nó sẽ sinh ra các bản tin Response để thông báo cho phía gọi biết về tiến trình của cuộc gọi. Ví dụ. UAS gửi trả lời bản tin Response 180 để thông báo cho bên gọi biết rằng chuông của
phía bị gọi đang rung. Nếu phía bị gọi chấp nhận cuộc gọi nó sẽ gửi trả lời bản tin Response 200 OK.
Alice
John Invite sip:j
[email protected] SDP offer 180 Ringing 200 OK SDP Answer
Hình 13. Trao đổi bản tin Invite Trong trường hợp một trong hai UA muốn thay đổi các thông số mô tả phiên khi mà cuộc gọi đang diễn ra thì một trong hai bên sẽ gửi lại bản tin INVITE (Re-INVITE) tới bên kia với các thông số media mới. Ví dụ trong hình trên Alice và John đang đàm thoại, và Alice muốn nhìn thấy John. Alice sẽ gửi lại bản tin INVITE tới John, trong bản tin INVITE này có thêm các thông số video mà phía Alice hỗ trợ.
Alice
John RTP Audio Channel Invite New SDP Offer 200 OK New SDP Offer ACK RTP A udio + Video Channel
Hình 14. Thay đổi các thông số của cuộc gọi (Re-Invite)
3.2.1.1.2. Bản tin Register
Bản tin Register được UA sử dụng để thực hiện thủ tục đăng ký với SIP server, trong bản tin Register này sẽ chứa các thông tin về UA như: địa chỉ hiện tại, số port mà UA đang lắng nghe…. Nếu nhận được bản tin Response 200 OK từ phía SIP server nghĩa là quá trình đăng ký đã thành công.
John
Registrar
Register sip: registrar .sea.com Contact :
200 OK Contact :
Hình 15. Quá trình đăng ký với Registrar server
3.2.1.1.3. Bản tin BYE Bản tin BYE được gửi từ phía UA để kết thúc một cuộc gọi. Khi một UA muốn kết thúc cuộc gọi, nó sẽ gửi bản tin BYE tới phía còn lại để thông báo rằng nó muốn kết thúc cuộc gọi. Một bản tin Respone 200 OK được gửi trả lại để thông báo rằng yêu cầu kết thúc được chấp nhận và cuộc gọi được kết thúc.
Alice
John RTP Data Channel
BYE
200 OK
Hình 16. Quá trình trao đổi bản tin BYE
3.2.1.1.4. Bản tin ACK Bản tin ACK được gửi từ phía UA để cho biết rằng nó đã nhận được bản tin response cuối cùng cho bản tin INVITE trước đó. Các bản tin Response cuối cùng là các bản tin thuộc lớp 2xx, 3xx, 4xx, 5xx, 6xx.
Alice
John Invite sip:[email protected] SDP offer 180 Ringing 200 OK SDP Answer AC K
Hình 17. Quá trình trao đổi bản tin ACK
3.2.1.1.5. Bản tin CANCEL
User agent1 muốn thực hiện cuộc gọi tới user agent2, ban đầu nó sẽ gửi bản tin INVITE tới user agent2. Nếu user agent1 không nhận được bản tin response cuối cùng từ phía user agent2 trong khoảng thời gian time out, nó sẽ gửi bản tin CANCEL tới user agent2 để hủy bỏ cuộc gọi. Bản tin BYE sẽ không được sử dụng trong trường hợp này vì cuộc gọi vẫn chưa được thiết lập. Một cuộc gọi được thiết lập khi các bản tin INVITE, 200 OK, ACK được trao đổi.
Alice
John Invite sip:j [email protected] SDP offer 180 Ringing CANCEL 200 OK (CANCEL)
Hình 18. Quá trìn trao đổi bản tin CANCEL
3.2.1.1.6. Bản tin OPTIONS Được sử dụng để truy vấn về khả năng của một UA. Khả năng ở đây có thể là khả năng mã hóa và giải mã âm thanh, hình ảnh, các message header được UA hỗ trợ.
3.2.1.1.7. Bản tin REFER Được gửi từ UA để yêu cầu một UA khác truy cập vào một địa chỉ URI hoặc URL trong trường header field Refer-To nằm trong bản tin REFER. Địa chỉ URI hoặc URL có thể là một địa chỉ SIP URI hoặc một địa chỉ của một trang web. Nếu là một địa chỉ SIP URI, UA dường như đang thực hiện một dịch vụ chuyển cuộc gọi (transfer call), hoặc là đang tạo ra một cuộc gọi với nhiều bên tham gia (conferencing). Khi nhận được bản tin REFER nếu UA đồng ý truy cập vào địa chỉ URI hoặc URL được cung cấp nó sẽ gửi trả lại bản tin response 202 Accepted. Ví dụ UA nhận được bản tin REFER với địa chỉ SIP
URI trong trường Refer-To, UA sau đó sẽ gửi một bản tin Invite tới địa chỉ SIP URI vừa được cung cấp trong trường Refer-To
UA1
UA2
UA3
REFER 202 Accepted NOTIFY
INVITE 180 Ringing
200 OK 200 OK NOTIFY ACK 200 OK
Hình 19. Quá trình trao đổi bản tin REFER
3.2.1.1.8. Bản tin SUBSCRIBE Được gửi từ một UA để yêu cầu nhận một cảnh báo về sự thay đổi của một sự kiện(event) nào đó, ví dụ như sự kiện chuyển cuộc gọi như hình trên, hoặc sự kiện thiết lập hội nghị (cuộc gọi có nhiều bên tham gia). Bản tin SUBSCRIBE được gửi tới server với trường Event chứa giá trị là tên của sự kiện mà client muốn được nhận thông báo, và trường Expires là khoảng thời gian timeout của bản tin SUBSCRIBE. Nếu server hỗ trợ sự kiện mà client mô tả trong trường Event, server gửi trả lời bằng bản tin response 200 OK, lúc này cứ mỗi lần có một sự thay đổi nào đó của sự kiện mà client mong muốn nhận, server sẽ gửi bản tin NOTIFY thông báo tới client, bản tin NOTIFY sẽ được gửi cho tới khi khoảng thời gian timeout của bản tin SUBSCRIBE hết hạn, lúc này nếu muốn tiếp tục nhận các thông báo từ server, client phải gửi lại bản tin SUBSCRIBE
Client
Server
SUBSCRIBE 200 OK
NOTIFY 200 OK NOTIFY 200 OK Timeout
SUBSCRIBE 200 OK
Hình 20. Quá trình trao đổi bản tin SUBSCRIBE
3.2.1.1.9. Bản tin NOTIFY Được sử dụng bởi UA để gửi một thông báo về sự thay đổi của một sự kiện tới UA phát ra bản tin SUBSCRIBE. Nội dung của phần thông báo chứa trong phần message body của bản tin NOTIFY và thường được định dạng theo kiểu XML.
3.2.1.1.10. Bản tin MESSAGE Được sử dụng để mang nội dung của các tin nhắn nhanh (Instant message) được gửi giữa các UA. Nội dung của IM được chứa trong phần message body của bản tin MESSAGE. Ví dụ một bản tin MESSAGE: MESSAGE sip:[email protected] SIP/2.0
Via SIP/2.0/UDP lab.mendeleev.org:5060;branch=z9hG4bK3 Max-Forwards: 70 To: From: “D. I. Mendeleev” ;tag=1865 Call-ID: 93847197172049343 CSeq: 5634 MESSAGE Subject: First Row Contact: Content-Type: text/plain Content-Length: 10 Hi, hehehe
3.2.1.2. Các bản tin trả lời (responses) Một bản tin response là một bản tin được gửi bởi UAS hoặc SIP server để trả lời cho một bản tin request trước đó. SIP định nghĩa 6 lớp của các bản tin responses, các lớp từ 1xx tới 5xx hầu như là tương tự với các bản tin response của giao thức HTTP, riêng lớp 6xx được định nghĩa riêng cho SIP.
3.2.1.2.1. Các lớp bản tin responses •
•
•
1xx responses: Các bản tin response ở lớp 1xx là các bản tin tạm thời hoặc là các bản tin thông báo các thông tin phản hồi. Khi một UA nhận được một bản tin request nó sẽ gửi ngay lập tức lại một bản tin ở lớp 1xx để thông báo rằng nó đã nhận được bản tin request và đang xử lý bản tin đó. 2xx responses: Các bản tin lớp 2xx là các bản tin response cuối cùng với mục đích là thông báo cho phía gửi request rằng bản tin request thành công, hoặc yêu cầu được chấp nhận. 3xx responses: Các bản tin lớp 3xx là các bản tin chuyển hướng, nó được gửi bởi SIP server có chức năng như là Redirect server. Ví dụ, nếu một Proxy server nhận được một bản tin Invite và nó không thể định vị được địa chỉ của phía nhận, khi đó
nó sẽ gửi trả lại phía gọi một bản tin lớp 3xx để thông báo cho phía gọi sử dụng một địa chỉ khác. •
•
•
4xx responses: Các bản tin lớp 4xx là các bản tin thông báo thất bại, có nghĩa rằng phía nhận không thể xử lý được bản tin request. 5xx responses: Các bản tin lớp 5xx là các bản tin thông báo rằng yêu cầu không thể được xử lý do lỗi phía server. 6xx responses: Các bản tin lớp 6xx là các bản tin thông báo lỗi toàn bộ hệ thống
3.2.1.2.2. Chi tiết các bản tin responses •
•
•
•
100 Trying: Bản tin này được sinh ra để thông báo rằng bản tin request trước đó đã được nhận và phía đang request ngừng gửi bản tin request. 180 Ringing: Thông báo cho phía gọi rằng phía bị gọi đã nhận được bản tin Invite và chuông của phía bị gọi đang rung 181 Call Is Being Forwarded: thông báo cho phía gọi rằng cuộc gọi đang được chuyển hướng tới một địa chỉ khác đã được thiết lập trước. 182 Call Queued: Thông báo cho phía gọi biết rằng cuộc gọi tạm thời được đưa vào hàng đợi để chờ xử lý do phía bị gọi tạm thời đang bận.
•
183 Session Progress: Được sử dụng để mang thông tin về trạng thái của cuộc gọi
•
200 OK: Thông báo request thành công.
•
202 Accepted: Thông báo yêu cầu được chấp nhận.
•
•
•
300 Multiple Choices: Bản tin response này sẽ trả lại một danh sách các contact, từ đó UA sẽ lựa chọn ra một contact để thực hiện request. 301 Moved Permanently: Bản tin response này sẽ trả lại cho UA địa chỉ của phía bị gọi được chứa trong trường contact header, địa chỉ này là địa chỉ cố định của phía bị gọi, do đó phía gọi có thể lưu địa chỉ này lại để sử dụng trong các cuộc gọi sau này. 302 Moved Temporality: Ngược với bản tin 301 địa chỉ của phía bị gọi chỉ là tạm thời, do đó phía gọi chỉ nên lưu địa chỉ này lại tạm thời đến khi nào hết thời gian time out được chứa trong trường Expires header field của bản tin response.
•
•
•
•
•
•
•
•
•
305 Use Proxy: Bản tin response này sẽ chứa một địa chỉ URI trỏ tới một proxy server để thông báo cho phía đang gọi biết rằng cần phải gửi bản tin request tới proxy server trước. 308 Alternative Service: Bản tin response này chứa một địa chỉ URI cho biết kiểu dịch vụ của phía bị gọi, ví dụ như là một địa chỉ của voicemail server. 400 Bad Request: Thông báo cho phía gọi biết rằng bản tin request được gửi là không đúng, hoặc là thiếu một số trường header mà cần thiết phải có như: To, From, Call-ID, Cseq. 401 Unauthorized: Bản tin này thông báo cho UA biết là cần phải thực hiện chứng thực. ví dụ, khi UA gửi một bản tin Register tới Registrar server, Registrar server sẽ gửi lại bản tin 401 yêu cầu cung cấp thông tin user name và password, UA sau đó sẽ gửi lại bản tin Register có chứa thông tin về user name và password. 404 Not Found: Bản tin này cho biết rằng địa chỉ sip uri của phía bị gọi mà phía gọi cung cấp không tồn tại, hoặc là do phía bị gọi đang offline. 407 Proxy Authentication Required: Bản tin response này được gửi bởi proxy server để thông báo cho phía UAC biết rằng nó cần phải thực hiện chứng thực với proxy trước khi bản tin request có thể được xử lý. 486 Busy Here: Bản tin response này được sử dụng để cho biết rằng phía bị gọi đang bận và không thể trả lời cuộc gọi được. 500 Server Internal Error: Bản tin này cho biết phía server đang có một số lỗi, và hiện tại không thể xử lý các bản tin request được. 501 Not Implement: Bản tin này cho biết rằng phía server không thể xử lý bản tin request, do bản tin request này không đúng, hoặc không được server hỗ trợ.
•
600 Busy Everywhre: Tương tự như bản tin 408 Busy Here
•
604 Does Not Exist Anywhare: Tương tự như 404 Not Found
3.3. Cấu trúc bản tin SIP SIP là một giao thức kiểu text-base, có nghĩa là các bản tin được sử dụng trong SIP được mã hóa theo kiểu các ký tự bình thường mà chúng ta có thể đọc được. Một bản tin SIP bao gồm nhiều dòng, kết thúc mỗi dòng là hai ký hiệu thông báo xuống dòng và bắt đầu một dòng mới CR LF (hai ký hiệu này là “\r\n”).
Hình 21. Cấu trúc bản tin SIP Có hai kiểu bản tin SIP là bản tin request và bản tin response, cả hai loại bản tin này đều bao gồm một dòng start line, một hoặc nhiều trường header, một dòng bỏ trống để cho biết kết thúc phần header, và một phần tùy trọn message body. Các trường header bao gồm hai thành phần là: tên header và giá trị của header. Bắt đầu bằng tên header, tiếp theo là dấu hai chấm (:), theo sau là giá trị của header kết thúc bằng hai ký hiệu \r\n (CRLF)
3.3.1.1. Bản tin Request Trong bản tin request dòng start line được gọi là request line và chứa các thông tin sau: Tên của bản tin(Invite, Register, BYE…), trường Request-URI và phiên bản của giao thức (hiện tại là SIP 2.0). Tất cả các thông tin này được cách nhau bởi một khoảng trắng(Single Space) MethodRequest-URIProtocol version Trường Request-URI là một địa chỉ SIP URI nó cho biết nơi mà bản tin sẽ được định tuyến tới. Ví dụ: Invite sip:[email protected] SIP 2.0
Hình 22. Ví dụ một bản tin request Invite
3.3.1.2. Bản tin Response Trong bản tin response dòng start line được gọi là status line và bao gồm các thông tin sau: phiên bản của giao thức, mã của bản tin response trả về và thông tin về lý do cho bản tin trả về này. Các thông tin này được cách nhau bới một ký tự trắng Ví dụ: SIP 2.0 180 Ringing
Hình 23. Ví dụ bản tin response 200 OK 3.4. SIP Header Fields Các trường header fields của bản tin SIP cũng tương tự như của giao thức HTTP, và tuân theo chuẩn của RFC 2822 (Internet Message Format). Có bốn loại header fields đó là: các trường header fields xuất hiện trong cả hai loại bản tin request và response (request and response header fields), các trường header fields chỉ xuất hiện trong các bản tin request (request header fields), các trường header fields chỉ xuất hiện trong các bản tin response (response header fields), Các trường header fields mô tả thông tin về phần message body (Message Body Header Fields).
3.4.1.1. Request and Response header fields 3.4.1.1.1. Alert-Info Được sử dụng để cung cấp một tài nguyên cho cả phía gọi và phía bị gọi để sử dụng cho việc thông báo cho người dùng biết, thông báo này có thể bằng hình ảnh hoặc âm thanh. Ví dụ nếu trong bản tin Invite có trường Alert-Info chứa địa chỉ URI của một bản nhạc chuông thì phía bị gọi có thể sử dụng địa chỉ URI này để thông báo cho phía người sử dụng biết rằng đang có một cuộc gọi tới bằng cách phát lại bản nhạc này.
3.4.1.1.2. Call-ID Trường Call-ID header field là bắt buộc phải có trong tất cả các bản tin SIP request và response, Call-ID được sử dụng để nhận ra một cuộc gọi giữa hai UA, giá trị của trường Call-ID là duy nhất và là ID của cuộc gọi, giá trị này được tạo bởi UA Ví dụ: Call-ID: 44fer23ei4291dekfer34231232
3.4.1.1.3. Contact Chứa một địa chỉ URI, địa chỉ này được sử dụng cho việc định tuyến các bản tin request trong tương lai, điều này có nghĩa rằng một bản tin request mới được tạo ra trong phạm vi một SIP dialog dialog sẽ được gửi thẳng trực tiếp tiếp tới địa chỉ URI của của UA trong trường contact mà không cần thông qua proxy. Một trường hợp đặc biệt đó là trong bản tin Register trường Contact với giá trị là ‘*’ xuất hiện cùng với trường Expires với giá trị bằng 0 được sử dụng để xóa toàn bộ lịch sử đăng ký trước đó của UA (tương tự như khi chúng ta logout khỏi yahoo messenger). Trường Contact còn có một vài tham số tùy chọn đi kèm như expires, giá trị của tham số expires cho biết khoảng thời gian mà địa chỉ URI còn có hiệu lực. Ví dụ: Contact: sip:[email protected]
3.4.1.1.4. Cseq Bắt buộc phải có trong tất cả các bản tin request, giá trị của Cseq là một số nguyên và được tăng lên khi mỗi lần một bản tin request được gửi đi. Một trường hợp ngoại lệ đó là trong các bản tin CANCEL, ACK giá trị của trường Cseq sẽ không được tăng lên mà giống với giá trị của bản tin INVITE trước đó. Giá trị của trường Cseq trong các bản tin response giống với giá trị trong các bản tin request trước đó.
Alice
Bob Invite: sip:[email protected] Cseq: 1 Invite 180 Ringing Cseq: 1 Invite 200 OK Cseq: 1 Invite ACK Cseq: 1 Invite Invite (re-Invite) Cseq: 2 Invite 200 OK Cseq: 2 Invite
Hình Hình 24. 24. Bản tin sử dụng dụng trườ trường ng CSeq CSeq
3.4.1.1.5. Date Mang thông tin về thời gian (ngày, tháng năm,…) khi các bản tin request hoặc response được gửi đi . Ví dụ: Date: Fri, 13 Oct 1998 23:29:00 GMT
3.4.1.1.6. From Bắt buộc phải có trong tất cả các bản tin SIP, From cho biết địa chỉ SIP URI của người khởi tạo bản tin request đầu tiên. From thường có một tham số đi kèm là tham số tag, giá trị của tag là một chuỗi ngẫu nhiên được sử dụng cùng với tham số tag của trường To để nhận ra một SIP Dialog. Giá trị của tag được tạo ra bởi phía gửi bản tin request. Ví dụ: From: ;tag=3342436 ;tag=3342436
3.4.1.1.7. Record-Route Được sử dụng cho UA biết rằng tất cả các bản tin đều phải được định tuyến thông qua proxy. Nếu trong một bản tin tin đều có cả Record-Route và Contact thì trường Contact sẽ không có ý nghĩa, tất cả các bản tin vẫn phải được định tuyến thông qua proxy. Proxy server tự động cập nhật địa chỉ của của nó vào trường Record-Route trong bản tin request sau đó mới forward chúng tới phía UA, Các bản tin request, response sau đó sẽ được gửi tới địa chỉ mà proxy server thêm vào. Ví dụ: Record-Route:sip:139.23.1.44 Record-Route:sip:139.23.1.44
3.4.1.1.8. To Bắt buộc cần phải có trong các bản tin SIP, trường To cho biết địa chỉ URI của phía nhận bản tin request. Tham số tag thường đi kèm với To, giá trị của tag cũng giống như giá trị của tham số tag của trường From, giá trị này được tạo ra bởi phía UA gửi bản tin response. Ví dụ: :To: ;tag=3342467
3.4.1.1.9. User-agent Được sử dụng để mang thông tin về nhà sản xuất hoặc phiên bản của phần mền. User-Agent: Acme SIP Phone v2.2
3.4.1.1.10. Via Cho biết giao thức được sử dụng để truyền tải các bản tin (UDP, TCP…) và địa chỉ cộng với port nơi mà bản tin response sẽ được gửi tới. Khi một bản tin request được gửi thông qua proxy, proxy sẽ thêm trường Via vào bản tin request sau đó mới forward chúng đi, cơ chế này để giúp cho việc phát hiện ra một bản tin request là lặp (loops). Có ba tham số đi kèm với trường Via đó là: received, branch, maddr. Nếu một UA hoặc proxy nhận được bản tin request từ một địa chỉ khác với địa chỉ trong trường Via, điều này có nghĩa rằng UA hoặc proxy đang sử dụng cơ chế NAT, khi đó tham số received sẽ được thêm vào Via và bản tin response sẽ được gửi tới địa chỉ received. Tham số branch được UA hoặc proxy thêm vào và có giá trị là duy nhất và được sử dụng để nhận ra một transaction. Tham số maddr được sử dụng cho việc truyền tải multicast. Ví dụ: Via: SIP/2.0/UDP 100.101.102.103;branch=z9hG4bK776a Via: SIP/2.0/TCP 192.168.1.2;received=12.4.5.50 ;branch=z9hG4bK334
3.4.1.2. Request header fields 3.4.1.2.1. Accept-Encoding Được sử dụng để cho biết UA hỗ trợ những cơ chế mã hóa phần message body nào, mặc định là text/plain. text/plain. Nếu UA nhận được được bản tin với phần message message body được mã hóa mà UA không hỗ trợ một bản tin response 406 Not Acceptable sẽ được gửi trả lại. Ví dụ: Accept-Encoding: text/plain
3.4.1.2.2. Authorization Được sử dụng để mang thông tin chứng thực của UA trong bản tin request tới phía server. Authorization được sử dụng trong bản tin request để trả lời cho bản tin response 401 Unauthorization. Ví dụ: Authorization: Digest username="102", realm="axon@duongdx", nonce="v58609qaq32385w", uri="sip:192.168.1.34", response="ef9062e830afff239a3c9c4d00393133", response="ef9062e830afff239a3c9c4d00393133", opaque=""", algorithm=MD5
3.4.1.2.3. Join Được sử dụng trong bản tin Invite để tham gia vào một cuộc gọi đã tồn tại trước đó, nếu cuộc gọi trước đó là một cuộc gọi điểm-điểm giữa hai UA thì trường Join header field trong bản tin Invite sẽ tạo ra một hội nghị với ba bên tham gia, còn nếu cuộc gọi
trước đó đã là một hội nghị thì UA với bản tin request có trường Join header field sẽ tham gia vào hội nghị đó. Để tham gia vào một cuộc gọi đã tồn tại trước đó thì giá trị của các tham số tag của To và From cùng với giá trị của Call-ID sẽ được Join sử dụng. Nếu cuộc gọi trước đó không tồn tại hoặc giá trị của Join gửi tới không đúng với giá trị của tham số tag của From, To và giá trị của Call-ID thì một bản tin response 481 Call/Dialog Does Not Exist sẽ được được gửi trả lại. To: ;tag=42312 ;tag=42312 From: ;tag=3443212 ;tag=3443212 Call-ID: 243134123234 Giá trị của trường Join trong bản tin Invite sẽ là: Join: 243134123234;to-tag=42312;from 243134123234;to-tag=42312;from-tag=3443212 -tag=3443212
Alice Ali ce
Bob
Carol
RTP Media Invite (Join) 180 Ringing Invite 200 OK ACK AC K Conference Media Session 200 OK AC K Conference Media Session
Hình 25. 25. mô hình hình cuộc gọi có có sử dụng dụng Join Join trong bản tin tin Invite Invite
3.4.1.2.4. Proxy-Authorization Được sử dụng để mang thông tin chứng thực của UA trong bản tin request tới phía server. Authorization được sử dụng trong bản tin request để trả lời cho bản tin response 407 Proxy Authentication Required. Ví dụ: Proxy-Authorization: Digest username="Customer1", realm="company.com", nonce="9c8e88df84f1cec4341ae6e5a359", opaque="", uri="sip:[email protected]", response="e56131d19580cd833064787ecc"
3.4.1.2.5. Max-Forwards Được sử dụng để cho biết số lần lớn nhất mà một bản tin request được proxy forward đi. Mỗi lần một bản tin request được proxy forward đi giá trị của trường Max-Forwards sẽ được giảm đi một. Nếu một proxy nhận được một bản tin request với giá trị của MaxForwards bằng 0 thì bản tin request đó sẽ bị hủy bỏ và proxy server gửi trả lại một bản tin response 483 Too Many Hops. Ví dụ: Max-Forwards: 70
3.4.1.2.6. Reason Được sử dụng trong các bản tin BYE hoặc CANCEL để cho biết nguyên nhân một cuộc gọi bị kết thúc.
3.4.1.3. Response header fields 3.4.1.3.1. Proxy-Authenticate Được sử dụng trong bản tin 407 Proxy Authentication Required để yêu cầu một UA cung cấp các thông tin chứng thực cho Proxy server. Ví dụ: Proxy-Authenticate: Digest realm="example.com", nonce="9c8e88df84f1cec4341ae6e5a359", opaque="", stale=FALSE, algorithm=MD5
3.4.1.3.2. WWW-Authenticate
Được sử dụng trong bản tin 401 Unauthorized để yêu cầu một UAC cung cấp các thông tin chứng thực cho Registrar server. Ví dụ: WWW-Authenticate: Digest realm="example.com", nonce="9c8e88df84f1cec4341ae6e5a359", opaque="", stale=FALSE, algorithm=MD5
3.4.1.3.3. Server Được sử dụng để mang thông tin về UAS, thông tin ở đây có thể là tên hoặc phiên bản của UAS.
3.4.1.1. Message Body header fields 3.4.1.1.1. Allow Được sử dụng để cho biết các phương thức sẽ được UA hoặc proxy server hỗ trợ Allow: INVITE, ACK, BYE, INFO, OPTIONS, CANCEL
3.4.1.1.2. Content-Encoding Được sử dụng để cho biết các phương thức được sử dụng để mã hóa phần message body. Điều này cho phép phía UAS sử dụng các phương pháp hợp lý để decoding phần message body được mã hóa Ví dụ: Content-Encoding: text/plain
3.4.1.1.3. Content-Length Được sử dụng để cho biết độ dài tính theo byte của phần message body. Một ContentLength: 0 cho biết rằng bản tin đó sẽ không có phần message body.
3.4.1.1.4. Content-Type Được sử dụng để cho biết kiểu Internet media type nào sẽ được sử dụng trong phần message body của bản tin. Trong các bản tin SIP kiểu Internet media type Application/SDP là mặc định.
3.4.1.1.5. Expires Được sử dụng để cho biết khoảng thời gian time out mà một bản tin request còn có hiệu lực. Ví dụ khi một UAC gửi một bản tin Invite tới UAS với trường Expires header
fields, Điều này có nghĩa rằng trong khoảng thời gian time out đó UAC cần phải nhận được bản tin response cuối cùng từ UAS. Nếu hết khoảng thời gian time out mà UAC vẫn chưa nhận được bản tin response cuối cùng nào từ UAS, UAC sẽ sinh ra một bản tin CANCEL để yêu cầu hủy bản tin Invite trước đó. 3.5. Session Description Protocol SIP sử dụng SDP để mô tả các thông số media cho một cuộc gọi, các thông số media này là các thông tin về băng thông, các chuẩn mã hóa audio, video và một số các thông tin khác.
3.5.1.1. Các trường của giao thức SDP Field Type
Bắt buộc/tùy chọn Mô tả
Ví dụ
V=
Bắt buộc
Phiên bản của giao thức
V=0
O=
Bắt buộc
Thông tin về người khởi tạo O=Sam 154954610 0 IN IP4 phiên và session id 10.10.10.26
S=
Bắt buộc
Tên của phiên
S=Conference call
C=
Tùy chọn
Thông tin kết nối
C=IN IP4 192.168.2.157
B=
Tùy chọn
Thông tin về băng thông, có B=CT:128 2 loại CT và AS. CT tổng băng thông của tất cả các bên tham gia vào cuộc gọi. AS băng thông của một phía
K=
Tùy chọn
Khóa mã hóa
M=
Bắt buộc
Tên của phần media (video, m=audio 49000 RTP/AVP 121 audio)
A=
Tùy chọn
Các thuộc tính
K=base64:7658339339
A=rtpmap:121 G7221/16000
Bảng 1: Các trường của giao thức SDP Một số thuộc tính của giao thức SDP •
•
A=rtpmap: mô tả các thông tin về chuẩn codecs . A=fmtp: thường được sử dụng để mô tả các thông tin về độ phân giải của video codecs.
•
A=sendonly: cho biết chế độ chỉ gửi không nhận các gói tin media.
•
A=recvonly: chỉ nhận không gửi các gói tin media.
•
A=sendrecv: vừa nhận vừa gửi các gói tin media.
3.5.1.2. Sử dụng SDP trong SIP Kiểu message body mặc định trong các bản tin SIP là application/sdp. Phía gọi liệt kê một danh sách về khả năng media mà nó hỗ trợ trong phần message body của bản tin Invite hoặc bản tin ACK. Phía bị gọi liệt kê khả năng media mà nó hỗ trợ trong bản tin trả lời 200 OK cho bản tin Invite. Trong một bản tin SIP phần message body nên có các trường của giao thức SDP sau: version(V), origin(O), subject(S), time(T), connection(C), và một hoặc vài trường mô tả về các chuẩn audio codecs, video codecs. Các trường O, S, T không được sử dụng trong giao thức SIP, nhưng đây là các trường bắt buộc của giao thức SDP nên chúng cần được thêm vào nhằm mục đích cho tính tương thích. SIP sử dụng các trường C, M, A của giao thức SDP để thiết lập một phiên đa phương tiện giữa các user agents. Ví dụ: phía gọi Tesla muốn thiết lập một cuộc gọi với hai chuẩn audio codecs được mô tả bằng SDP và được gửi đi trong bản tin Invite: v=0 o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org s=c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
Phía bị gọi Marconi trả lời cuộc gọi và chọn chuẩn audio codec thứ hai trong bản tin Invite của Tesla. v=0 o=Marconi 2890844526 2890844526 IN IP4 tower.radio.org s=c=IN IP4 200.201.202.203 t=0 0 m=audio 60000 RTP/AVP 8 a=rtpmap:8 PCMA/8000 Chuẩn audio codecs PCMA sau đó sẽ được sử dụng trong quá trình cuộc gọi giữa Tesla và Marconi. 3.6. Sử dụng NAT trong SIP
3.6.1.1. NAT (Network Address Translation) NAT Là kỹ thuật mà địa chỉ nguồn hay địa chỉ đích thay đổi khi đi qua thiết bị có chức năng NAT, cho phép nhiều host trong mạng nội bộ dùng chung một địa chỉ IP để đi ra mạng bên ngoài.
Hình 26. Quá trình thay đổi địa chỉ trong NAT Có 4 kiểu NAT
Full : tất cả các yêu cầu từ cùng các host bên trong (địa chỉ IP và port) được
ánh xạ tới cùng một IP hay port đại diện bên ngoài, vì vậy bất kỳ một host bên ngoài có thể gửi gói tới 1 host bên trong nếu biết địa chỉ được ánh xạ đó. Restricted : chỉ cho phép 1 host bên ngoài với IP X gửi gói cho host mạng bên trong nếu host của mạng bên trong đã gửi tới IP X một gói trước đó. Port restricted : Giống Restricted one nhưng có thêm port. Chính sách này được sử dụng để có thể dùng chung một địa chỉ IP đại diện bên ngoài. Symmetric : tất cả các request từ cùng 1 IP hay port đến 1 đích nào đó được ánh xạ đi bằng 1 IP đại diện, nếu đi tới 1 đích khác thì nó sẽ đi bằng IP đại diện khác Chỉ có những host bên ngoài nhận được gói thì mới gửi gói ngược trở lại các host bên trong được.
3.6.1.2. Sử dụng NAT trong SIP Sử dụng NAT trong SIP có thể được chia ra làm 2 vấn đề chính như sau: •
Sử dụng NAT trong quá trình trao đổi các bản tin báo hiệu
•
Sử dụng NAT trong quá trình trao đổi tín hiệu media (audio, video)
Cả hai vấn đề trên có thể được giải quyết một cách dễ dàng nếu sử dụng thêm một giao thức hỗ trợ NAT kèm theo, hiện nay có một số giao thức hỗ trợ NAT như: •
•
STUN (Simple Traversal Of UDP Through NAT): Một STUN client gửi bản tin STUN tới STUN server, STUN server sau đó sẽ gửi trả lại một bản tin cho biết địa chỉ IP và Port mà thiết bị NAT sử dụng. Địa chỉ IP và Port này sau đó sẽ được UAC sử dụng cho việc thiết lập cuộc gọi, một hạn chế của STUN là không hỗ trợ Symmetric NAT TURN (Traversal Using NAT Relay): Cũng giống như STUN tuy nhiên TURN hỗi trợ cả giao thức TCP làm giao thức truyền tải. TURN bổ xung cho hạn chế của STUN là hỗ trợ Symmetric NAT.
Ngoài việc sử dụng một số giao thức hỗ trợ NAT kèm theo, chính bản thân SIP cũng có khả năng hỗ trợ NAT. Vấn đề sử dụng NAT trong quá trình trao đổi các bản tin báo hiệu có thể được giải quyết bằng cách sử dụng giao thức TCP làm giao thức truyền tải. Tuy nhiên hầu hết các ứng dụng VOIP client hiện nay đều không hỗ trợ giao thức này. Vậy nếu sử dụng UDP làm giao thức truyền tải thì sao? Chúng ta có thể mô tả một cách
đơn giản như sau: Một UAC đằng sau NAT gửi bản tin request tớ server ở phía bên ngoài, giao thức truyền tải được sử dụng là giao thức UDP. Bản tin response sau đó sẽ được gửi trả lại thông qua số hiệu cổng và địa chỉ có được trong trường Via của bản tin request. Tuy nhiên vì sử dụng NAT nên số hiệu cổng trong trường Via sẽ là không đúng, do đó bản tin response sẽ không được gửi tới đúng đích. Một giải pháp được đưa ra để giải quyết vấn đề trên đó là định nghĩa thêm một tham số mới cho trường Via, tham số có tên là “rport” (response port). Khi một UAC gửi bản tin request nó sẽ thêm tham số rport vào trường Via để làm cờ báo hiệu có sử dụng NAT. Khi proxy server nhận đượcbản tin request nó nhận thấy rằng số hiệu cổng và địa chỉ nguồn của gói tin chứa bản tin request khác với số hiệu cổng và địa chỉ trong trường Via của bản tin request, proxy sẽ ngầm hiểu rằng UAC đang ở đằng sau một thiết bị NAT. Proxy sẽ thêm giá trị của số hiệu cổng cho tham số rport, và thêm tham số recievied với giá trị là địa chỉ IP nguồn của gói tin chứa bản tin request mà nó nhận được. Bản tin response sau đó sẽ được gửi tới địa chỉ và số hiệu cổng của hai tham số received và rport. Ví dụ: Một UAC gửi 1 bản tin request với trường Via như sau: INVITE sip:user@domain SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport
Bản tin Invite trên được gửi với địa chỉ nguồn là 10.1.1.1 và port nguồn là 4540. Proxy nhận được bản tin Invite và nhận thấy rằng địa chỉ IP và số hiệu cổng của gói tin chứa bản tin Invite là 68.44.20.1 và 9988 khác với địa chỉ IP và số hiệu cổng trong trường Via của bản tin Invite là 10.1.1.1 và 4540. Bản tin Invite sau đó sẽ được proxy sửa lại như sau: INVITE sip:user@domain SIP/2.0 Via: SIP/2.0/UDP proxy.domain.com Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
Bản tin response sau được gửi trở lại cho bản tin Invite có dạng như sau: SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.domain.com Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988
Proxy sau đó sẽ gửi bản tin response này tới địa chỉ 68.44.20.1 và số hiệu cổng là 9988. Thiết bị NAT sẽ sửa lại địa chỉ đích và số hiệu cổng đích của gói tin thành 10.1.1.1 và 4540.
Chương 4. Các mô hình cuộc gọi trong SIP Thành phần
Tên hiển thị
URI
Địa chỉ IP
User Agent
Bob
[email protected]
192.0.2.201
User Agent
Alice
[email protected]
192.0.2.101
User Agent
Boo
boo@ atlanta.example.com
192.0.2.100
Proxy Server
ss1.atlanta.example.com
192.0.2.111
Proxy/Registrar
ss2.biloxi.example.com
192.0.2.222
Proxy Server
ss3.chicago.example.com
192.0.2.233
Bảng 2: Các thông tin về user agent, proxy server
4.1. Đăng ký với SIP server
4.1.1.1. Đăng ký thành công
Hình 27. Quá trình đăng ký với Registrar server Bob gửi bản tin Register request tới Registrar server, bản tin request bao gồm các thông tin như tên, địa chỉ của Bob. Registrar sau đó gửi lại bản tin response 401 Unauthorized yêu cầu Bob cung cấp thông tin chứng thực bao gồm user name và password. Bob gửi lại bản tin Register cộng với các thông tin user name và password (đã được mã hóa) tới Registrar, Registrar sẽ kiểm tra username và password mà Bob cung cấp có hợp lệ không. Đăng ký thành công khi Bob nhận được bản tin response 200 OK. Các bản tin sau đây sẽ được trao đổi giữa Bob và Registrar: - Register Bob -> Registrar REGISTER sip:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.biloxi.example.com:5061;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob ;tag=a73kszlfl To: Bob Call-ID: [email protected] CSeq: 1 REGISTER
Contact: sip:[email protected] Content-Length: 0
- 401 Unauthorized Registrar -> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP client.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=a73kszlfl To: Bob ;tag=1410948204 Call-ID: [email protected] CSeq: 1 REGISTER WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0
- Register Bob -> Registrar REGISTER sip:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.biloxi.example.com:5061;branch=z9hG4bKnashd92 Max-Forwards: 70 From: Bob ;tag=ja743ks76zlflH To: Bob Call-ID: [email protected] CSeq: 2 REGISTER Contact: Authorization: Digest username="bob", realm="atlanta.example.com" nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sip:ss2.biloxi.example.com", response="dfe56131d1958046689d83306477ecc" Content-Length: 0
- 200 OK Registrar -> Bob
SIP/2.0 200 OK Via: SIP/2.0/TCP client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201 From: Bob ;tag=ja743ks76zlflH To: Bob ;tag=37GkEhwl6 Call-ID: [email protected] CSeq: 2 REGISTER Contact: ;expires=3600 Content-Length: 0
4.1.1.2. Đăng ký thất bại Bob gửi bản tin Register request tới Registrar server, bản tin request bao gồm các thông tin như tên, địa chỉ của Bob. Registrar sau đó gửi lại bản tin response 401 Unauthorized yêu cầu Bob cung cấp thông tin chứng thực bao gồm user name và password. Bob gửi lại bản tin Register cộng với các thông tin user name và password (đã được mã hóa) tới Registrar. Registrar kiểm tra user name và password mà Bob cung cấp và thấy chúng không hợp lệ. Registrar gửi lại bản tin response 401 Unauthorized.
4.1.1.3. Hủy đăng ký Bob gửi bản tin Register tới Registrar với trường Contact có giá trị là ‘*’ và trường Expires có giá trị 0 để cho biết rằng Bob muốn hủy đăng ký trước đó với Registrar. Registrar sau đó gửi trả lại bản tin 200 OK thông báo việc hủy đăng ký thành công Các bản tin sau sẽ được sử dụng: - Register Bob -> Registrar REGISTER sip:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.biloxi.example.com:5061;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob ;tag=a73kszlfl To: Bob Call-ID: [email protected] CSeq: 1 REGISTER
Expires: 0 Contact: * Authorization: Digest username="bob", realm="atlanta.example.com", nonce="88df84f1cac4341aea9c8ee6cbe5a359", opaque="", uri="sip:ss2.biloxi.example.com", response="ff0437c51696f9a76244f0cf1dbabbea" Content-Length: 0
- 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/TCP client.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=a73kszlfl To: Bob ;tag=1418nmdsrf Call-ID: [email protected] CSeq: 1 REGISTER
Content-Length: 0
4.2. Thiết lập cuộc gọi trực tiếp giữa hai UA
Alice
Bob Invite 180 Ringing
200 OK
AC K
RTP Media BY E 200 OK
Hình 28. Cuộc gọi trực tiếp giữa hai UA Alice gửi bản tin Invite để thiết lập một cuộc gọi với Bob, Bob chấp nhận và gửi bản tin 200 OK tới Alice, Alice gửi bản tin ACK để xác nhận là đã nhận được bản tin response 200 OK từ Bob. Quá trình thiết lập hoàn tất, kênh RTP được mở giữa Alice và Bob. Bob chủ động kết thúc cuộc gọi bằng cách gửi bản tin BYE tới Alice, Alice chấp nhận và gửi trả lại bản tin response 200 OK. Các bản tin sau đây sẽ được trao đổi giữa Alice và Bob - Invite Alice -> Bob INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob sip:[email protected] Call-ID: [email protected] CSeq: 1 INVITE
Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
- 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: [email protected] CSeq: 1 INVITE Contact: Content-Length: 0
- 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: [email protected] CSeq: 1 INVITE Contact:
Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
- ACK Alice -> Bob ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0
- BYE Bob -> Alice BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0
- 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0
4.3. Thiết lập cuộc gọi thông qua proxy
Alice
Proxy server
Boo
Invite 407 ACK Invite 100 Trying Invite 180 Ringing
180 Ringing
200 OK 200 OK ACK
ACK
RTP Media BYE BYE 200 OK
200 OK
Hình 29. Cuộc gọi thông qua Proxy server
Alice muốn thực hiện một cuộc gọi với Boo, Alice gửi bản tin Invite có chứa trường Route với địa chỉ URI của proxy server. Trong bản tin Invite chưa có các thông tin chứng thực của Alice, Proxy gửi lại bản tin response 407 yêu cầu Alice cung cấp các thông tin chứng thực. Alice gửi lại bản tin Invite với các thông tin chứng thực mà proxy yêu cầu. Proxy server nhận bản tin Invite và chèn thêm trường Record-Route với giá trị chính là địa chỉ của nó để chắc chắn rằng các bản tin được trao đổi sau đó sẽ được gửi tới proxy. Cuộc gọi kết thúc khi Boo gửi bản tin BYE yêu cầu kết thúc cuộc gọi. Các bản tin sau sẽ được sử dụng: - Invite Alice -> Proxy server INVITE sip: boo@ atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Boo Call-ID: [email protected] CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
- 407 Proxy Authorization Required Proxy -> Alice SIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Boo ;tag=3flal12sf Call-ID: [email protected] CSeq: 1 INVITE Proxy-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0
- ACK Alice -> Proxy ACK sip: boo@ atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Boo ;tag=3flal12sf Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0
- Invite Alice -> Proxy INVITE sip: boo@ atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Boo Call-ID: [email protected] CSeq: 2 INVITE
Contact: Proxy-Authorization: Digest username="alice", realm="atlanta.example.com", nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="", uri="sip boo@ atlanta.example.com ", response="42ce3cef44b22f50c6a6071bc8" Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
- 100 Trying Proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Boo Call-ID: [email protected] CSeq: 2 INVITE Content-Length: 0
- Invite Proxy -> Boo INVITE sip: boo@ atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch= z9hG4bK2d4790.1 ;received=192.0.2.101 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 69 Record-Route: From: Alice ;tag=9fxced76sl To: Boo Call-ID: [email protected] CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
-
180 Ringing Boo -> Proxy
SIP/2.0 180 Ringing Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch= z9hG4bK2d4790.1 ;received=192.0.2.101 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Record-Route: From: Alice ;tag=9fxced76sl To: Boo ;tag=314159 Call-ID: [email protected] Contact: CSeq: 2 INVITE Content-Length: 0
- 180 Ringing Proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Record-Route: From: Alice ;tag=9fxced76sl To: Boo ;tag=314159 Call-ID: [email protected] Contact: CSeq: 2 INVITE Content-Length: 0
-
200 OK Boo -> Proxy
SIP/2.0 200 OK Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch= z9hG4bK2d4790.1 ;received=192.0.2.101 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Record-Route: From: Alice ;tag=9fxced76sl To: Boo ;tag=314159 Call-ID: [email protected] CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
-
200 OK Proxy -> Alice
SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Record-Route: From: Alice ;tag=9fxced76sl To: Boo ;tag=314159 Call-ID: [email protected] CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
- ACK Alice -> Proxy ACK sip:boo@client. atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Boo ;tag=314159 Call-ID: [email protected] CSeq: 2 ACK Content-Length: 0
- ACK Proxy -> Boo ACK sip:boo@client. atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch= z9hG4bK2d4790.1 ;received=192.0.2.101 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76 Max-Forwards: 69 From: Alice ;tag=9fxced76sl To: Boo ;tag=314159 Call-ID: [email protected] CSeq: 2 ACK Content-Length: 0
- BYE Bob -> Proxy BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 Route: From: Boo ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0
- BYE Proxy -> Alice BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.100 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 69 From: Boo ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: [email protected]
CSeq: 1 BYE Content-Length: 0
- 200 OK Alice -> Proxy SIP/2.0 200 OK Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.100 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 From: Boo ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0
- 200 OK Proxy -> Boo SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 From: Boo ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0
4.4. Thực hiện cuộc gọi liên mạng SIP – PSTN
4.4.1.1. Giới thiệu hệ thống báo hiệu SS7 Hệ thống báo hiệu SS7 của ITU-T là một hệ thống báo hiệu kênh chung được tiêu chuẩn hoá. SS7 được thiết kế cho mạng thông tin điện thoại và nhiều loại mạng viễn thông khác được phát triển trong tương lai. SS7 cung cấp một phương tiện tin cậy để chuyển thông tin đúng trình tự không thất lạc hoặc trùng lặp. Một kênh báo hiệu chung có thể phục vụ 5000 cuộc thoại.
4.4.1.2. Cấu trúc của hệ thống SS7 Hệ thống SS7 được cấu trúc theo mođun và giống với mô hình OSI nhưng chỉ có 4 lớp. Ba lớp thấp 1, 2 và 3 tạo thành phần chuyển giao tin báo MTP. Lớp thứ 4 chứa các phần UP(user part) cho user. Có thể kể ra một số phần UP khác nhau cho các user là: TUP - phần của user dùng điện thoại DUP - phần của user dùng số liệu ISUP - phần của user mạng ISDN MTUP - phần của user điện thoại di động
Hình 30. Cấu trúc của hệ thống SS7 Để thực hiện một cuộc gọi liên mạng từ mạng VOIP sang mạng PSTN cần phải có một Gateway liên mạng làm nhiệm vụ chuyển các bản tin SIP của VOIP sang các bản tin thuộc lớp ISUP của mạng PSTN, đồng thời cũng cần phải có một Gateway media làm nhiệm vụ chuyển các dữ liệu media từ mạng VOIP sang dữ liệu media phù hợp với mạng PSTN.
Các bản tin lớp ISUP: Bản tin IAM
Tên đầy đủ Initial Address
ACM ANM REL
Address Complete Answer Release
RLC COT CPG SUS
Release Complete Continuity Test Call Process Suspend
RES
Resume
FOT INR
Forward Transfer Information Request
INF
Ý nghĩa Sử dụng để thiết lập cuộc gọi. Bản tin này thường chứa số thuê bao bị gọi Thông báo rằng cuộc gọi đang được thiết lập. Phía bị gọi đã có tín hiệu trả lời Cuộc gọi bị hủy. Cũng có thể sử dụng kiểu bản tin này để thông báo rằng tổng đài tandem hoặc tổng đài đích không thể thiết lập được kết nối. Đã nhận được bản tin REL và kênh thoại được hủy Dùng để kiểm tra tính liên tục của đường trunk Đang rung chuông thuê bao bị gọi Dừng một cuộc gọi nhưng kết nối của nó vẫn được giữ Phục hồi trạng thái cuộc gọi được dừng trước đó.SUS và RES dùng cùng một cấu trúc bản tin và tham số.
Yêu cầu thông tin từ phía tổng đài đích tới tổng đài nguồn để lấy thêm thông tin. Information Cung cấp thông tin yêu cầu bởi INR Bảng 3: Các bản tin lớp ISUP
4.4.1.3. Mô hình cuộc gọi liên mạng SIP - PSTN 4.4.1.3.1. Cuộc gọi bắt đầu từ VOIP(SIP) và kết thúc ở PSTN
SIP UA
GateWay
PSTN Switch
Telephone
INVITE IAM 100 Trying ACM 183 Session Progress One Way Media
One Way Speech
ANM 200 OK ACK
RTP Media Session
Two Way Speech
BYE REL 200 OK RLC
Hình 31. Mô hình cuộc gọi SIP – PSTN •
•
•
SIP User Agent gửi bản tin INVITE tới Gateway yêu cầu kết nối với một thuê bao PSTN. Gateway trả lời bằng bản tin 100 Trying ngay sau khi khởi tạo bản tin SS7 IAM tới mạng PSTN để lập tuyến tới thuê bao bị gọi. Chú ý là việc gửi bản tin 100 Trying cũng có thể thực hiện trước khi gửi bản tin IAM, điều này phụ thuộc vào việc cấu hình trên Gateway. Mạng PSTN trả về bản tin ACM sau khi đã xác định được địa chỉ thuê bao bị gọi. Bản tin SS7 này được chuyển thành bản tin SIP 183 Session Progress
•
•
•
•
Để báo rằng thuê bao bị được đang được rung chuông thì ở đây, mạng SIP trọn một cách an toàn là truyền nguyên trạng thái tín hiệu nhận được trên Gateway đến thuê bao SIP. Việc này cho phép báo hiệu chính xác trạng thái đang diễn ra đề phòng có trục trặc trong lúc thực hiện kết nối với PSTN. Thông tin này được truyền bằng một luồng RTP một chiều – biểu diễn như hình vẽ. Khi thuê bao bị gọi nhấc máy, bản tin SS7 ANM được gửi đi. Bản này được chuyển thành bản tin 200OK báo hiệu cổng trên Gateway sẵn sàng cho cuộc gọi. Sau khi thuê bao SIP trả lời bằng bản tin ACK thì luồng RTP được thiết lập 2 chiều giữa Gateway và SIP User Agent truyền tải tín hiệu thoại trên Gateway nhận được từ tổng đài của mạng PSTN Giả sử thuê bao SIP dập máy trước, nó sẽ gửi bản tin BYE tới Gateway để giải phóng cuộc gọi. Gateway gửi bản tin REL tới tổng đài PSTN để hủy kết nối. Sau khi Gateway gửi bản tin 200 OK và nhận được bản tin RLC, cuộc gọi chính thức chấm dứt.
4.4.1.3.2. Cuộc gọi bắt đầu ở PSTN và kết thúc ở mạng VOIP Trong mô hình cuộc gọi này rất giống với trường hợp cuộc gọi xuất phát từ mạng VoIP và kết thúc ở PSTN.
PSTN Switch
GateWay
SIP UA
IAM INVITE 100 Trying 180 Ringing
ACM One way speech
200 OK ANM ACK RTP Media REL BYE RLC 200 OK
Hình 32. Mô hình cuộc gọi PSTN - SIP Thông tin báo hiệu vẫn được chuyển đổi tương đương giữa bản tin SS7 và SIP. Để thông báo trạng thái rung chuông của mình, thuê bao SIP gửi trả bản tin 180 Ringing tới Gateway. Bản tin này tương ứng với bản tin SS7 ACM. Khi đó, Gateway sẽ gửi tín hiệu thoại một chiều mô tả trạng thái của thuê bao bị gọi tới thuê bao gọi.
PHẦN II: GIỚI THIỆU ỨNG DỤNG Chương 5. Giới thiệu ứng dụng 5.1. Giới thiệu thư viện mã nguồn mở OpenSipStack
5.1.1.1. Giới thiệu OpenSipStack là thư viện mã nguồn mở được Joegen Baclor phát triển từ năm 2005 và đã phát triển qua một vài phiên bản, phiên bản mới nhất hiện nay là 1.8 được phát hành ngày 30/12/2007. OpenSipStack có thể biên dịch được trên các nền tảng khác nhau như: Linux, Solaris, Windows.
5.1.1.2. Các chức năng được hỗ trợ bởi OpenSipStack •
•
OpenSipStack cung cấp các lớp, các hàm API cho phép chúng ta xây dựng các SIP clients và SIP servers hoạt động như mô tả trong phiên bản RFC 3261 của tổ chức IETF. OpenSipStack hỗ trợ các chuẩn audio codecs như: G.711, GSM, iLBC G.729, G.723.1
5.1.1.3. Ưu nhược điểm khi sử dụng OpenSipStack 5.1.1.3.1. Ưu điểm: •
• •
Là thư viện mã nguồn mở, nên chúng ta có thể dễ dàng tùy biến trong khi phát triển ứng dụng Biên dịch được trên nhiều nền tảng khác nhau như: Linux, Solaris, Windows. Hỗ trợ hầu hết các chuẩn audio codecs hiện nay
5.1.1.3.2. Nhược điểm: Chưa hỗ trợ video Chưa có tài liệu hướng dẫn phát triển đi kèm, muốn sử dụng các thư viện cần phải đọc code để hiểu. 5.2. Giới thiệu chương trình SIMO • •
5.2.1.1. Giới thiệu Đây là một ứng dụng SIP client đơn giản do em tự xây dựng, có sử dụng thư viện mã nguồn mở OpenSipStack. Chương trình được phát triển bằng ngông ngữ visual C++.
Hình 33. Giao diện chính của chương trình SIMO
5.2.1.2. Các chức năng được hỗ trợ bởi SIMO Hiện tại SIMO hỗ trợ các chức năng nghe gọi cơ bản như: • • • •
Đăng ký với Registrar server Gọi điểm – điểm trực tiếp giữa hai user agent Gọi điểm – điểm thông qua Proxy server Hỗ trợ các chuẩn audio codecs như: G.711, G.723.1, G.729, GSM
5.2.1.3. Các chức năng sẽ được hỗ trợ trong tương lai Trong tương lai em sẽ cố gắng thay đổi một số chức năng của SIMO, đồng thời thêm một số tính năng mới như: •
Thay đổi giao diện của chương trình
• •
Thêm chức năng conferencing Thêm chức năng gọi có kèm theo video
Giao Thức Khởi Tạo Phiên SIP – Đào Xuân Dương
KẾT LUẬN Qua việc nghiên cứu về mạng VoIP và giao thức SIP, em nhận thấy được cơ hội và hướng phát triển của nó trong tương lai. Việc phát triển dựa trên công nghệ VoIP không chỉ mang một tính chất kinh tế, xã hội to lớn mà còn là một cơ hội rất lớn để Việt Nam có thể có một sản phầm mang tính chiến lược và hoàn toàn khả thi nếu được đầu tư đúng hướng. Giao thức SIP được đề cập tới trong bài khóa luận tốt nghiệp được trình bày hết sức cơ bản nhưng khá đầy đủ và toàn diện. Sau khi hoàn thành nội dung bài luận này, em đã học hỏi được rất nhiều và đã chắp nối khá tốt các kiến thức được học trên lớp về mạng, về các giao thức cơ bản. Nó giúp em phát triển phương pháp luận, cách đặt vấn đề và giải quyết vấn đề. Khóa luận đã tập trung nghiên cứu vấn đề trên và đã đạt được những kết quả sau: •
Tìm hiểu cơ bản về công nghệ VOIP
•
Tìm hiểu, nắm bắt tổng quan về các giao thức truyền tải trong VOIP
•
Tìm hiểu cơ bản về giao thức SIP và ứng dụng của nó trong VOIP
•
Tìm hiểu thư viện mã nguồn mở OpenSipStack
•
Xây dựng được một ứng dụng SIP client đơn giản
Do hạn chế về thời gian, khuôn khổ của bài luận cũng như kinh nghiệm thực tiễn của em chưa nhiều nên không tránh khỏi những sai sót và những nhầm lẫn. Nên sự đóng góp của thầy cô cùng các bạn không chỉ giúp bài luận của em có chất lượng cao hơn mà còn trang bị cho em một kiến thức vững vàng hơn trong nghiên cứu và công tác sau này. Với những kết quả đã đạt được thì đề tài có thể mở rộng theo hướng sau: Tiến hành nghiên cứu thật sâu rộng hơn về giao thức SIP như: Các mô hình cuộc gọi có nhiều bên tham gia(Conferencing), các vấn đề bảo mật cho hệ thống VOIP, kết nối liên mạng với các giao thức VOIP khác như: H.323. Em xin chân thành cảm ơn!
-1-
Khóa Luận Tốt Nghiệp
