Đồ án Một số giải pháp nâng cao chất lượng dịch vụ trong VoIP

eper giữa hai thiết bị đầu cuối (hình 2.4). Hình 2. 4 Bản tin báo hiệu của cuộc gọi được định tuyến qua Gatekeeper Thứ hai là các bản tin báo hiệu của cuộc gọi được truyền trực tiếp giữa hai thiết bị đầu cuối (hình 2.5). Cả hai phương thức này đều sử dụng các kết nối giống nhau với cùng mục đích, dạng bản tin được sử dụng cũng giống nhau, các bản tin thiết lập báo hiệu được trao đổi trên kênh RAS của Gatekeeper, sau đó tới trao đổi bản tin báo hiệu cuộc gọi trên kênh báo hiệu cuộc gọi. Sau đó mới tới thiết lập kênh điều khiển H.245. Hình 2. 5 Bản tin báo hiệu được truyền trực tiếp giữa các thiết bị đầu cuối Trong phương thức Gatekeeper định tuyến các bản tin thì nó có thể đóng kênh báo hiệu cuộc gọi khi việc thiết lập cuộc gọi hoàn thành hoặc vẫn duy trì kênh này để hỗ trợ các dịch vụ bổ xung. Chỉ có Gatekeeper mới có thể đóng kênh báo hiệu cuộc gọi, nhưng khi Gateway tham gia vào cuộc gọi thì các kênh này không được phép đóng. 2.2.3.3 Kênh điều khiển Khi các bản tin báo hiệu cuộc gọi được Gatekeeper định tuyến thì sau đó kênh điều khiển H.245 sẽ được định tuyến theo 2 cách thể hiện trên hình 2.6 và 2.7.Kênh điều khiển H.245 được thiết lập một cách trực tiếp giữa các thiết bị đầu cuối, (hình 2.6). Khi đó chỉ cho phép kết nối trực tiếp 2 thiết bị đầu cuối. Hình 2. 6 Kênh điều khiển H.245 kết nối trực tiếp hai thiết bị đầu cuối Kênh điều khiển H.245 được thiết lập từ thiết bị đầu cuối này tới thiết bị đầu cuối kia thông qua Gatekeeper (hình 2.7). Khi đó cho phép Gatekeeper định tuyến lại kênh điều khiển H.245 tới một MC khi thực hiện dịch vụ hội nghị. Hình 2. 7 Gatekeeper định tuyến kênh điều khiển H.245 2.2.4 Các thủ tục báo hiệu Người ta chia một cuộc gọi làm 5 giai đoạn gồm: - Giai đoạn 1: thiết lập cuộc gọi. - Giai đoạn 2: thiết lập kênh điều khiển . - Giai đoạn 3: thiết lập kênh thoại ảo. - Giai đoạn 4: dịch vụ. - Giai đoạn 5: kết thúc cuộc gọi. 2.2.4.1 Bước 1 - Thiết lập cuộc gọi Việc thiết lập cuộc gọi sử dụng các bản tin được định nghĩa trong khuyến nghị H.225.0. Có thể xẩy ra 6 trường hợp, đó là : - Cuộc gọi cơ bản - Cả hai thiết bị đầu cuối đều không đăng ký. - Cả hai thuê bao đều đăng ký tới một Gatekeeper. - Chỉ có thuê bao chủ gọi có đăng ký với Gatekeeper. - Chỉ có thuê bao bị gọi có đăng ký với Gatekeeper. - Hai thuê bao đăng ký với hai Gatekeeper khác nhau. - Thiết lập cuộc gọi qua Gateway. Trong hầu hết giao thức/báo hiệu phục vụ các ứng dụng thời gian thực, yêu cầu về ngưỡng thời gian xử lý cho phép (Tout - Time Out) của từng tín hiệu và của cả quá trình báo hiệu là bắt buộc. ở phương thức báo hiệu trực tiếp, quá trình báo hiệu diễn ra nhanh hơn dẫn đến xác xuất thời gian xử lý báo hiệu vượt quá Tout ít, làm cho tỷ lệ lỗi cuộc gọi giảm, hơn nữa việc báo hiệu trực tiếp giúp cho quá trình đồng bộ mạng chính xác. Tuy nhiên, ở phương thức này, yêu cầu các đầu cuối tham gia vào cuộc gọi phải có sự tính tương thích về báo hiệu. ở phương thức báo hiệu gián tiếp thông qua Gatekeeper, quá trình báo hiệu diễn ra chậm hơn dẫn đến xác xuất thời gian xử lý báo hiệu vượt quá Tout lớn hơn, và vì thế tỷ lệ lỗi cuộc gọi cũng nhiều hơn. Vì phải thông qua (các) Gatekeeper nên cấu trúc mạng sẽ phức tạp, vấn đề tổ chức và đồng bộ mạng cần phải quan tâm hơn. ở phương thức này, vì báo hiệu thông qua Gatekeeper trung gian, vì thế vấn đề tương thích báo hiệu chỉ liên quan đến đầu cuối và Gatekeeper, làm tăng khả năng lựa chọn đầu cuối cho người dùng. 2.2.4.2 Bước 2 - Thiết lập kênh điều khiển Khi kết thúc giai đoạn 1 tức là cả chủ gọi lẫn bị gọi đã hoàn thành việc trao đổi các bản tin thiết lập cuộc gọi, thì các đầu cuối sẽ thiết lập kênh điều khiển H.245. Bản tin đầu tiên được trao đổi giữa các đầu cuối là terminalCapabilitySet để các bên thông báo cho nhau khả năng làm việc của mình. Mỗi một thiết bị đầu cuối đều có đặc tính riêng nói lên khả năng chế độ mã hoá, truyền, nhận và giải mã các tín hiệu đa dịch vụ. Kênh điều khiển này có thể do thuê bao bị gọi thiết lập sau khi nó nhận được bản tin Set-up hoặc do thuê bao chủ gọi thiết lập khi nó nhận được bản tin Alerting hoặc Call Proceeding. Trong trường hợp không nhận được bản tin Connect hoặc một đầu cuối gửi Release Complete, thì kênh điều khiển H.245 sẽ được giải phóng. 2.2.4.3 Bước 3 - Thiết lập kênh truyền thông Sau khi trao đổi khả năng (tốc độ nhận tối đa, phương thức mã hoá..) và xác định quan hệ master-slave trong giao tiếp ở giai đoạn 2, thủ tục điều khiển kênh H.245 sẽ thực hiện việc mở kênh logic để truyền số liệu. Các kênh này là kênh H.225. Sau khi mở kênh logic để truyền tín hiệu là âm thanh và hình ảnh thì mỗi đầu cuối truyền tín hiệu sẽ truyền đi một bản tin h2250MaximumSkewIndication để xác định thông số truyền. 1. Thay đổi chế độ hoạt động Trong giai đoạn này các thiết bị đầu cuối có thể thực hiện thủ tục thay đổi cấu trúc kênh, thay đổi khả năng và chế độ truyền cũng như nhận (Chế độ truyền và nhận là thông báo và ghi nhận của các đầu cuối để xác định khả năng làm việc giữa chúng). 2. Trao đổi các luồng tín hiệu video Việc sử dụng chỉ thị videoIndicateReadyToActive được định nghĩa trong khuyến nghị H.245 là không bắt buộc, nhưng khi sử dụng thì thủ tục của nó như sau: đầu tiên thuê bao chủ gọi sẽ không được phép truyền video cho đến khi thuê bao bị gọi chỉ thị sẵn sàng để truyền video. Thuê bao chủ gọi sẽ truyền bản tin videoIndicateReadyToActive sau khi kết thúc quá trình trao đổi khả năng, nhưng nó sẽ không truyền tín hiệu video cho đến khi nhận được bản tin videoIndicateReadyToActive hoặc nhận được luồng tín hiệu video đến từ phía thuê bao bị gọi. 3. Phân phối các địa chỉ luồng dữ liệu Trong chế độ một địa chỉ, một đầu cuối sẽ mở một kênh logic tới MCU hoặc một đầu cuối khác. Địa chỉ của các kênh chứa trong bản tin openLogicalChannel và openLogicalChannelAck. Trong chế độ địa chỉ nhóm, địa chỉ nhóm sẽ được xác định bởi MC và được truyền tới các đầu cuối trong bản tin communicationModeCommand. Một đầu cuối sẽ báo cho MC việc mở một kênh logic với địa chỉ nhóm thông qua bản tin openLogicalChannel và MC sẽ truyền bản tin đó tới tất cả các đầu cuối trong nhóm. 2.2.4.4 Bước 4 - Dịch vụ cuộc gọi Có một số dịch vụ cuộc gọi được thực hiện trên mạng H.323 như : thay đổi độ rộng băng tần, giám sát trạng thái hoạt động, hội nghị đặc biệt, các dịch vụ bổ xung. ở đây xin được trình bày hai loại dịch vụ là “thay đổi độ rộng băng tần” và “giám sát trạng thái hoạt động”. 1. Thay đổi độ rộng băng tần Độ rộng băng tần của một cuộc gọi được Gatekeeper thiết lập trong khoảng thời gian thiết lập trao đổi. Một đầu cuối phải chắc chắn rằng tổng tất cả luồng truyền, nhận âm thanh và hình ảnh đều phải nằm trong độ rộng băng tần đã thiết lập. Tại mọi thời điểm trong khi hội thoại, đầu cuối hoặc Gatekeeper đều có thể yêu cầu tăng hoặc giảm độ rộng băng tần. Một đầu cuối có thể thay đổi tốc độ truyền trên một kênh logic mà không yêu cầu Gatekeeper thay đổi độ rộng băng tần nếu như tổng tốc độ truyền và nhận không vượt quá độ rộng băng tần hiện tại. Trong trường hợp ngược lại thì đầu cuối phải yêu cầu Gatekeeper mà nó đăng ký thay đổi độ rộng băng tần. 2. Giám sát trạng thái Để giám sát trạng thái hoạt động của đầu cuối, Gatekeeper liên tục trao đổi cập bản tin IRQ/IRR với các đầu cuối do nó kiểm soát. Khoảng thời gian đều đặn giữa các lần trao đổi các bản tin có thể lớn hơn 10 giây và giá trị của nó do nhà sản xuất quyết định. Gatekeeper có thể yêu cầu một thiết bị đầu cuối gửi cho nó bản tin IRR một cách đều đặn nhờ giá trị của trường irrFrequency trong bản tin ACF gửi cho thiết bị đầu cuối đó để xác định tốc độ truyền bản tin IRR. Khi xác định được giá trị của trường irrFrequency, thiết bị đầu cuối sẽ gửi bản tin IRR với tốc độ đó trong suốt khoảng thời gian của cuộc gọi. Trong khi đó, Gatekeeper có thể vẫn gửi IRQ tới thiết bị đầu cuối và yêu cầu trả lời theo cơ chế như đã trình bày ở trên. Trong khoảng thời gian diễn ra cuộc gọi, một đầu cuối hoặc Gatekeeper có thể đều đặn hỏi trạng thái từ đầu cuối bên kia bằng cách sử dụng bản tin Status Enquiry. Đầu cuối nhận được bản tin Status Enquiry sẽ trả lời bằng bản tin chỉ thị trạng thái hiện thời. Thủ tục hỏi đáp này có thể được Gatekeeper sử dụng để kiểm tra một cách đều đặn xem cuộc gọi có còn đang hoạt động không. Có một lưu ý là các bản tin này là bản tin H.225.0 được truyền trên kênh báo hiệu cuộc gọi không ảnh hưởng đến các bản tin IRR được truyền trên kênh RAS. 2.2.4.5 Bước 5 - Kết thúc cuộc gọi Một thiết bị đầu cuối có thể kết thúc cuộc gọi theo các bước của thủ tục sau: - Dừng truyền luồng tín hiệu video khi kết thúc truyền một ảnh, sau đó giải phóng tất cả các kênh logic phục vụ truyền video. - Dừng truyền dữ liệu và đóng tất cả các kênh logic dùng để truyền dữ liệu. - Dừng truyền audio sau đó đóng tất cả các kênh logic dùng để truyền audio. - Truyền bản tin H.245 endSessionCommand trên kênh điều khiển H.245 để báo cho thuê bao đầu kia biết nó muốn kết thúc cuộc gọi. Sau đó nó dừng truyền các bản tin H.245 và đóng kênh điều khiển H.245. - Nó sẽ chờ nhận bản tin endSessionCommand từ thuê bao đầu kia và sẽ đóng kênh điều khiển H.245 - Nếu kênh báo hiệu cuộc gọi đang mở, thì nó sẽ truyền đi bản tin Release Complete sau đó đóng kênh báo hiệu. 2.3 Giao thức khởi đầu phiên SIP 2.3.1 Giới thiệu chung về giao thức SIP SIP (Session Initiation Protocol) là một giao thức chuẩn của IETF để thực thi hệ thống VoIP. Về cơ bản SIP dựa trên ý tưởng và cấu trúc của giao thức truyền tải siêu văn bản HTTP (HyperText Transfer Protocol) để trao đổi thông tin World Wide Web. Nó được định nghĩa như một giao thức client-server, gồm một tập các bản tin đề nghị được bên gọi (client) đưa ra và các đáp ứng được bên bị gọi (server) trả lời. SIP được cấu trúc gồm bốn lớp như sau: - Lớp thấp nhất là lớp cú pháp và mã hoá (syntax and encoding). - Lớp thứ hai là lớp truyền tải (Transport layer), ở lớp này, nó định nghĩa cách thức để client gửi yêu cầu và nhận được trả lời cũng như cách thức để server nhận được yêu cầu và gửi trả lời qua mạng. - Lớp thứ ba là lớp giao dịch (Transaction layer). - Lớp trên cùng là lớp người dùng của lớp giao dịch (Transaction user layer), chính là các thực thể SIP. SIP cung cấp 5 chức năng cơ bản cho các cuộc truyền thông đa phương tiện: - Định vị người dùng (user location): xác định vị trí của đầu cuối mạng mà người dùng hiện đang ở đó. - Xác định tính sẵn sàng của người dùng (user availability): xác định xem phía bị gọi có sẵn sàng tham gia truyền thông hay không. - Xác định khả năng của người dùng (user capabilities): xác định kiểu phương tiện và các tham số của phương tiện được sử dụng. - Thiết lập phiên (Session setup): thiết lập các tham số của phiên cho cả hai phía chủ gọi và bị gọi. - Quản lý phiên (Session management): bao gồm việc truyền tải và kết thúc một phiên, thay đổi các tham số của phiên, và các dịch vụ khác có liên quan. Nói chung, SIP là một công cụ để tạo, sửa đổi và kết thúc các phiên một cách nhanh chóng và độc lập với các giao thức truyền tải ở lớp dưới cũng như không phụ thuộc vào kiểu của phiên được thiết lập. Về cơ bản SIP là một giao thức hướng văn bản và gần giống với HTTP nhưng nó không phải là một sự mở rộng của HTTP. 2.3.2 Cơ chế hoạt động của giao thức SIP SIP hoạt động theo cơ chế trao đổi các yêu cầu và đáp ứng (request/respond). Trong ví dụ này, cuộc giao dịch bắt đầu bằng việc Alice's softphone gửi một lời mời INVITE tới Bob's SIP URI. Yêu cầu INVITE chứa một số trường header gọi là các thuộc tính mang các thông tin như: mã nhận dạng cuộc gọi, địa chỉ đích, địa chỉ của chủ gọi và thông tin về kiểu phiên mà Alice muốn thiết lập với Bob. Đầu tiên, Alice gọi Bob bằng cách sử dụng địa chỉ SIP của anh ta được gọi là SIP URI (Uniform resource Identifier). Địa chỉ này tương tự như một địa chỉ e-mail bao gồm hai phần username và host name, ví dụ như URI của Bob có thể là "sip:bob@biloxi.com" (trong đó "biloxi.com" là tên miền của nhà cung cấp dịch vụ SIP cho Bob), còn URI của Alice là "sip:alice@atlanta.com". Ngoài URI, SIP còn cung cấp một loại URI được bảo đảm an toàn hơn gọi là SIPS URI, ví dụ như "sips:bob@biloxi.com". Vì Alice's softphone không biết được vị trí của Bob cũng như máy chủ SIP phục vụ miền biloxi.com, nên nó gửi bản tin INVITE tới máy chủ SIP phục vụ miền của Alice, đó là atlanta.com. Địa chỉ của server này có thể được cấu hình trước hay sử dụng giao thức cấu hình máy chủ động DHCP (Dynamic Host Configuration Protocol) để xác định. Máy chủ SIP tại Atlanta là một proxy server. Nó nhận yêu cầu INVITE sẽ gửi trở lại máy tính của Alice một đáp ứng 100 (Trying) để chỉ thị rằng INVITE đã được nhận và nó đang là đại diện cho thiết bị của Alice để định tuyến bản tin INVITE tới đích của cuộc gọi. Đáp ứng này mang cùng giá trị To, From, Call-ID, Cseq và tham số con (Branch parameter) trong mục "Via" của bản tin INVITE. Điều đó cho phép Alice's softphone có thể hiểu được đây là đáp ứng của bản tin INVITE mà nó đã gửi đi trước đó.Tiếp đến, máy chủ ở Atlanta sẽ xác định máy chủ của miền biloxi.com và chuyển tiếp bản tin yêu cầu INVITE tới đó. Khi máy chủ tại Biloxi nhận được bản tin INVITE, nó gửi trở lại một bản tin 100 (Trying) để trả lời cho máy chủ tại Atlanta biết nó đã nhận được yêu cầu và đang xử lý yêu cầu này. Tiếp đến, nó truy vấn cơ sở dữ liệu, được gọi chung là dịch vụ định vị, để xác định địa chỉ IP hiện tại của Bob. Tại các điểm trung gian, trước khi được chuyển đi bản tin INVITE sẽ được bổ sung thêm vào đầu trường "Via" địa chỉ của điểm trung gian để sử dụng sau này. Máy điện thoại của Bob khi nhận được bản tin này nó sẽ rung chuông để báo cho Bob biết có một cuộc gọi từ Alice tới để anh ta có thể quyết định xem có trả lời cuộc gọi hay không. Đồng thời máy điện thoại của Bob cũng gửi trở lại một bản tin 180 (Ringing) qua hai proxy server để trả lời cho chương trình trên máy của Alice biết cuộc gọi đã được định tuyến đến đích. Quá trình định tuyến ngược lại được thực hiện bằng cách sử dụng các địa chỉ trong trường "Via" của bản tin được sao từ bản tin INVITE. Hình 2.8 Cơ chế hoạt động của giao thức SIP Giả sử, Bob quyết định trả lời cuộc gọi từ Alice, khi đó anh ta nhấc máy và một bản tin trả lời 200 (OK) sẽ được máy điện thoại của Bob tạo ra và gửi trở lại phía Alice để thông báo rằng cuộc gọi đã được trả lời. Bản tin này có phần thân mang thông tin miêu tả về kiểu phiên mà Bob mong muốn thiết lập với Alice. Nếu Bob không muốn trả lời cuộc gọi hay anh ta đang bận tham gia một cuộc gọi khác, một đáp ứng lỗi sẽ được gửi đi thay cho bản tin 200 (OK), và khi đó sẽ không có một phiên phương tiện nào được thiết lập. Khi bản tin 200 (OK) sẽ được gửi tới chương trình thoại trên máy PC của Alice. Nó sẽ ngắt hồi âm chuông để thông báo rằng cuộc gọi đã được trả lời. Cuối cùng, Alice's softphone sẽ gửi một bản tin công nhận ACK tới máy điện thoại SIP của Bob để xác nhận rằng nó đã nhận được đáp ứng cuối cùng. Trong ví dụ này, ACK được gửi trực tiếp từ máy của Alice tới điện thoại của Bob. Điều này có thể thực hiện được bởi vì khi đó các điểm cuối đã biết được địa chỉ của nhau từ trường "Contact" trong header của các bản tin INVITE/200 (OK). Bây giờ, một phiên phương tiện đã được thiết lập giữa Alice và Bob và họ có thể gửi đi các gói sử dụng định dạng đã được đề nghị trong phần miêu tả phiên trước đó. Trong phiên dữ liệu, hoặc Alice hoặc Bob có thể quyết định thay đổi các đặc tính của của phiên. Điều đó có thể thực hiện bằng cách gửi đi một bản tin re-INVITE chứa các miêu tả mới về phương tiện tới phía bên kia. Bản tin này được tham chiếu tới dialog đang tồn tại để phía bên kia hiểu được đây là một yêu cầu thay đổi phiên đang tồn tại chứ không phải thiết lập một phiên mới. Nếu đồng ý, phía bên kia sẽ gửi trả lời bằng bản tin 200 (OK) để chấp nhận các thay đổi, và sẽ được xác nhận bằng bản tin ACK, sau đó hai bên sẽ trao đổi với nhau trên một phiên phương tiện với các tham số mới. Trong trường hợp phía bên kia không chấp nhận, nó sẽ gửi đi bản tin đáp ứng lỗi 488 (Not Acceptable Here) và cũng được xác nhận bằng bản tin ACK, khi đó hai bên tham gia vẫn tiếp tục trao đổi với nhau dựa trên các tham số của phiên phương tiện đã được thiết lập trước đó. Khi một bên tham gia muốn kết thúc cuộc gọi, anh ta đặt máy. Giả sử Bob đặt máy trước, khi đó máy của anh ta sẽ tạo ra một bản tin BYE. Bản tin này được định tuyến trực tiếp tới máy của Alice và được xác nhận bằng một đáp ứng 200 (OK), phiên phương tiện kết thúc mà không cần thiết phải gửi đi một bản tin ACK. 2.3.3 Bản tin SIP SIP là một giao thức hướng văn bản, các bản tin SIP được xây dựng dựa trên tập hợp các kí tự UTF-8 và được quy định trong RFC 2279[7]. Về cơ bản các bản tin SIP được chia làm hai loại: bản tin yêu cầu (Request) và bản tin đáp ứng (Respond). Cả hai loại bản tin này đều sử dụng chung một định dạng cơ bản được quy định trong RFC 2822[3] với cấu trúc gồm một dòng khởi đầu (start-line), một số trường tiêu đề và một phần thân bản tin tuỳ chọn. Cấu trúc này được tóm tắt như sau: generic-message = start-line *message-header CRLF [ message-body ] Với start-line = Request-Line / Status-Line Trong đó, dòng khởi đầu, các dòng tiêu đề hay dòng chống phải được kết thúc bằng một kí tự xuống dòng (CRLF) và phải lưu ý rằng dòng chống vẫn phải có để ngăn cách phần tiêu đề và thân của bản tin ngay cả khi phần thân bản tin là rỗng. 2.3.3.1 Các bản tin yêu cầu (Request) Các bản tin SIP được phân biệt với nhau dựa vào dòng đầu tiên (start line). Trong đó, các bản tin yêu cầu có dòng khởi đầu là một dòng yêu cầu (Request-line). Dòng này chứa tên phương thức, một Request-URI, và số phiên bản của giao thức. Các thành phần được ngăn cách với nhau bằng một kí tự trắng (SP). Cũng như các dòng khác, dòng khởi đầu được kết thúc bằng một ký tự xuống dòng CRLF. Request-Line = Method SP Request-URI SP SIP-Version CRLF Trong đó: - Method: chỉ định một trong 6 phương thức: REGISTER để đăng ký các thông tin, INVITE, ACK và CANCEL để quản lý phiên còn OPTIONS để truy vấn các server về khả năng của chúng. Ngoài ra, trong phiên bản SIP mở rộng còn có thể định nghĩa thêm một số phương thức nữa. - Request-URI: dùng để xác định địa chỉ của một user hay một dịch vụ mà bản tin yêu cầu này phải gửi đến. Trường này không được chứa kí tự trắng hay các kí tự điều khiển và cũng không được đóng trong khung "". - SIP-version: cả hai loại bản tin yêu cầu và đáp ứng đều chứa tên phiên bản của SIP được sử dụng tương tự như trong bản tin HTTP. Hiện nay có hai phiên bản SIP được kí hiệu là SIP và SIP/2.0. 2.3.3.2 Các bản tin trả lời (Respond) Các bản tin đáp ứng được phân biệt với các bản tin yêu cầu bằng một dòng trạng thái (Status-line) được đặt ở dòng khởi đầu của bản tin. Một dòng trạng thái bao gồm tên phiên bản của giao thức SIP, một mã trạng thái bằng và một cụm văn bản giải thích ý nghĩa của bản tin trả lời. Mỗi thành phần cũng được phân biệt với nhau bằng một kí tự trắng SP. ở cuối dòng, kí tự xuống dòng CRLF được sử dụng để tách biệt nó với dòng tiếp theo trong bản tin: Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Mã trạng thái bao gồm 3 kí tự để chỉ mã đáp ứng ra đối với yêu cầu đầu vào. Cụm từ chỉ lý do (reasion-phrase) là một miêu tả ngắn giải thích cho mã trạng thái: 1xx: Provision - đã nhận được yêu cầu, đang tiếp tục xử lý yêu cầu. 2xx: Success - yêu cầu đã được nhận được, đã được xử lý và đã được chấp nhận. 3xx: Redirection - cần thực hiện thêm một số hoạt động để hoàn thành yêu cầu. 4xx: Client error - yêu cầu chứa cú pháp không hợp lệ hay không thể hoàn thành ở server hiện tại. 5xx:Server error - server bị lỗi khi thực hiện yêu cầu bên ngoài. 6xx:Global Failure - yêu cầu không thể thực hiện được ở bất kỳ một server nào. 2.3.4 Hội thoại (Dialog) Dialog là một khái niệm rất quan trọng liên quan đến hoạt động của một tác nhân người dùng (UA) trong hệ thống SIP. Đây là một mối quan hệ giữa hai UA cùng cấp để đảm bảo trật tự các bản tin trao đổi giữa chúng và định tuyến cho các yêu cầu giữa các UA này được chính xác. Mục này sẽ thảo luận cách thức để những yêu cầu và đáp ứng được sử dụng để thiết lập một dialog và sau đó là cách thức để gửi các yêu cầu và đáp ứng bên trong một dialog. 2.3.4.1 Tạo một Dialog Một dialog được tạo ra khi UA nhận được một đáp ứng không lỗi cho một yêu cầu chứa một phương thức xác định. Ví dụ chỉ những đáp ứng 2xx và 101-199 chứa một thẻ trong trường "To" của yêu cầu INVITE sẽ thiết lập ra một dialog. Một dialog được thiết lập bởi một đáp ứng trước đáp ứng cuối cùng của một yêu cầu sẽ ở trong trạng thái "early" và nó được gọi là một early dialog. Khi một dialog được tạo ra, UA phải gán các giá trị cho các thành phần của dialog ID để phân biệt với các dialog khác. Nếu UA là một UAS, khi nó đáp ứng một yêu cầu để thiết lập một dialog (như 2xx cho INVITE chẳng hạn), UAS phải sao tất cả các giá trị trong trường tiêu đề "Record-Route" từ bản tin yêu cầu sang bản tin đáp ứng và phải duy trì được trật tự của các giá trị này. UAS còn phải bổ sung thêm một trường "Contact" vào trong đáp ứng, trường này chứa địa chỉ của nơi mà UAS muốn trao đổi các yêu cầu sau đó được gửi bên trong dialog. Địa chỉ URI này phải là toàn cục (tức là cùng một giá trị URI có thể được cùng sử dụng cho cả các bản tin bên trong và bên ngoài dialog). Sau đó, UAS tiến hành thiết lập trạng thái cho dialog. Trạng thái này phải được duy trì trong suốt thời gian tồn tại của dialog. Nếu UA là một UAC, khi nó gửi một yêu cầu để có thể thiết lập một dialog (ví dụ như một bản tin INVITE) nó phải cung cấp một SIP hay SIPS URI có phạm vi toàn cục trong trường "Contact" của bản tin yêu cầu. Nếu như yêu cầu có một "Request-URI" hay giá trị trên cùng của trường "Route" là một SIPS URI thì trường "Contact" phải chứa một SIPS URI. Khi UAC nhận được một đáp ứng để thiết lập một dialog, nó thiết lập trạng thái cho dialog này. Trạng thái này phải được duy trì trong suốt quá trình của dialog. 2.3.4.2 Xử lý các bản tin trong Dialog Khi một dialog đã được thiết lập giữa hai UA, UA gửi các yêu cầu sẽ đóng vai trò của UAC trong cuộc giao dịch và UA nhận các yêu cầu đóng vai trò của UAS. Các vai trò này có thể khác so với vai trò mà các UA đã tham gia trong quá trình thiết lập dialog. Khi có yêu cầu cần trao đổi, UAC tạo ra một bản tin yêu cầu. Muốn bản tin này được truyền trong dialog đã được thiết lập trước đó thì nó phải được cấu trúc dựa vào các thông tin trạng thái được lưu trước đó của dialog. Giá trị của các trường "Call-ID", "To", thẻ của trường "To", "From" và "tag" của trường "From" lần lượt được gán bằng các thành phần "Call-ID", "remote URI", "remote tag", "local URI" và "local tag" của dialog ID. Bản tin trả lời từ UAS được gửi ngược trở lại UAC. Khi UAC nhận được một đáp ứng 2xx cho một yêu cầu với mục đích thay đổi dialog, nó phải thay thế URI của đích đầu xa bằng URI trong trường "Contact" của đáp ứng này. Nếu như đáp ứng là 481 (Call/Transaction Does Not Exit) hay 408 (Request Timeout) thì UAC sẽ kết thúc dialog. Dialog cũng sẽ được kết thúc nếu như không có đáp ứng nào nhận được cho yêu cầu đã gửi đi khi timeout xảy ra. Nếu UAC nhận được đáp ứng 3xx cho một yêu cầu được gửi ở bên trong dialog, nó sẽ phản ứng giống với trường hợp yêu cầu được gửi ở bên ngoài dialog. 2.3.4.3 Kết thúc một Dialog Cách thức các early dialog được kết thúc không phụ thuộc vào phương thức. Tức là nếu một yêu cầu bên ngoài một dialog tạo ra một đáp ứng cuối cùng không phải là đáp ứng thuộc lớp 2xx thì những early dialog được tạo ra bởi các đáp ứng tạm thời cho yêu cầu này sẽ bị kết thúc. Ngược lại, cơ chế để kết thúc các confirmed dialog thì lại tuỳ thuộc vào từng phương thức cụ thể. Ví dụ như phương thức BYE sẽ kết thúc một phiên và dialog tương ứng với nó. Như vậy có thể thấy rằng, dialog đóng vai trò của một kênh logic báo hiệu giữa hai tác nhân người dùng để đảm bảo truyền và nhận các bản tin được trao đổi giữa chúng một cách tin cậy. 2.3.5 Các chức năng của SIP 2.3.5.1 Đăng ký (Registration) Để xác định được vị trí hiện tại của thuê bao bị gọi tại thời điểm hiện tại mạng phải sử dụng dịch vụ định vị. Trong đó sử dụng một cơ sở dữ liệu chứa các liên kết địa chỉ cho phép ánh xạ một địa chỉ SIP hay SIPS URI ở đầu vào, như sip:bob@biloxi.com chẳng hạn, với một hay nhiều URI gần hơn với user đích, ví dụ như sip:bob@engineering.biloxi.com, ở đầu ra. Cứ như thế, cuối cùng ta sẽ xác định được vị trí hiện tại mà thuê bao bị gọi hiện đang cư trú. Dịch vụ định vị hoạt động dựa trên các thuật toán tìm kiếm các liên kết địa chỉ trong một cơ sở dữ liệu. Có rất nhiều cách để xây dựng cơ sở dữ liệu cho dịch vụ định vị. Trong đó, SIP cung cấp một cơ chế để cho một tác nhân người dùng thực hiện cập nhật cơ sở dữ liệu động được gọi là đăng ký. Để đăng ký, tác nhân người dùng phải gửi đi một bản tin đăng ký REGISTER tới một UAS đặc biệt gọi là registrar. Đây là một tiền trạm của dịch vụ định vị trong một miền. Nhiệm vụ của nó là đọc và ghi các ánh xạ địa chỉ dựa vào nội dung của bản tin REGISTER. Hình vẽ 2.9 dưới đây miêu tả toàn bộ quá trình đăng ký này. Một bản tin REGISTER có thể được sử dụng để bổ sung, xoá bỏ hay truy vấn các liên kết địa chỉ. Các