CHƯƠNG 2: CÁC DỊCH VỤ TRÊN NỀN IP
2.2 VoIP Giao thức thiết lập - phiên - SIP
2.2.4 Các bản tin của SIP
• Thân bản tin
Kiểu truyền thông của thân bản tin được chỉ ra bởi tiêu đề Content–Type. Nếu thân bản tin đã qua mã hóa thì nó được chỉ ra bởi trường tiêu đề Content–Encoding.
Tập hợp các ký tự của thân bản tin được chỉ ra bởi trường tiêu đề Content–Type.
Độ dài thân bản tin tính theo Byte được đưa ra bởi trường tiêu đề Content–
Length.
Bản tin yêu cầu phải chứa các thân bản tin trừ khi có lưu ý khác (ví dụ: bản tin yêu cầu CANCEL không chứa một thân bản tin). Đối với các chỉ thị ACK, INTIVE, OPTIONS, thân bản tin bao giờ cũng là một miêu tả phiên.
Với các bản tin đáp ứng, chỉ thị yêu cầu và mã trạng thái đáp ứng xác định kiểu và sự thể hiện của các thân bản tin. Tất cả các đáp ứng đều có một thân bản tin:
- Trong các đáp ứng 1xx, thân bản tin chứa thông tin tư vấn về tiến trình của yêu cầu.
- Trong các đáp ứng 2xx cho yêu cầu INTIVE, thân bản tin chứa miêu tả phiên.
- Trong các đáp ứng 3xx, thân bản tin chứa miêu tả về các đích chọn lựa hay dịch vụ.
- Trong các đáp ứng 4xx và lớn hơn, thân bản tin gồm các thông tin bổ sung, các thông tin con người có thể đọc được về các nguyên nhân gây lỗi.
• Trường tiêu đề
Các trường tiêu đề của SIP giống các trường tiêu đề HTTP về cả cú pháp và ngữ nghĩa. Các trường tiêu đề gồm: tiêu đề chung, tiêu đề yêu cầu, tiêu đề áp dụng, tiêu đề thực thể.
- Các trường tiêu đề chung
Các trường tiêu đề chung áp dụng cho cả các bản tin yêu cầu và bản tin đáp ứng. Các tên trường “general header” có thể đượ- c mở rộng khi kết hợp với sự thay đổi về phiên bản giao thức. Tuy nhiên, trường tiêu đề mới hoặc đang thử nghiệm có thể có nghĩa như các trường tiêu đề chung nếu tất cả các bên trong phiên truyền thông đều nhận biết được chúng là các trường tiêu đề chung. Các trường tiêu đề chung không nhận biết được xử lý như các trường tiêu đề thực thể. Các trường tiêu đề chung như: Accept, Accept–Encoding, Accept–Language, Call ID, Contact, – Date, Encryption, From, Organization, Record Route, Require, Timestamp, To,– User–Agent, Via.
- Các trường tiêu đề thực thể
Các trường tiêu đề thực thể định nghĩa siêu thông tin về thân bản tin. Nếu thân bản tin không có mặt thì nó thể hiện các tài nguyên để định danh theo yêu cầu.
Thuật ngữ “tiêu đề thực thể” là thuật ngữ HTTP, ở đó phần chính của đáp ứng có
thể chứa phiên vận chuyển phần chính của bản tin. Thân bản tin ban đầu gọi là
“thực thể”. Các trường tiêu đề thực thể như: Allow, Content–Encoding, Content–
Length, Content Type, Expires.– - Các trường tiêu đề yêu cầu
Các trường tiêu đề yêu cầu cho phép Client chuyển qua các thông tin bổ sung theo yêu cầu và các thông tin về Client đến Server. Các trường này hoạt động như các bộ thay đổi theo yêu cầu với nghĩa tượng trưng với các tham số của ngôn ngữ lập trình. Các trường tiêu đề yêu cầu như: Authorziation, Max–Forwards, Priority, Proxy–Require, Response Key, Route, Subject– .
- Các trường tiêu đề đáp ứng
Các trường tiêu đề đáp ứng cho phép Server bỏ qua các thông tin bổ sung về đáp ứng khi không thể đặt trong Status-line. Các trường tiêu đề này đưa ra những thông tin về Server và về các truy nhập xa hơn đến tài nguyên được định danh bởi Request-URI. Tuy nhiên trường tiêu đề mới hoặc đang thử nghiệm có thể định nghĩa như trường “Respone-header”. Các trường tiêu đề không nhận biết được xử lý như các trường tiêu đề thực thể. Các trường tiêu đề đáp ứng như: Proxy- Authenticate, Retry After, Server, Unsupported, Warning.-
2.2.4.2 Các bản tin request
SIP không phụ thuộc vào một giao thức vận chuyển đặc biệt nào, nhưng sử dụng phổ biến trên thực tế là UDP, nó tạo điều kiện dễ dàng để giải thích các điều kiện lỗi tại các server. Các lệnh được gửi đến chỉ số cổng mặc nhiên là 5060. Các lệnh của SIP cũng có thể được gửi đến bất cứ port mở nào trong endpoint hay trong softswitch, nếu như nơi gửi biết trước chỉ số port. SIP cũng có thể thực hiện qua một giao thức kết nối tin cậy giống như TCP, nhưng điều này không phổ biến trên thực tế. Nếu dùng TCP thì các yêu cầu và các đáp ứng của cùng một cầu nối TCP (socket). Việc vận chuyển SIP qua giao thức SCTP mới được định nghĩa cũng được đề nghị.
INVITE
Thông điệp bắt buộc này là thông điệp đầu tiên được chủ gọi gửi đi để khởi động báo hiệu cuộc gọi. Nó chứa thông tin cuộc gọi trong SIP header, qua đó định danh chủ gọi, Call ID bị gọi và chỉ số tuần tự của cuộc gọi cùng với nhiều thứ khác nữa. Về cơ bản nó chỉ ra một cuộc gọi đang được xúc tiến, nhưng cũng có thể được truyền trong quá trình của cuộc gọi để sửa đổi trạng thái hoạt động của. Thông thường thông điệp INVITE chứa một đặc tả SDP của cuộc gọi, chẳng hạn như dạng truyền thông và TAS. Khi có một số lựa chọn thông số SDP, thì một trong số đó
được lựa chọn được trả về với mã thành công (200) trong thông điệp phúc đáp. Sự lựa chọn sau cùng sẽ được dùng trong cuộc gọi được dùng làm ACK method.
Thông điệp INVITE gốc sẽ chỉ cho nơi được gọi biết các header tùy chọn nào được hỗ trợ bởi nơi gọi trong trường “Supported Header” và phương thức nào là được phép trong trường “Allow”. Trao đổi này cho phép nhận dạng nhanh chóng mức độ liên kết báo hiêu giữa các endpoint.
ACK
Một phiên SIP đơn giản bắt đầu thành công với một thông điệp INVITE. Theo sau đó sẽ là một đáp ứng OK từ đối tác mời và được xác nhận bằng một ACK. Toàn bộ thông điệp ACK có thể chứa đặc tả SDP về dung lượng loại truyền thông của nơi được gọi. Nếu phúc đáp thành công không chứa đặc tả SDP, các thông số mô tả phiên của thông điệp INVITE ban đầu được dùng cho kết nối truyền thông. Một ACK không nhận đáp ứng và một softswitch tuân theo SIP phải hỗ trợ nó.
Option
Thông điệp này được gửi để truy vấn các khả năng của một đại diện gọi, cũng như để cho đối tác kia biết các khả năng của nơi truyền. Đây là công cụ khá tốt nhằm phát hiện loại truyền thông và các phương pháp mà một user ở xa hỗ trợ trước khi tạo ra một cuộc gọi. Việc hỗ trợ OPTIONS có tính chất bắt buộc.
Bye
Client truyền thông điệp này đến call agent để giải phóng cuộc gọi. Endpoint truyền kết thúc luồng truyền thông và coi như cuộc gọi đã ngưng, bất chấp có một đáp ứng từ đầu xa. Một phúc đáp BYE từ đối tác kia là không cần thiết. Một BYE cũng có thể bao gồm trường “also”, qua đó sẽ chứa thông tin tiếp xúc của đối tác kia. Nếu đây là một trường hợp thì nơi nhận được giả sử kết thúc cuộc gọi hiện tại và thiết lập một cuộc gọi mới với đối tác mới. Thật vậy, đây là một hoạt động
“transfer”, nó cũng được hỗ trợ phương thức REFER. Hỗ trợ BYE là điều bắt buộc đối với các softswitch chạy SIP.
CANCEL
Phương thức này hủy bỏ một yêu cầu trong tiến trình nhưng không ảnh hưởng đến việc thiết lập gọi khi không có yêu cầu nào đang xúc tiến. Nó được gửi khi các yêu cầu đã được đưa vào mạng và nhận được một báo nhận từ một và các giá trị To và From trong SIP header. Proxy buộc phải hỗ trợ CANCEL.
Register
Một client dùng Register để đăng ký địa chỉ được liệt kê trong trường “To” của header với một SIP Server. Một user agent có thể đăng ký với một server cục bộ vào lúc khởi động bằng cách truyền một Register đến địa chỉ multicast “all SIP
server” nổi tiếng SIP.mcast.net (224.0.1.75). Việc đăng ký có thể được thực hiện theo định kỳ bởi user hay một đối tác thứ ba thay mặt cho user. Sự tách biệt này được thể hiện trong trường “From”. Phương thức Register tương tự như lệnh H.323 RAS RRQ và cho phép user di chuyển trong các SIP domain các domain được - phục vụ bởi một softswitch đa giao thức cho phép đặc tính di động cho các SIP endpoint của nó.
Prack
Sự mở rộng của giao thức SIP cơ bản cung cấp một báo nhận cho các đáp ứng tạm thời, chẳng hạn như đáp ứng 183 Progess. Phương thức này là cần thiết để đảm bảo sự chuyển phát tin cậy các đáp ứng tạm thời đến endpoint nguồn. Các proxy chuyển tiếp các đáp ứng PRACK thay vì tái sinh chúng. Thật ra, PRACK là một đáp ứng, nhưng bản thân nó chưa phải là đáp ứng khác của các lệnh từ endpoint ở xa.
Infor
Đây là một mở rộng khác của giao thức cơ bản, nó cho phép vận chuyển báo hiệu ISDN để hỗ trợ các dịch vụ điện thoại thông thường trong một cuộc gọi. Một trường hợp sử dụng chúng là để vận chuyển các âm hiệu DTMF nhận được từ phía mạng PSTN của cuộc gọi, dưới dạng mã ASCII, đến SIP server hay server. Phương thức INFO không được dùng để thay đổi trạng thái của một cuộc gọi đã ổn định.
Refer
Sự mở rộng SIP này cung cấp khả năng chuyển cuộc gọi theo một phương pháp đủ linh hoạt để cho phép chuyển cuộc gọi không giám sát và chuyển cuộc gọi với sự tham kiến. Phương thức này cung cấp một endpoint mới được gọi bằng cách tiếp cận thông tin này, là nơi khởi động các thủ tục thiết lập cuộc gọi thông thường bằng INVITE. Một khi cuộc gọi mới đã được thiết lập, một “200 OK” được hồi âm cho nơi truyền. Điều này khá hữu ích trong việc định hướng cho một nhánh gọi đi đến một thiết bị như media server, có thể cần được xen vào trong cuộc gọi một cách tạm thời (ví dụ thực thi nhạc). Cuộc gọi có thể được khôi phục sau đó.
Comet
Đây là phương thức được đề nghị để cho phép một đối tác xác nhận tất cả các tiền định được cài đặt trong SDP của một lệnh được nhận trước đó có phù hợp với nơi truyền hay không. Các tiền định này có thể liên quan đến các nhu cầu QoS và bảo mật cho cuộc gọi, một vài hay tất cả chúng đều là bắt buộc cho cuộc gọi thành công. Các thuộc tính của SDP được thiết đặt qua “a=thông số” có thể bao gồm một yêu cầu xác nhận, trong trường hợp đó COMET được yêu cầu (nếu được hỗ trợ) để xác định cuộc gọi có thể tiến hành với các tiền định hay không. COMET phải chứa
một SDP và hoạt động trên cùng đường dẫn báo hiệu thiết lập cuộc gọi này. Mỗi tiền định trong SDP được trả về được gắn thẻ “thành công” hay “thất bại”. COMET yêu cầu một đáp ứng, nó được xem xét sau cùng. Các mở rộng của giao thức SDP được yêu cầu hỗ trợ cho COMET.
COMET và FRANK có thể công tác hỗ trợ nhau để đăng ký các tài nguyên tại hai đầu của cuộc gọi, dựa vào các SDP nhất thời được cung cấp trong một đáp ứng 183 để khởi động thông điệp INVITE. Sau khi sự đăng ký đã được thực hiện, COMET đã được dùng để xác nhận rằng các thuộc tính cho cuộc gọi có thể được thống nhất ở cả hai đầu.
2.2.4.3 Các bản tin đáp ứng: 1xx, 2xx, 3xx, 4xx, 5xx, 6xx
SIP định nghĩa sáu loại đáp ứng đối với các thông điệp. Mỗi loại đáp ứng dùng một mã trong một dải. Vài mã trả về yêu cầu sự phản ứng rõ ràng từ các server và endpoint, và vài mã khác dẫn đến một động thái nào đó của hệ thống.
Các đáp ứng nhất thời được phát ra để cho biết nơi thu đang tiến hành thực thi yêu cầu.
• 1xx: Cho biết yêu cầu đã được nhận, đang xử lý yêu cầu gửi đến.
• 2xx: Thành công. Hành động đã được nhận thành công và được chấp nhận.
• 3xx: Yêu cầu xác định lại. Một số hành động cần được thực hiện để hoàn tất yêu cầu.
• 4xx: Có lỗi ở client. Điều này có nghĩa là trong yêu cầu có lỗi cú pháp hay server không thể thi hành yêu cầu.
• 5xx: Có lỗi ở server. Điều này có nghĩa là server bị quá tải để thi hành hay đưa ra yêu cầu.
• 6xx: Lỗi toàn cục. Điều này có nghĩa là yêu cầu không thể thi hành ở bất cứ server nào.