Đồ án Giao thức khởi tạo phiên và ứng dụng(SIP)

UA (Uers Agent). Hội nghị (Conference): hội nghị là một phiên đa phương tiện. Một hội nghị có thể không có hoặc có nhiều thành viên và bao gồm các trường hợp như hội nghị đa phương, thoại hai thành viên. Đoạn thoại (dialog): một đoạn giữa các UA có quan hệ “ngang hàng” và nó được duy trì trong một khoảng thời gian. Một đoạn thoại được thiết lập bởi các bản tin SIP, chẳng hạn như 2xx đáp ứng cho yêu cầu INVITE. (Trong RFC 2543 thì nó chính là Call leg: Call leg được nhận biết bởi sự kết hợp của Call-ID, To và From). Đáp ứng kết thúc (Final Respone): là đáp ứng kết thúc một phiên giao dịch SIP, bao gồm các lớp đáp ứng sau: 2xx, 3xx, 4xx, 5xx, 6xx. Lời mời (invitation): là yêu cầu gửi từ User hoặc Service đề nghị tham gia vào một phiên hội thoại. Một lời mời đầy đủ gồm một yêu cầu INVITE ngay sau một yêu cầu ACK. Tìm kiếm song song (Parallel search): trong một quá trình tìm kiếm song song, một proxy đưa ra một vài yêu cầu tới người dùng hiện tại trong khi nhận một yêu cầu đến. Đáp ứng tạm thời (provisional respone): đáp ứng tạm thời là đáp ứng được Server dùng để thông báo tiến trình gọi nhưng chưa kết thúc một phiên giao dịch SIP, đáp ứng 1xx là đáp ứng tạm thời. Server: là một chương trình ứng dụng có nhiệm vụ nhận các yêu cầu hợp lệ từ các dịch vụ và gửi trả lại các đáp ứng. Server có thể là Proxy, Redirect, UAS, Registrars. Phiên (session) : theo đặc tả của SDP thì một phiên đa truyền thông là tập hợp những người gửi và nhận cùng với dòng dữ liệu từ nơi gửi đến nơi nhận. Nó được xác định bởi chuỗi tên người dùng, phiên nhận dạng, kiểu mạng, kiểu địa chỉ và địa chỉ các phần tử trong trường nguồn. Giao dịch SIP (SIP transaction): giao dịch SIP là quá trình xảy ra giữa một Client và một Server gồm tất cả các bản tin từ yêu cầu đầu tiên gửi đi từ client đến server cho đến đáp ứng kết thúc từ Server gửi trả lại Client. Nó được nhận biết bởi số thứ tự CSeq. Yêu cầu ACK có cùng số CSeq với yêu cầu INVITE tương ứng nhưng chứa một giao dịch của riêng nó. Bản tin: dữ liệu gửi giữa các phần tử SIP, nó như là một phần của giao thức. Có hai loại bản tin đó là bản tin yêu cầu và bản tin đáp ứng. Yêu cầu: là một bản tin SIP được gửi từ client tới server nhằm mục đích yêu cầu hoạt động. Đáp ứng: là bản tin SIP được gửi từ server tới client, nó chỉ ra trạng thái của yêu cầu gửi từ client tới server. Proxy hướng ra: một proxy mà nhận yêu cầu từ một client. Thông thường, UA cấu hình với proxy hướng ra, hoặc là nó có thể học thông qua việc cấu hình tự động. Proxy, Proxy Server: nó là phần tử trung gian, hoạt động giống như là server và client. Stateful Proxy: là proxy có duy trì trạng thái giao dịch client và server trong quá trình xử lý yêu cầu. Stateless Proxy: là proxy mà không duy trì trạng thái giao dịch client và server khi nó xử lý yêu cầu. Redirect Server: máy chủ chuyển tiếp, nó là UAS và phát các đáp ứng 3xx đáp lại các yêu cầu mà nó nhận được. TU (Transaction User): giao dịch người dùng là quá trình xử lý lớp giao thức mà nằm trên lớp giao dịch. UAC (User Agent Client): là thực thể mà tạo yêu cầu mới, và sau đó dùng cơ cấu trạng thái giao dịch client để gửi yêu cầu. UAS (User Agent Server): là thực thể mạng mà phát đáp ứng trả lời yêu cầu SIP. Đáp ứng có thể chấp nhận, từ chối, chuyển tiếp yêu cầu. Phần II. NỘI DUNG 2.1 Các Thành phần của SIP Giao thức SIP gồm hai thành phần chính là: - Đại lý trạm người dùng (user agent ) - Máy chủ mạng (Network Server ) Hình 2.1: Cấu trúc của SIP 2.1.1 User Agent (UA) - User Agent ( UA) là một hệ thống cuối cùng hoạt động trên nhân danh của người dùng, User Agent phải có khả năng thiết lập một session của phương tiện này với các user agent khác. UA bao gồm User Agent Client (UAC) khởi tạo cuộc gọi và User Agent Server (USA) trả lời cuộc gọi. - User Agent (UA) có thể là máy điện thoại SIP hoặc máy tính chạy phần mềm đầu cuối SIP. ( Điện thoại SIP giống như Điện thoại VoIP hoặc điện thoại mềm,đây là các điện thoại cho phép thực hiện các cuộc gọi bằng cách sử dụng công nghệ VoIP giao thức truyền giọng nói qua Internet, điện thoại SIP chạy trên phần cứng giống như điện thoại để bàn nhưng có thể nhận và thực hiện các cuộc gọi qua internet thay vì hệ thống PSTN truyền thống, điện thoại SIP cũng có thể chạy trên phần mềm. Các tùy chọn này cho phép mọi máy tính được sử dụng như điện thoại qua tai nghe có micrô hoặc card âm thanh. Ngoài ra, cần phải kết nối băng thông rộng và kết nối với nhà cung cấp VOIP hoặc máy chủ SIP). Hình 2.2.1 Sơ đồ User Agent 2.1.2 Máy chủ mạng (Network Server ) Máy chủ mạng bao gồm: 2.1.2.1 Máy chủ ủy quyền (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 các server khác. Một proxy có thể dịch và nếu cần thiết có thể tạo lại các bản tin yêu cầu SIP trước khi chuyển chúng đến server khác hoặc một UA. Trong trường hợp này trường Via trong bản tin đáp ứng, yêu cầu chỉ ra các proxy trung gian tham gia vào tiến trình xử lý yêu cầu. 2.1.2.2 Máy chủ định vị (Location Server) : là phần mềm định vị thuê bao, cung cấp thông tin về những vị trí có thể của thuê bao bị gọi cho các phần mềm máy chủ ủy quyền và máy chủ chuyển đổi địa chỉ. 2.1.2.3 Máy chủ chuyển đổi địa chỉ (Redirect Server): là phần mềm nhận yêu cầu SIP và chuyển đổi địa chỉ SIP sang một số địa chỉ khác và gửi lại cho đầu cuối. Không giống như máy chủ ủy quyền, máy chủ chuyển đổi địa chỉ không bao giờ hoạt động như một đầu cuối, tức là không gửi đi bất cứ yêu cầu nào. Máy chủ chuyển đổi địa chỉ cũng không nhận hoặc huỷ cuộc gọi. 2.1.2.4 Máy chủ đăng ký (Register Server): là phần mềm nhận các yêu cầu đăng ký,trong nhiều trường hợp máy chủ đăng ký đảm nhiệm luôn một số chức năng an ninh như xác nhận người sử dụng. Thông thường máy chủ đăng ký được cài đặt cùng với máy chủ ủy quyền và máy chủ hay địa chỉ hoặc cung cấp dịch vụ định vị thuê bao. Mỗi lần đầu cuối được bật lên ( ví dụ máy điện thoại hoặc phần mềm SIP) thì đầu cuối lại đăng ký với máy chủ. Nếu đầu cuối cần thông báo cho máy chủ về địa điểm của mình thì bản tin REGISTER cũng được gửi đi. Nói chung các đầu cuối đều thực hiện việc đăng ký lại một cách định kỳ. 2.2 Địa chỉ SIP Địa chỉ SIP thường là URI với giản đồ sip, hoặc là sips được sử dụng trong một số trường header như là To, From và Contact để chỉ ra đích. SIP URI chứa giản đồ “sip” với dấu ‘:’, sau đó sẽ là địa chỉ có dạng username@host hoặc là địa chỉ IPv4, tiếp theo đó là dấu ‘:’ sau đó là port number, và sau đó là ‘;’ và các thông số của URI được phân cách bởi dấu ‘;’. Thí dụ: sip: lop.h09vt9@transform.org: 5060; transport=udp; user=ip; method = INVITE; ttl =1; maddr =240.101.102.103 Một số SIP URI, chẳng hạn như REGISTER, Request-URI không có “username”, nhưng nó bắt đầu với host hoặc là địa chỉ IPv4. Trong thí dụ trên, số cổng là 5060 là cổng dành cho SIP. Với SIP URI nếu như không có số cổng, thì nó giả định là 5060. Với SIPS URI cổng được giả định là 5061. Trong thí dụ trên thông số truyền tải “transport” là UDP được sử dụng. Các thông số transport khác có thể được dùng là TCP, TLS. Thông số user được sử dụng để xác định đối tượng được dùng của URI. Khi không có mặt thông số này, thì nó có giá trị mặc định là “ip”.Nếu thông số user = phone, thì nó chỉ thị giá trị là số điện thoại. Thông số này không được sử dụng để phỏng đoán với các đặc điểm hoặc khả năng của UA. Nếu user = phone thì URI trong SIP lúc này sẽ là tel URI (thí dụ tel URI, tel: +84906264755). Thông số method được sử dụng để chỉ thị phương thức được sử dụng. Giá trị mặc định là INVITE. Thông số này không có trong các trường header To và From, nhưng mà có thể được sử dụng trong header Contact để đăng kí. Với thông số ttl (time-to-live), nó chỉ được sử dụng nếu như thông số maddr chứa địa chỉ multicast và thông số truyền tải chứa UDP. Giá trị mặc định là 1. Giá trị này có nghĩa là phiên multicast. Thông số maddr thường chứa địa chỉ multicast khi mà các yêu cầu có thể được chuyển hướng. Tuy nhiên nó cũng có thể chứa địa chỉ unicast của một server khác để yêu cầu. Giản đồ sips URI có cấu trúc giống như sip URI nhưng nó bắt đầu với tên giản đồ là sips. Chú ý sips URI có yêu cầu bảo mật cao hơn sip URI, thông số transport của sips URI luôn có giá trị là tls. Với sips URI, với lớp truyền tải TLS được sử dụng là end-to-end cho đường truyền SIP. 2.3 Bản tin SIP SIP là giao thức dạng TEXT sử dụng bộ kí tự UTF-8. Bản tin SIP có thể chia ra làm 2 loại chính là: yêu cầu và đáp ứng. Bản tin yêu cầu có 6 loại, được khai báo trong trường thông số chỉ thị (Method). Bản tin đáp ứng được phân theo lớp, nó có thông số mã trạng thái (Status Code) và ta có thể xem các loại bản tin. 2.3.1 Cấu trúc bản tin SIP Bản tin SIP gồm nhiều dòng text, mỗi dòng kết thúc bằng một kí tự CRLF (Carriage-Return Line-Feed: hết dòng bắt đầu dòng mới) và phải lưu ý rằng dòng trố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. Cả bản tin yêu cầu và đáp ứng đều sử dụng chung một định dạng cơ bản được quy định trong RFC 3261 với cấu trúc gồm một dòng bắt đầu (start - line), một số trường header (tiêu đề) và và một phần thân bản tin tùy chọn. Bản tin SIP có khuôn dạng như sau: Hình 2.3.1 Khuôn dạng bản tin SIP Cấu trúc này được tóm tắt như sau: Bản tin dạng tổng quát = dòng bắt đầu *header bản tin CRLF [thân bản tin] Trong đó: Dòng bắt đầu = Dòng yêu cầu/Dòng trạng thái header bản tin = header yêu cầu/header đáp ứng 2.3.2 Các bản tin yêu cầu Các bản tin SIP được phân biệt với nhau dựa vào dòng tiêu đề (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. Dòng này chứa tên phương thức (Method), Request–URI, và phiên bản giao thức. Các thành phần được ngăn cách bằng một kí tự trống (SP: space). Khuôn dạng bản tin yêu cầu: Bản tin yêu cầu = Dòng yêu cầu *header yêu cầu CRLF [ thân bản tin ] Trong đó: Dòng yêu cầu = Method SP Request-URI SP SIP-Version CRLF Bảng phân loại các bản tin yêu cầu: Bản tin Ý nghĩa INVITE khởi tạo một phiên ( bắt đầu thiết lập cuộc gọi bằng cách gửi bản tin mời đầu cuối khác tham gia) ACK bản tin này khẳng định máy trạm đã nhận được bản tin trả lời bản tin INVITE BYE Yêu cầu kết thúc phiên CANCEL Huỷ yêu cầu đang nằm trong hàng đợi REGISTER đầu cuối SIP sử dụng bản tin này để đăng ký với máy chủ đăng ký OPTIONS sử dụng để xác định năng lực của máy chủ INFO sử dụng để tải các thông tin như âm báo DTMF 2.3.2.1 Method (Chỉ thị) SIP định nghĩa 6 chỉ thị chính đó là: REGISTER, INVITE, ACK, CANCEL, OPTIONS. REGISTER để đăng kí thông tin liên lạc, INVITE, ACK và CANCEL để thiết lập phiên, BYE để kết thúc phiên, và OPTION để đòi hỏi về khả năng của SIP Server. i.INVITE Chỉ thị INVITE được dùng để thiết lập phiên phương tiện giữa các UA. Trả lời INVITE luôn luôn được thông báo với chỉ thị ACK. Một bản tin INVITE thường có phần thân bản tin chứa thông tin của người gọi. Thân bản tin cũng có thể chứa các thông phiên khác như là QoS hoặc là thông tin bảo mật. Nếu INVITE không chứa thông tin phương tiện UAC, thì ACK chứa thông tin phương tiện của UAC. Nếu thông tin phương tiện trong ACK không được chấp nhận, thì phía bị gọi sẽ gửi bản tin BYE để hủy phiên. CANCEL không được gửi vì phiên đã sẵn sàng để thiết lập. Một phiên phương tiện được xem như là đã thiết lập khi mà các bản tin INVITE, 200 OK, và ACK đã trao đổi giữa UAC và UAS. Bản tin INVITE thành công sẽ thiết lập thoại giữa hai UA, nó kết thúc khi bản tin BYE được gửi bởi một trong hai bên để kết thúc phiên. UAC khởi tạo INVITE để thiết lập thoại tạo ra một Call-ID mà được sử dụng trong suốt quá trình gọi. Số Cseq được gán (không nhất thiết phải là 1, nhưng phải là số nguyên) và nó tăng theo mỗi yêu cầu mới cho cùng Call-ID. Header To và From chứa địa chỉ remote(địa chỉ xa) và local(địa chỉ nội bộ). Nhãn From nằm trong INVITE, và UAS tính đến nhãn To trong bất kỳ đáp ứng nào. Nhãn To trong 200 OK (báo yêu cầu thành công) đáp trả INVITE được sử dụng trong trường header To của ACK, và tất cả các yêu cầu sau trong thoại. Việc kết hợp các nhãn To, From, và Call-ID để nhận dạng cho cho thoại. Hình 2.3.2 Thí dụ đơn giản về thiết lập phiên SIP INVITE được gửi cho một cho một đoạn thoại đang tồn tại với cùng Call-ID giống như INVITE ban đầu và chứa cùng cùng nhãn To và From. Đôi khi được gọi là re-INVITE, yêu cầu để thay đổi các đặc tính hoặc “refresh” (làm mới) trạng thái của thoại. CSeq điều khiển chuỗi số được tăng do đó UAS có thể phân biệt re-INVITE của INVITE gốc. Nếu re-INVITE bị từ chối hoặc xảy ra bất kỳ lỗi nào, phiên tiếp tục như thể re-INVITE chưa từng được gửi. Một re-INVITE không được gửi bởi UAC cho tới khi đáp ứng kết thúc cho INVITE ban đầu được nhận. Ngoài ra còn có trường hợp khi mà 2 UA đồng thời gửi re-INVITE cho nhau. Nó có thể được xử lý bằng cách gửi header Retry-After. Trường hợp này được gọi là xung đột trong thoại, và xảy ra khi mà cả hai đầu cuối của cùng nhóm trung kế bắt tín hiệu của cùng trung kế tại cùng thời điểm. Header Expires trong INVITE cho UAS biết yêu cầu của cuộc gọi tồn tại trong bao lâu. Thí dụ, UAS có thể loại bỏ và không đáp trả yêu cầu INVITE được hiển thị trong suốt quá trình chỉ định trong header Expires. Một phiên được thiết lập, header Expires không có ý nghĩa, header này chỉ có ý nghĩa trong quá trình thiết lập phiên. Các trường header bắt buộc phải có trong một yêu cầu INVITE đó là: Call-ID, CSeq, From, To, Via, Contact, Max-Forwards. Thêm vào đó, yêu cầu này chứa thêm header Subject tùy chọn. ii.ACK Chỉ thị ACK được sử dụng để báo nhận đáp ứng kết thúc cho yêu cầu INVITE. Nó không được dùng để thông báo cho các yêu cầu khác. Đáp ứng kết thúc được xác định như là 2xx, 3xx, 4xx, 5xx, 6xx. Một ACK có thể chứa thân bản tin có kiểu application/sdp. Điều này được phép nếu như yêu cầu INVITE ban đầu không chứa thân bản tin SDP. Nếu như INVITE đã chứa thân bản tin, ACK có thể không chứa thân bản tin. ACK có thể không được sử dụng để thay đổi sự mô tả phương tiện mà đã được gửi trong INVITE ban đầu; bản tin re-INVITE sẽ được sử dụng trong trường hợp này. SDP trong ACK được sử dụng trong một số kịch bản phối hợp với các giao thức khác, trong trường hợp mà các đặc điểm phương tiện có thể không được biết khi mà INVITE ban đầu được khởi tạo và gửi. Với đáp ứng 2xx, ACK là “toàn trình” (end-to-end), nhưng đối với tất cả các đáp ứng kết thúc khác, nó được thực hiện theo kiểu “nhảy bước” (hop-by-hop) khi có mặt stateful proxy. Đặc tính end-to-end của ACK với đáp ứng 2xx cho phép thân bản tin được truyền. Một ACK khởi tạo trong báo nhận kiểu hop-by-hop sẽ chỉ chứa một header Via với địa chỉ của proxy server mà làm phát sinh ACK. Sự khác nhau giữa báo nhận hop-by-hop với đáp ứng báo nhận end-to-end được minh họa trong hình 2.3.3. Một stateful proxy nhận bản tin ACK phải xác định ACK sẽ được chuyển hay không trên luồng về tới proxy hay UA khác hay không. Có nghĩa là: ACK theo kiểu hop-by-hop hay end-to-end. Điều này được thực hiện bằng cách so sánh branch ID(số nhận dạng nhánh) với một branch ID chờ xử lý. Nếu kết quả là không chính xác, ACK được ủy quyền chuyển tới UAS. ACK trong bước này không được proxy chuyển tiếp. Các trường header bắt buộc trong yêu cầu ACK là: Call-ID, CSeq, From, To, Via, Max-Forwards. iii.BYE Chỉ thị BYE được sử dụng để kết thúc một phiên truyền thông đã được thiết lập. Một phiên được coi là đã được thiết lập, khi mà một INVITE đã nhận đáp ứng báo thành công (2xx) hoặc một ACK đã được gửi. Chỉ thị BYE chỉ được gửi bởi các UA đang tham gia trong phiên, proxy hoặc là các thành viên thứ 3 khác không được phép gửi. Một UA sẽ gửi trả với đáp ứng 481 (Dialog/Transaction Does Not Exist: thoại/giao dịch không tồn tại) cho yêu cầu BYE mà nó không biết đến trong đoạn thoại. Các trường header bắt buộc trong yêu cầu BYE là: Call-ID, CSeq, From, To, Via, Max-Forwards. Hình 2.3.3 Minh họa bản tin end-to-end và hop-by-hop iv. REGISTER Chỉ thị REGISTER được UA dùng để đăng kí danh sách địa chỉ của người dùng trong trường tiêu đề To tới SIP server (registrar). Như vậy chỉ thị REGISTER này dùng để đăng kí thông tin người dùng Chỉ thị REGISTER được sử dụng bởi một UA để thông báo cho mạng của nó là nó chứa Contact URI (địa chỉ IP) và URI này có thể để các yêu cầu tìm tuyến đường cho Contact này. Tùy thuộc vào header Contact và Expires của yêu cầu REGISTER, mà registrar server có những đáp ứng khác nhau. Nếu không có thông số expires, SIP URI sẽ kết thúc sau 1 giờ. Nếu có thông số expires, nó sẽ thiết lập thời gian kết thúc cho Contact. SIP URI nào cũng bị giới hạn về thời gian kết thúc. CSeq được tăng cho yêu cầu REGISTER. Việc sử dụng các header Request-URI, To, From, và Call-ID trong yêu cầu REGISTER không khác là mấy so với các yêu cầu khác. Request-URI chỉ chứa tên miền của registrar server. Yêu cầu REGISTER có thể được chuyển tiếp hoặc ủy quyền cho tới khi nó tới registrar server trao quyền với tên miền được khai báo. Header To chứa SIP URI của bản ghi của UA mà đang được đăng kí. From chứa SIP URI của người gửi yêu cầu. Nó yêu cầu cùng Call-ID cho mọi hoạt động đăng kí được sử dụng bởi cùng một UA. Một UA gửi yêu cầu REGISTER có thể nhận đáp ứng 3xx (chuyển tiếp yêu cầu) hoặc là 4xx (lỗi yêu cầu). Request Header Hoạt động của Registrar Contact: * Expires:0 Hủy tất cả những đăng kí Contact: sip:galvani@bologna.edu.it Expires: 30 Thêm Contact vào những đăng kí hiện tại; đăng kí kết thúc sau 30 phút. Contact: sip:galvani@bologna.edu.it Expires: 45 Contact: sip:l.galvani@bologna.it Expires: 30 Thêm vào Contact để đăng kí theo thứ tự ưu tiên được ghi vào; địa chỉ đầu tiên nó kết thúc sau 45 phút, địa chỉ sau đó là kết thúc sau 30 phút. Không chứa header Contact Trả lại tất cả những đăng kí trong đáp ứng. Bảng 2.3.4 Kiểu hoạt động của registrar và header Contact v. CANCEL Chỉ thị CANCEL được sử dụng để hủy bỏ một yêu cầu được thực hiện với cùng giá trị trong các trường Call-ID, From, To và CSeq của yêu cầu đó. CANCEL là yêu cầu theo kiểu “nhảy bước”(hop-by-hop). CSeq không tăng đối với chỉ thị này do đó các proxy và UA có thể gán cho CSeq của CANCEL với CSeq của INVITE mà đang chờ xử lý một cách tương ứng. Số nhận dạng nhánh Branch ID của CANCEL được gắn với giá trị Branch ID của INVITE mà đang hủy. CANCEL chỉ dành cho INVITE, khi mà INVITE diễn ra quá lâu để hoàn thành. UA xác nhận việc hủy bỏ bằng đáp ứng 200 OK. Khi mà yêu cầu theo kiểu hop-by-hop, CANCEL có thể không chứa thân bản tin. Các trường header bắt buộc trong CANCEL là: Call-ID, CSeq, From, To, Via, Max-Forwards. vi. OPTIONS Chỉ thị OPTIONS dùng để đòi hỏi về khả năng của SIP Server. Nếu một Server có khả năng liên lạc với user có thể đáp lại yêu cầu OPTIONS bằng một tập hợp các khả năng của nó. Chỉ thị này được đưa ra bởi SIP Proxy, Redirect Server, Registrar, Client. 2.3.2.2 Request-URI Request-URI là SIP hoặc là SIPS URI hoặc là một URI tổng quát. Nó xác định người dùng và dịch vụ trong những yêu cầu được đánh địa chỉ. Các phần tử SIP có thể cấp Request-URI với giản đồ “sip” và “sips”. 2.3.2.3 SIP Version Cả bản tin yêu cầu và đáp ứng đều chứa phiên bản SIP được sử dụng. Hiện nay, có hai phiên bản SIP được kí hiệu là SIP và SIP/2.0. 2.3.2.4 Thân bản tin SIP Thân bản tin SIP chứa rất nhiều kiểu thông tin khác nhau. Chúng có thể chứa thông tin SDP, mà được sử dụng để truyền đạt thông tin phương tiện hoặc là QoS, thậm chí cả thông tin bảo mật. Header Content-Disposition được sử dụng để chỉ thị kiểu thân bản tin. Nếu như không có mặt header này thì phần thân bản tin sẽ giả định là phiên phương tiện. Định dạng của thân bản tin được chỉ thị bởi header Content-Type. Nếu 1 bản tin có chứa thân bản tin, thì bản tin phải bao gồm header Content-Type. Tất cả các UA phải hỗ trợ Content-Type là application/sdp. Kỹ thuật mã hóa của phần thân bản tin được chỉ thị trong header Content-Encoding. Nếu không khai báo thì nó sẽ được giả định là text/plain (dạng hiển thị văn bản). Header Content-Length chứa số byte của thân bản tin. Nếu 1 bản tin mà ko có phần thân, thì Content-Length sẽ có giá trị là 0. Do bản tin SIP đa điểm có thể gửi theo luồng TCP, dựa vào số Content-Length để phát hiện một bản tin là kết thúc hoặc là bắt đầu. Nếu Content-Length ko có giá trị, thì UAC phải giả thiết rằng thân bản tin vẫn được duy trì cho tới khi kết thúc dữ liệu UDP, hoặc là kết nối TCP được đóng lại, điều này phụ thuộc vào giao thức truyền tải. Thân bản tin có thể có nhiều phần nếu như chúng được mã hóa, sử dụng MIME (Multi-part Internet Mail Extensions). Có nghĩa là có thể hoạt động với nhiều thân bản tin, header Content-Type được ghi là multipart/mime. Tuy nhiên, thân bản tin SIP phải không được vượt quá UDP MTU (khối truyền UDP tối đa) của mạng. Proxy có thể từ chối nếu thân bản tin lớn bằng đáp ứng 413 Request Entity Too Large (thực thể yêu cầu quá lớn), khi mà việc xử lý bản tin lớn khiến cho server không thể tải được. 2.3.3 Nhãn tag Nhãn tag là số ngẫu nhiên nhỏ hơn 232, nó được thêm vào trong header To và From để xác định tính duy nhất của đoạn thoại. Header To trong INVITE ban đầu không chứa tag. Theo RFC 3261, người gọi đưa ra nhãn tag trong header From (còn theo RFC 2543 thì một UA thông thường thì không hoạt động như vậy, nó là phần tùy chọn). Việc gửi và nhận một đáp ứng chứa tag trong header From được tạo ngay cho đoạn thoại sau. Một nhãn tag không bao giờ được sao chép thông qua cuộc gọi. Bất kỳ đáp ứng nào khởi tạo bởi proxy sẽ được proxy thêm vào một nhãn tag. Bản tin ACK khởi tạo bởi hoặc là UA hoặc là proxy sẽ luôn luôn sao chép nhãn tag của header From của đáp ứng vào trong yêu cầu ACK. Nếu UAC nhận đáp ứng chứa những nhãn tag khác, điều đó có nghĩa là đáp ứng từ các UAS khác, và do đó yêu cầu INVITE đã bị rẽ nhánh. Điều này phụ thuộc UAC xử lý trường hợp này như thế nào. Thí dụ, UAC có thể thiết lập các phiên riêng với mỗi đáp ứng của UAS. Đoạn thoại này chứa header From, Call-ID, và CSeq giống nhau, nhưng nhãn tag trong header To sẽ khác nhau. Chú ý là nhãn tag là một phần của header và nó luôn được đặt ngoài dấu “”. 2.3.4 Bản tin đáp ứng 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 (bản tin yêu cầu là dòng yêu cầu). Dòng trạng thái của bản tin đáp ứng bao gồm tên phiên bản giao thức SIP (SIP - Version), mã dòng trạng thái (Status - Code) và cụm văn bản giải thích ý nghĩa Status - Code. Mỗi phần của bản tin cũng được tách 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. Khuôn dạng bản tin như sau: Bản tin đáp ứng = Dòng trạng thái *header bản tin CRLF [ thân bản tin ] Trong đó: Dòng trạng thái = SIP – Version SP Mã trạng thái SP Reason – Phrase CRLF Reason-Phrase (cụm chú thích): là cụm từ chú thích cho bản tin đáp ứng. Mã trạng thái là một mã kết quả, là một số nguyên gồm 3 chữ số chỉ thị kết quả của việc cố gắng hiểu và đáp ứng yêu cầu. Chữ số đầu tiên dùng để phân loại đáp ứng, hai chữ số sau không có vai trò phân loại. Bản SIP/2.0 phân loại 6 lớp đáp ứng như sau: Bản tin Ý nghĩa 1xx: Information Các bản tin chung 2xx: Success Thành công 3xx: Redirect Chuyển địa chỉ 4xx: Client – Error Yêu cầu không được đáp ứng 5xx: Sever – Error Sự cố của máy chủ 6xx: Global – Failure Sự cố toàn mạng 2.3.5 Bảng tổng hợp các bản tin trả lời của SIP 1xx – các bản tin chung - 100 Đang thử -180 Đang đở chuông -181 Cuộc gọi đang được chuyển hướng -182 Đang xếp hàng đợi - 183 Phiên đang tiến hành 2xx – thành công - 200 OK - 202 được chấp nhận: dùng để tham chiếu 3xx - chuyển địa chỉ - 300 Có nhiều lựa chọn - 301 Đã dời đi vĩnh viễn - 302 Đã tạm thời dời đi - 305 Dùng Proxy - 380 Dịch vụ thay thế 4xx – yêu cầu không được đáp ứng - 400 Yêu cầu sai - 401 Không được quyền: Chỉ sử dụng bởi cơ quan đăng kiểm. Các proxy phải sử dụng yêu cầu cấp phép cho proxy 407 - 402 Yêu cầu trả tiền (Dự trữ để dùng trong tương lai) - 403 Cấm - 404 Không tìm thấy: Không tìm thấy người dùng - 405 Phương thức không được phép - 406 Không được chấp nhận - 407 Cần có sự cấp phép cho proxy - 408 Yêu cầu bị hết giờ: không tìm thấy người dùng trong thời gian cho phép - 410 Đã không còn: Người dùng đã từng tồn tại, nhưng không còn ở đây nữa. - 413 Đơn vị yêu cầu quá lớn - 414 URI của yêu cầu quá dài - 415 Kiểu phương tiện không được hỗ trợ - 416 Giản đồ URI không được hỗ trợ - 420 Phần mở rộng không đúng: sử dụng phần mở rộng củ