Luận văn Tìm hiểu SS7 over IP

n thông (ITU cũng định nghĩa một giao thức tương tự là H.248) nó là giao thức điều khiển giữa MGC và MG. SIP (Session Initiation Protocol): Giao thức khởi tạo phiên, nó là giao thức điều khiển cuộc gọi hoạt động giữa MGC hoặc giữa MGC và điện thoại IP. RTP đặc tả giao thức thời gian thực như H.323 nhằm vận chuyển gói truyền thông. 3.2.2.a. CẤU TRÚC CỦA MEGACO Cấu trúc của Megaco có một vài đặc điểm giống H.323 về bộ điều khiển Gateway. Bộ điều khiển trong H.323 được gọi là Gatekeeper, còn trong Megaco được gọi là Media Gateway Controller (MGC). Trong cả hai hệ thống, các bộ điều khiển này giám sát các hoạt động của Gateway tương ứng, cũng như là hỗ trợ xử lý cuộc gọi. Tuy nhiên, Megaco thì dựa vào Web và sử dụng cơ chế khác biệt cho các hoạt động của nó. Megaco có hai khái niệm mang tính trừu tượng là: Termination và Context. Hình 3.11: Mô hình của hệ thống Megaco Megaco định nghĩa việc thêm vào hoặc bớt Termination ra khỏi Context như thế nào và di chuyển Termination giữa hai Context như thế nào. Nó định nghĩa Termination được lập trình như thế nào để phát hiện các sự kiện, như là các sự kiện thêm vào hoặc bớt ra từ các Termination đó. Termination cũng có thể được sửa đổi, như thay đổi một Termination từ trạng thái rỗi sang trạng thái gửi/nhận. Các GW có thể gửi các bản tin chú ý đến bộ điều khiển MGC về trạng thái của Termination hoặc về các sự kiện xảy ra ở Termination. 3.2.2.b. CONTEXT Context là một sự kết hợp giữa một số Termination. Có một Context đặc biệt được gọi là Context rỗng. Nó chứa các Termination không kết hợp với các Termination khác. Các Termination trong Context rỗng có thể có các tham số được khảo sát hoặc sửa đổi và có thể có các sự kiện xảy ra trên chúng. Lệnh Add dùng để thêm Termination vào Context. Nếu MGC không chỉ định một Context tồn tại để Termination được thêm vào thì MG (Media Gateway) sẽ tạo một Context mới. Lệnh Subtract dùng để xóa bỏ Termination ra khỏi một Context. Termination cũng có thể được di chuyển từ Context này sang một Context khác với lệnh Move. Một Termination chỉ tồn tại trong một Context ở một thời điểm. Số lượng Termination lớn nhất trong một Context phụ thuộc vào MG. Chẳng hạn, MG chỉ đưa ra kết nối điểm điểm thì có thể chỉ cho phép hai Termination trên một Context. Các MG hỗ trợ các cuộc hội nghị đa điểm có thể cho phép 3 hoặc nhiều Termination trên một Context. Các thuộc tính của Context: ContextID. Mô hình (topology). Mô hình của Context mô tả luồng media giữa các Termination trong một Context. Ngược lại, chế độ của Termination (nhận/gửi) mô tả luồng media ở ngõ vào/ra của MG. Sự ưu tiên được sử dụng cho một Context để cung cấp cho MG thông tin về việc điều khiển ưu tiên. MGC cũng có thể điều khiển sự ưu tiên lưu lượng trong MG khi nhiều Context phải được điều khiển đồng thời. Bộ chỉ thị (indicator) cho cuộc gọi khẩn cấp cũng được cung cấp để cho phép việc điều khiển ưu tiên trong MG. Tạo, xóa và sửa đổi Context: Megaco có thể được dùng để tạo Context và sửa đổi các giá trị tham số của Context đang tồn tại. Megaco có các lệnh để thêm Termination vào Context, bỏ Termination ra khỏi Context và di chuyển Termination giữa các Context. Context bị xóa hoàn toàn khi Termination còn lại sau cùng bị xóa bỏ hoặc di chuyển khỏi Context. 3.2.2.c. TEMINATION Termination là một thực thể luận lý trên MG, như là các nguồn hoặc các luồng điều khiển, …. Termination có duy nhất một số nhận dạng (TerminationID) được phân phối bởi MG ở thời điểm chúng được tạo ra. Termination cũng biểu hiện cho các thực thể vật lý có thời gian tồn tại bán thường trực, như là một kênh TDM. Termination cũng biểu hiện cho các luồng thông tin ngắn hạn như là các luồng RTP, thường tồn tại trong thời gian chúng được sử dụng. Các Termination ngắn hạn được tạo bởi lệnh Add và được hủy bỏ bởi lệnh Subtract. Ngược lại, một Termination vật lý được thêm vào và bỏ ra khỏi một Context thì chúng được lấy ra hoặc đưa vào một Context rỗng tương ứng. Các tín hiệu có thể áp dụng lên các Termination, các tín hiệu này như là các âm hiệu hoặc các thông báo. Các Termination cũng có thể được lập trình để phát hiện các sự kiện. 3.2.2.d. MỘT SỐ LỆNH MEGACO Add: lệnh Add dùng để thêm một Termination vào một Context. Lệnh Add trên Termination đầu tiên trong Context được dùng để tạo Context. Modify: dùng để sửa đổi các thuộc tính, sự kiện và tín hiệu của Termination. Subtract: dùng để ngắt một Termination từ một Context. Lệnh này trên Termination sau cùng trong một Context dùng để xóa Context đó. Move: dùng để di chuyển Termination trong Context này đến Context khác. AuditValue: trả lại trạng thái hiện tại của các đặc tính, các sự kiện, các tín hiệu và thống kê của Termination. Auditcapabilities: trả lại tất cả các giá trị đối với các tính chất của Termination, các sự kiện và các tín hiệu được cho phép bởi MG. Notify: cho phép MG thông báo cho MGC biết các sự kiện xảy ra trong MG. ServiceChange: cho phép MG thông báo MGC rằng một Termination hoặc một nhóm Termination chuẩn bị rời khỏi hoặc trả lại dịch vụ. Lệnh này cũng được dùng bởi MG để thông báo cho MGC sự sẵn sàng của nó. MGC cũng có thể thông báo chuyển giao tới MG bằng các gửi lệnh ServiceChange. 3.2.2.e. HOẠT ĐỘNG CỦA MEGACO Để đơn giản ta lấy ví dụ sử dụng một MGC điều khiển cả hai Gateway (Gateway cục bộ và Gateway ở xa). Mục đích của ví dụ này là trình bày 3 trạm thiết lập một Context và một Termination như thế nào. Các bản tin ACK ngoài việc xác nhận cho bản tin đã nhận mà còn chứa các thông tin cộng thêm như kết quả của việc thiết lập cổng RTP mới, đặt tên cho một Context rỗng, … MGC cũng sử dụng bộ mô tả cục bộ (LocalDesc) và bộ mô tả xa (RemoteDesc) để dành riêng và giao nguồn tài nguyên MG cho bộ mã hóa và giải mã media đối với các luồng media cho trước và Termination mà chúng áp dụng. Quá trình hoạt động của luồng giao thức Megaco như sau: Hình 3.12: Hoạt động của Megaco Bước 1: MGC gửi bản tin Modify đến Gateway cục bộ để yêu cầu Termination 1 (T1) phát hiện nhắc máy. Khi sự nhắc máy được phát hiện, Gateway cục bộ thu thập các chữ số. Context thì rỗng (CTX=Null) do nó chưa có liên hệ với một kết nối. Bước 2: lệnh Modify được công nhận. Bước 3: Gateway cục bộ phát hiện sự nhắc máy. Bước 4: nó thông báo cho MGC bằng bản tin Notify. Bước 5: MGC ghi nhận lại sự kiện này. Bước 6: MGC công nhận bản tin Notify. Bước 7: Gateway cục bộ tích lũy các chữ số được quay từ người dùng theo kế hoạch đánh số được tải từ MGC, thường trong lệnh Modify. Kế hoạch đánh số đơn giản là một biểu đồ được gửi đến Gateway để thông báo và giải thích cho nó biết các chữ số được quay như thế nào. Bước 8: các chữ số được gửi đến MGC trong lệnh Notify. Bước 9: MGC công nhận việc nhận các chữ số. Bước 10: MGC quyết định chuỗi số đúng và tạo cuộc gọi. Nó gửi lệnh Add đến Gateway cục bộ để tạo Context chứa T1. Chú ý là CTX=* nghĩa là Context chưa được đặt tên. Gateway cục bộ sẽ cung cấp một tên cho Context trong bước 11. Trong bản tin này cũng định gói Termination không tên RTP/*. Trong bản tin Add có trường LocalDesc có thể chỉ định bộ mã hóa cho cuộc gọi. Bước 11: Gateway cục bộ trả lời MGC với ACK và Context được đặt tên là C1. Nó cũng xác định bộ nhận dạng Termination RTP (RTP/ID). LocalDesc của Gateway cục bộ chỉ định bộ mã hóa được hỗ trợ trên cổng RTP. Bước 12: dựa vào thông tin nhận được từ Gateway cục bộ, MGC có thể thông báo cho Gateway ở xa thêm Termination (T1r) tương ứng với chuỗi số quay mà MGC nhận được từ Gateway cục bộ. Nhiệm vụ của MGC là ánh xạ T1r và T1 vào một Context. Nó cũng gửi trường cổng RTP chưa được đặt tên trong bản tin này. Thông tin trong LocalDesc của T1 được đưa đến Gateway ở xa trong trường RemoteDesc, thông tin này chỉ định bộ mã hóa cho T1r từ Gateway cục bộ. Trường LocalDesc trong bản tin này có thể rỗng hoặc có thể chứa đựng các thông số mà MGC mong muốn Gateway ở xa sử dụng cho cuộc gọi này, như kích thước gói cho các mẫu VoIP. Bước 13: Gateway ở xa trả lời lại lệnh Add với Context được đặt tên C1r, Termination RTP được đặt tên RTP/IDr và LocalDesc của Gateway xa chỉ định bộ mã hóa được hỗ trợ trên cổng RTP nhận của nó. Giá trị LocalDesc được gửi đến Gateway này trong bước 12 có thể được thay đổi trong bước này. Bước 14: bây giờ, MGC sử dụng lệnh Modify để yêu cầu rung chuông (Ring) trên T1r. Bản tin cũng yêu cầu Gateway này tìm kiếm sự nhắc máy. Bước 15: Gateway ở xa đưa tín hiệu chuông lên đường dây của người bị gọi. Bước 16: nó cũng đáp ứng đến MGC với ACK. Bước 17: MGC gửi lệnh Modify đến Gateway cục bộ (Gateway phía người gọi). Lệnh này yêu cầu đưa tín hiệu chuông lên T1 và nhận dạng cổng RTP ở xa trong RemoteDesc trong bản tin. Bước 18: tín hiệu chuông được đưa lên T1. Bước 19: Gateway cục bộ trả lời MGC là tín hiệu chuông đã được đưa lên T1 và các thiết lập RTP được cập nhật. Bước 20: người bị gọi trả lời cuộc gọi (nhắc máy). Bước 21: Gateway ở xa gửi bản tin Notify chứa thông tin này đến MGC và tín hiệu chuông được hủy bỏ. Bước 22: MGC công nhận bản tin Notify. Bước 23: MGC phát lệnh Modify để hủy bỏ tín hiệu chuông trên T1 và thiết lập một đường hai chiều (TerminationState=sendrcv). Thông tin trong SignalList được dùng để hủy bỏ tín hiệu chuông trên T1. Bước 24: Gateway cục bộ công nhận bản tin Modify, bỏ tín hiệu chuông và sự thiết lập cuộc gọi đã hoàn tất. 3.2.3. SIP 3.2.3.a. TỔNG QUAN Giao thức khởi tạo phiên (SIP: Session Initiation Protocol) là một giao thức điều khiển và đã được tiêu chuẩn hóa bởi IETF. Nhiệm vụ của nó là thiết lập, hiệu chỉnh và xóa các phiên làm việc giữa các người dùng. Các phiên làm việc cũng có thể là hội nghị đa phương tiện, cuộc gọi điện thoại điểm - điểm, …. SIP được sử dụng kết hợp với các chuẩn giao thức IETF khác như là SAP, SDP và MGCP (MEGACO) để cung cấp một lĩnh vực rộng hơn cho các dịch vụ VoIP. Cấu trúc của SIP cũng tương tự với cấu trúc HTTP (giao thức client-server). Nó bao gồm các yêu cầu được gửi đến từ người sử dụng SIP client tới SIP server. Server xử lý các yêu cầu và đáp ứng đến các client. Một thông điệp yêu cầu, cùng với các thông điệp đáp ứng tạo nên sự thực thi SIP. SIP là một công cụ hỗ trợ hấp dẫn đối với điện thoại IP vì các lý do sau: Nó có thể hoạt động không trạng thái hoặc có trạng thái. Vì vậy, sự hoạt động không trạng thái cung cấp sự mở rộng tốt do các server không phải duy trì thông tin về trạng thái cuộc gọi một khi sự thực hiện (transaction) đã được xử lý. Nó có thể sử dụng nhiều dạng hoặc cú pháp giao thức chuyển siêu văn bản HTTP (Hypertext Transfer Protocol), vì vậy, nó cung cấp một cách thuận lợi để hoạt động trên các trình duyệt. Bản tin SIP (nội dung bản tin) thì không rõ ràng, nó có thể là bất cứ cú pháp nào. Vì vậy, nó có thể được mô tả theo nhiều cách. Chẳng hạn, nó có thể được mô tả với sự mở rộng thư Internet đa mục đích MIME (Multipurpose Internet Mail Extension) hoặc ngôn ngữ đánh dấu mở rộng XML (Extensible Markup Language). Nó nhận dạng một người dùng với bộ định vị tài nguyên đồng nhất URL (Uniform Resource Locator), vì vậy, nó cung cấp cho người dùng khả năng khởi tạo cuộc gọi bằng cách nhấp vào một liên kết trên trang web. Các chức năng chính của SIP: Xác định vị trí của người sử dụng (user location): hay còn gọi là chức năng dịch tên (name translation) và xác định người được gọi. Dùng để đảm bảo cuộc gọi đến được người nhận dù họ ở đâu. Xác định khả năng của người sử dụng: còn gọi là chức năng thương lượng đặc tính cuộc gọi (feature negotiation). Dùng để xác định loại thông tin và các loại thông số liên quan đến thông tin sẽ được sử dụng. Xác định sự sẵn sàng của người sử dụng: dùng để xác định người được gọi có muốn tham gia vào kết nối hay không. Thiết lập cuộc gọi: chức năng này thực hiện việc rung chuông, thiết lập các thông số cuộc gọi cửa các bên tham gia kết nối. Xử lý cuộc gọi: bao gồm chuyển và kết thúc cuộc gọi, quản lý những người tham gia cuộc gọi, thay đổi đặc tính cuộc gọi. 3.2.3.b. CẤU TRÚC CỦA SIP Một khía cạnh khác biệt của SIP đối với các giao thức xử lý cuộc gọi IP khác là nó không sử dụng bộ điều khiển Gateway. Nó không dùng khái niệm Gateway/bộ điều khiển Gateway nhưng nó dựa vào mô hình khách/chủ (client/server). UA (User Agent): là một ứng dụng chứa cả UAC (User Agent Client) và UAS. UAC (User Agent Client): đây là phần người sử dụng được dùng để khởi tạo một yêu cầu SIP tới server SIP hoặc UAS. UAS (User Agent Server): là một ứng dụng server giao tiếp với người dùng khi yêu cầu SIP được nhận và trả lại một đáp ứng đại diện cho người dùng. User Agent là một điểm cuối giao tiếp với người dùng và hoạt động đại diện cho người dùng. User Agent bao gồm hai thành phần: một giao thức client được biết như là UAC và một giao thức server được biết như là UAS. UAC khởi tạo cuộc gọi và UAS trả lời cuộc gọi. Do User Agent chứa cả UAC và UAS nên SIP có thể hoạt động ngang hàng khi sử dụng mô hình client/server. Server: là một chương trình ứng dụng chấp nhận các bản tin yêu cầu để phục vụ các yêu cầu này và gửi trả các đáp ứng cho các yêu cầu đó. Server là Proxy, gửi lại (redirect), UAS hoặc Registrar. Proxy server: là một chương trình trung gian, hoạt động như là một server và một client cho mục đích tạo các yêu cầu thay mặt cho các client khác. Các yêu cầu được phục vụ bên trong hoặc truyền chúng đến server khác. Một Proxy có thể dịch và nếu cần thiết, có thể tạo lại bản tin yêu cầu SIP trước khi chuyển chúng đến server khác hoặc một UA. Redirect server: là một server chấp nhận một yêu cầu SIP, ánh xạ địa chỉ trong yêu cầu thành một địa chỉ mới và trả lại địa chỉ này trở về client. Không giống như Proxy Server, nó không khởi tạo một yêu cầu SIP và không chuyển các yêu cầu đến các Server khác. Không giống như Server đại diện người dùng UAS, nó không chấp nhận cuộc gọi. Location/Registration Server: Là server được các server còn lại sử dụng để lấy thông tin về vị trí của người được gọi. Nó được dùng để đăng ký các đối tượng SIP trong miền SIP và cập nhật vị trí hiện tại của chúng. Một miền SIP thì tương tự với một vùng H.323. 3.2.3.c TỔNG QUAN VỀ HOẠT ĐỘNG CỦA SIP Địa chỉ SIP: tồn tại dưới dạng user@host. Phần user trong phần địa chỉ có thể là tên người sử dụng hoặc số điện thoại. Phần host có thể là tên miền hoặc địa chỉ mạng. Ví dụ địa chỉ SIP: sip:ciscopress@cisco.com sip:4085262222@171.171.171.1 Định vị server SIP: Khi client muốn gửi một yêu cầu, client gửi nó đến một proxy server SIP đã được cấu hình hoặc gửi yêu cầu đến địa chỉ IP và số cổng tương ứng với URL SIP. Gửi yêu cầu trực tiếp đến proxy server thì dễ dàng nếu ứng dụng cuối đã biết proxy server. Gửi yêu cầu theo cách thứ hai thì phức tạp hơn. Client phải cố gắng tiếp xúc với server ở số cổng được liệt kê trong bộ định vị tài nguyên đồng nhất URL SIP. Nếu số hiệu cổng không có trong URL SIP thì client sử dụng số cổng 5060. nếu URL SIP chỉ định một giao thức (UDP hoặc TCP) thì client tiếp xúc với server sử dụng giao thức đó. Nếu không có giao thức nào được chỉ định hoặc nếu client không hỗ trợ UDP nhưng có hỗ trợ TCP thì nó cố gắng dùng TCP. Client cố gắng tìm một hoặc nhiều địa chỉ server SIP bằng cách truy vấn DNS (Domain Name System). Tiến trình như sau: Nếu phần host của URL SIP là địa chỉ IP, client tiếp xúc với server ở địa chỉ cho trước. Ngược lại nó xử lý bước kế tiếp. Client truy vấn server DNS cho địa chỉ phần host của URL SIP. Nếu server DNS không trả về địa chỉ của URL SIP, client sẽ ngừng vì nó không thể định vị được server. Sự giao dịch SIP (SIP Transaction): Khi phần host của URL SIP đã được giải quyết, client gửi một hoặc nhiều yêu cầu SIP đến server và nhận được một hoặc nhiều đáp ứng từ server. Các yêu cầu cùng với các đáp ứng liên hệ với nhau trong hoạt động này tạo thành sự giao dịch SIP. Tất cả các đáp ứng chứa cùng các giá trị trong các trường Call-ID, Cseq, To và From. Điều này cho phép các đáp ứng so khớp với các yêu cầu. Nếu TCP được sử dụng, các đáp ứng và yêu cầu trong một sự giao dịch đơn lẻ được mang trên cùng một kết nối TCP. Nhiều yêu cầu SIP từ một client đến một server có thể sử dụng cùng kết nối TCP hoặc có thể sử dụng một kết nối mới cho mỗi yêu cầu. Nếu client gửi yêu cầu sử dụng UDP, đáp ứng được gửi đến địa chỉ được định nghĩa trong trường tiêu đề của yêu cầu. Lời mời SIP (SIP Invitation) Một lời mời SIP thành công bao gồm hai bản tin: bản tin INVITE và theo sau là bản tin ACK. Bản tin INVITE yêu cầu người bị gọi tham gia vào một hội nghị đặc biệt hoặc thiết lập một cuộc đối thoại hai người. Sau khi người bị gọi đồng ý tham gia cuộc gọi, người gọi xác nhận rằng nó đã nhận được đáp ứng bằng cách gửi bản tin ACK. Định vị người dùng: Người bị gọi có thể di chuyển giữa nhiều hệ thống đầu cuối theo thời gian. Các vị trí này có thể đăng ký động với server SIP. Một server vị trí có thể trả về nhiều vị trí bởi vì người dùng đăng nhập ở nhiều trạm một cách đồng thời hoặc server vị trí có thông tin không chính xác. Server SIP kết hợp các kết quả để cung cấp một danh sách các vị trí hoặc không có vị trí nào. Hoạt động nhận danh sách các vị trí thay đổi tùy thuộc vào server SIP. Một Redirect server trả về một danh sách hoàn chỉnh các vị trí và cho phép các client định vị người dùng chính xác. Một Proxy server cũng cố gắng định địa chỉ cho đến khi cuộc gọi thành công hoặc người bị gọi từ chối cuộc gọi. Thay đổi một phiên đang tồn tại: Trong một số trường hợp, người ta mong muốn thay đổi các thông số của một phiên đang tồn tại. Điều này được thực hiện bằng cách phát lại bản tin INVITE, sử dụng cùng Call-ID, nhưng nội dung mới hoặc các trường tiêu đều mang thông tin 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 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 mô tả phiên multicast mới, ngoại trừ số nhận dạng cuộc gọi là cũ. 3.2.3.d. CÁC BẢN TIN SIP Có hai loại bản tin SIP: bản tin yêu cầu được khởi tạo từ client và bản tin đáp ứng được trả lại từ server. Mỗi bản tin chứa một tiêu đề mô tả chi tiết về sự truyền thông. SIP có thể sử dụng cả TCP và UDP, nhiều sự giao dịch SIP có thể được mang trên một kết nối TCP đơn lẻ hoặc gói dữ liệu UDP. Gói dữ liệu UDP (bao gồm tất cả các tiêu đề) thì không vượt quá đơn vị truyền dẫn lớn nhất MTU (Maximum Transmission Unit) nếu MTU được định nghĩa, hoặc không quá 1500 byte nếu MTU không được định nghĩa. Một bản tin SIP cơ bản bao gồm 4 phần: dòng bắt đầu (start-line), một hoặc nhiều trường tiêu đề, một dòng trống (CRLF) dùng để kết thúc các trường tiêu đề và phần nội dung bản tin. Tiêu đề bản tin dùng để chỉ ra người gọi, người bị gọi, đường định tuyến và loại bản tin của cuộc gọi. Có 4 nhóm tiêu đề bản tin như sau: Tiêu đề chung: áp dụng cho các yêu cầu và các đáp ứng. Tiêu đề thực thể: định nghĩa thông tin về loại bản tin và chiều dài. Tiêu đề yêu cầu: cho phép client thêm vào các thông tin yêu cầu. Tiêu đề đáp ứng: cho phép server thêm vào các thông tin đáp ứng. Tiêu đề chung Tiêu đề thực thể Tiêu đề yêu cầu Tiêu đề đáp ứng Accept Content-Encoding Authorization Allow Accept-Encoding Content-Length Contact Proxy-Authenticate Accept-Language Content-Type Hide Retry-After Call-ID Max-Forwards Server Contact Organization Unsupported CSeq Priority Warning Date Proxy-Authorization www-Authenticate Encryption Proxy-Require Expires Route From Require Record-Route Response-Key Timestamp Subject To User-Agent Via Bảng 3.1: Các tiêu đề bản tin của SIP Tiêu đề Giải thích Call-ID So khớp các yêu cầu với các đáp ứng tương ứng, nhận dạng duy nhất lời mời hoặc sự đăng ký của client. Cseq Trong một cuộc gọi, Cseq tăng lên khi một yêu cầu mới được gửi đi và bắt đầu ở một giá trị ngẫu nhiên. Tuy nhiên, đối với yêu cầu ACK và Cancel thì Cseq không tăng. To Có mặt trong tất cả các yêu cầu và đáp ứng để chỉ ra nơi nhận yêu cầu. From Có mặt trong tất cả yêu cầu và đáp ứng chứa tên và địa chỉ của nơi khởi tạo yêu cầu. Via Ghi lại đường đi của yêu cầu để cho phép các server SIP trung gian chuyển các câu trả lời trở lại cùng đường đi. Encryption Chỉ định nội dung và một số tiêu đề bản tin đã được mã hóa như thế nào. Content-Length Chỉ ra kích thước của nội dung bản tin (tính bằng octet). Content-Type Chỉ ra loại media của nội dung bản tin (văn bản/html, …). Expires Nhận dạng ngày và thời gian khi bản tin hết hạn Accept Chỉ ra loại media nào được chấp nhận trong bản tin đáp ứng. Subject Cho thông tin về bản chất của cuộc gọi. Bảng 3.2: Một số loại tiêu đề bản tin chính của SIP Bản tin yêu cầu: Các yêu cầu cũng có thể được xem như các phương pháp (method) cho phép User Agent và server mạng có thể định vị, mời và quản lý các cuộc gọi. Bản tin yêu cầu SIP có Dòng bắt đầu là một dòng yêu cầu. Phần tiêu đề là các tiêu đề thuộc 3 loại tiêu đề chung/tiêu đề yêu cầu/tiêu đề thực thể. Dòng yêu cầu bắt đầu với mã phương pháp, bộ nhận dạng tài nguyên đồng nhất yêu cầu, phiên bản giao thức SIP và kết thúc với CRLF. Các thành phần được phân cách bởi kí tự SP. Dòng yêu cầu = Method SP Request-URI SP SIP-Version CRLF. Có 6 loại bản tin yêu cầu SIP: INVITE, ACK, OPTIONS, BYE, CANCEL và REGISTER. INVITE: chỉ ra người dùng hoặc dịch vụ đang được mời tham dự một phiên làm việc. Nội dung bản tin chứa sự mô tả phiên mà người dùng được mời. Đối với cuộc gọi hai người, bên gọi chỉ ra loại media mà nó có thể nhận. Một đáp ứng thành công phải chứa trong nội dung bản tin của nó loại media nào mà người bị gọi mong muốn nhận. Với bản tin này, người dùng có thể nhận biết được khả năng của người dùng khác và mở ra một phiên hội thoại với số bản tin giới hạn. ACK: bản tin xác nhận client đã nhận được đáp ứng sau cùng đối với bản tin INVITE (ACK chỉ được sử dụng với bản tin INVITE). Nội dung bản tin ACK chứa sự mô tả phiên sau cùng được sử dụng bởi người bị gọi. Nếu nội dung bản tin ACK rỗng thì người bị gọi sử dụng sự mô tả phiên trong bản tin INVITE. OPTIONS: Bản tin này cho phép truy vấn, thu thập User Agent và các khả năng của server mạng nhằm xác định đặc tính cuộc gọi. BYE: User Agent Client sử dụng bản tin BYE báo cho server biết nó muốn giải phóng cuộc gọi. Bản tin BYE được chuyển giống như là bản tin INVITE và có thể được phát đi từ người gọi hoặc người bị gọi. Khi một đối tác nhận bản tin BYE thì nó phải ngừng việc truyền các luồng dữ liệu về hướng đối tác phát đi bản tin BYE. CANCEL: Bản tin CANCEL cho phép User Agent và server mạng hủy bỏ bất cứ yêu cầu nào đang trong quá trình xử lý, nó không ảnh hưởng đến yêu cầu đã hoàn thành mà các đáp ứng sau cùng đã được nhận. REGISTER: Bản tin này được sử dụng bởi client để đăng ký thông tin vị trí của nó với server SIP. Bản tin đáp ứng: Các bản tin đáp ứng có dạng: dòng bắt đầu là dòng trạng thái còn các tiêu đề thuộc 3 loại sau: tiêu đề chung/tiêu đề đáp ứng/tiêu đề thực thể. Dòng trạng thái bao gồm phiên bản của giao thức, mã trạng thái (số), lý do và CRLF. Các thành phần được cách nhau bằng hai kí tự SP. Dòng trạng thái = SIP-version SP Status-Code SP Reason-Phrase CRLF Mã trạng thái có 3 chữ số chỉ ra kết quả của việc đáp ứng yêu cầu. Lý do (Reason-Phrase) là sự mô tả ngắn gọn về mã trạng thái. Chữ số đầu tiên của mã trạng thái định nghĩa lớp đáp ứng. SIP phiên bản 2.0 định nghĩa 6 giá trị cho lớp đáp ứng. 1xx: thông tin – các yêu cầu được nhận, xử lý các yêu cầu. 2xx: thành công – hoạt động được nhận thành công và được chấp nhận. 3xx: đổi hướng (redirection): cần thêm một số hoạt động để hoàn thành yêu cầu. 4xx: lỗi client – yêu cầu bị sai lỗi cú pháp hoặc không thỏa mãn ở server. 5xx: lỗi server – server không thỏa mãn một yêu cầu đúng. 6xx: lỗi toàn cầu – yêu cầu không thể thỏa mãn ở bất kì server nào. Lớp đáp ứng Mã trạng thái Giải thích Thông tin 100 Đang cố gắng 180 Rung chuông 181 Cuộc gọi được chuyển 182 Được xếp hàng đợi Thành công 200 OK Đổi hướng 300 Nhiều chọn lựa 301 Được di chuyển thường xuyên 302 Được di chuyển tạm thời 380 Dịch vụ thay đổi Lỗi client 400 Yêu cầu lỗi 401 Không nhận thực được 402 Yêu cầu trả tiền (payment required) 403 Cấm 404 Không tìm thấy 405 Bản tin không cho phép 406 Không chấp nhận 407 Yêu cầu nhận thực proxy 408 Yêu cầu timeout 409 Xung đột 410 Tiếp tục (gone) 411 Yêu cầu chiều dài 413 Thực thể yêu cầu quá lớn 414 URL yêu cầu quá lớn 415 Không hỗ trợ loại media 420 Mở rộng sai 480 Không sẵn có 481 Cuộc gọi hoặc sự trao đổi không tồn tại 482 Vòng lặp được phát hiện 483 Quá nhiều hop 484 Địa chỉ không hoàn thành 485 Mơ hồ 486 Đang bận Lỗi server 500 Lỗi server bên trong 501 Không thực thi 502 Gateway lỗi 503 Dịch vụ không có sẵn 504 Gateway timeout 505 Phiên bản SIP không hỗ trợ Lỗi toàn cầu 600 Bận ở mọi nơi 603 Từ chối 604 Không tồn tại ở mọi nơi 606 Không chấp nhận Bảng 3.3: Các đáp ứng của SIP 3.2.3.e. CÁC HOẠT ĐỘNG CHÍNH CỦA SIP Hoạt động của Proxy server Hoạt động của Proxy server được trình bày như hình 4.21. Client SIP userA@yahoo.com gửi bản tin INVITE cho userB@hotmail.com để mời tham gia cuộc gọi. Từng bước được mô tả như sau: Bước 1: UserA (userA@yahoo.com) gửi bản tin INVITE cho UserB ở miền hotmail.