Tài liệu Giao thức sip trong voip (session initiation protocol giao thức báo hiệu điều khiển

EBOOKBKMT.COM BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP. HCM ĐỀ ÁN CƠ SỞ NGÀNH MẠNG MÁY TÍNH GIAO THỨC SIP TRONG VOIP ( SESSION INITIATION PROTOCOL : GIAO THỨC BÁO HIỆU ĐIỀU KHIỂN) Giáo viên hướng dẫn : Ths.Nguyễn Đức Quang Người thực hiện : Lê Võ Hồng Thanh MSSV : 1081020097 TP. Hồ Chí Minh, 2011 1 EBOOKBKMT.COM MỤC LỤC Lời Mở Đầu I . Tổng quan về giao thức SIP 1. Tổng quan về RFC 2. Tổng quan về giao thức SIP 3. Nguồn gốc sự phát triển của SIP II. Các thành phần bên trong mạng SIP 1. SIP User Agent 2. SIP Server 3. Mối liên hệ giữa các thành phần trong mạng SIP 4. Bản tin SIP 4.1 SIP Response 4.2 SIP Request 4.3 Các trường Header 4.4 Message Body 4.5 Cấu trúc bản tin SIP 5. Chức năng của SIP 5.1 Thiết lập,sửa đổi và kết thúc phiên 5.2 Tính di động của người sử dụng 6. Thiết lập và hủy cuộc gọi SIP III. Các giao thức hỗ trợ trong SIP 1. RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên mạng. 2. RTP ( Real Time Tranpsport Protocol ) : Giao thức vận chuyển thời gian thực 3. RTCP (Real-Time Transport Control Protocol)odd port-port lẻ 2 EBOOKBKMT.COM 4. RTSP ( Real Time Streaming Protocol ) : Giao thức tạo luồng thời gian thực . 5. SDP ( Session Description Protocol ) : Giao thức mô tả phiên kết nối đa phương tiện 6. MIME ( Multipurpose Internet mail Extension – Mở rộng thư tín Internet đa mục đích 7. HTTP ( Hypertext Transfer protocol ) : Giao thức truyền siêu văn bản IV. Kết luận V . Demo 1. Mục tiêu và mô hình 2. Công cụ Demo 3. Các bước 4. Kết quả 3 EBOOKBKMT.COM LỜI CẢM ƠN Trước hết em xin gửi tới thầy giáo Ths. Nguyễn Đức Quang , lời cảm ơn chân thành và sâu sắc đã trực tiếp hướng dẫn , chỉ bảo tận tình trong suốt quá trình em làm đề án này. LỜI MỞ ĐẦU Trước đây khi đề cập đến VoIP, tiêu chuẩn quốc tế thường đề cập đến là H.323. Giao thức H.323 là chuẩn do ITU-T phát triển cho phép truyền thông đa phương tiện qua các hệ thống dựa trên mạng chuyển mạch gói, tập giao thức H.323 bao gồm rất nhiều giao thức con bên trong nó như H.245, H225, Q.931… hoạt động dựa trên H.323 là rất chặt chẽ và phức tạp. Những năm trở lại đây thì giao thức SIP lại chiếm ưu thế và dần dần thay thế H.323. I. TỔNG QUAN VỀ GIAO THỨC SIP : 1. Tổng quan về RFC : Trong kỹ thuật mạng máy tính, các tài liệu RFC (Request For Comments - RFC) là 1 loạt các bản ghi nhớ chứa những nghiên cứu mới, những phương pháp luận ứng dụng cho công nghệ internet. Thông qua Hội đồng Internet (Internet Society) các kỹ sư và các nhà khoa học máy tính có thể công bố luận văn dưới hình thức là một bản ghi nhớ RFC để cho những đồng nghiệp khác phê bình hoặc chỉ đơn thuần là để thông báo những tin tức hoặc quan điểm mới về mặt kỹ thuật. Tổ chức chuyên trách kỹ thuật liên mạng (IETF – Internet Engineering Task Force) chấp nhận những lý thuyết đã được công bố trong các RFC và đã được ứng dụng thực tế như là những tiêu chuẩn cho Internet. Mỗi một bản RFC chỉ có duy nhất một số đăng ký,một khi số đăng ký đã được công bố thì nó sẽ không bao giờ được sữa chữa hay bị hủy bỏ. Nếu cần được chỉnh sửa thì tác giả của nó sẽ công bố các bản chỉnh sữa vì vậy các bản RFC bị lỗi thời bởi những bản mới 4 EBOOKBKMT.COM hơn của chính nó. Hàng loạt các RFC đã đăng ký hình thành nên lịch sử tiến triển của tiêu chuẩn Internet . Tiến trình kiến tạo RFC không giống với những tiến trình tiêu chuẩn hóa do những tổ chức chính quy về tiêu chuẩn như ANSI thường làm. Những chuyêng gia về kỹ thuật mạng và truyền thông có thể tự đề bạt một bản dự thảo Internet (Internet Draft) mà không cần sự hỗ trợ từ những cơ quan bên ngoài. Những bản RFC được công nhận thường được công bố với sự phê chuẩn của IETF và đa số là do những chuyên gia tham dự trong các nhóm điều hành của IETF thi hành. Khi mới bắt đầu chúng chỉ là những bản dự thảo Internet, cách xắp xếp này cho phép những bản dự thảo này được thông qua những vòng thăm dò ý kiến ban đầu từ những đồng nghiệp trước khi tài liệu được hoàn thành và thanh lọc để trở thành những bản RFC. Truyền thống của RFC là dựa vào tính thực dụng, kinh nghjệm từng trải, quyền tiêu chuẩn hóa những bản thảo thông qua thực tế đạt được bởi các cá nhân hoặc một nhóm cộng tác nhỏ. Điều này có ưu điểm đó là hơn rất nhiều so với quy trình chính quy do hội đồng điều khiển mà chúng ta thường thấy ở ANSI hoặc ISO. Các bản RFC đã từng nổi tiếng vì chất lượng của chúng. Trong các bản RFC chúng ta vừa không gặp những sự nhập nhằng,khó hiểu là một vấn đề phổ biến trong các bản thiết kế dự thảo, vừa không có những chức năng ngoài dự kiến do sai lầm của hội đồng gây ra đó là những điều ám ảnh đối với các tiêu chuẩn chính quy. Và chúng đang mở đường cho một mạng lưới đang phát triển tới tầm cỡ toàn cầu. Hình thức RFC được khởi đầu vào năm 1969, khi nó là một phần trong hội thảo của dự án ARPANET. Hiện nay, nó là kênh công bố chính thức của IETF, của Ủy Ban Kiến Trúc Mạng ( Internet Architecture Board – IAB) và ở mức độ nào đó là của cộng đồng những kỹ sư nghiên cứu về mạng lưới truyền thông máy tính toàn cầu. Những bản RFC đầu tiên được tác giả của chúng đánh bằng máy đánh chữ và truyền tay các bản in giữa nhóm những kỹ sư nghiên cứu tại ARPA. Tháng 12 năm 1969, các kỹ sư nghiên cứu phân phát các bản RFC mới thông qua mạng lưới truyền thông ARPANET. Bản RFC đầu tiên với đề tài Phần Mềm Dành Cho Máy Chủ (Host Software), được Steve 5 EBOOKBKMT.COM Crocker, một sinh viên của trường đại học California, Los Angeles ( UCLA) viết và được công bố vào ngày 07 tháng 04 năm 1969. Trong phiên bản RFC số 3, Steve Crocker đã đặt các bản RFC dưới quyền của “Nhóm Điều Hành Mạng – Network Working Group“, nhóm này chưa bao giờ tồn tại chính thức mà chỉ được định nghĩa là “nhóm người này” nhưng sự ủy quyền của “họ” vẫn tồn tại trong các RFC cho đến nay. Trường đại học UCLA tiếp tục cho ra đời nhiều bản RFC trong những năm 1970 không những vì chất lượng của chúng cao mà còn vì UCLA là một trong những điểm kết nối mạng đầu tiên của ARPANET. Từ năm 1969 đến 1998, ông Jon Postel làm chủ biên tập RFC. Sau khi hết hạn hợp đồng tài trợ của chính phủ Mỹ, hội đồng Internet (thay mặt cho IETF) ký hợp đồng với chi nhánh điều hành mạng (Networking Division) của trường đại học Nam California (USC) đứng ra làm quyền biên tập và chịu trách nhiệm về việc xuất bản. Mọi người đều có thể tiếp cận bất kỳ một bản RFC nào tại website chính thức của chủ biên RFC : http://www.rfc-editor.org/rfc.html . Hầu hết các bản RFC đều hiện hiện hữu ở dạng ASCII, đồng thời cũng có ở một số định dạng khác. Từ năm 2006 trở đi bất kỳ một đặc tả tiêu chuẩn internet nào cũng đều ở dưới dạng ASCII. Không phải bất kỳ bản RFC nào cũng là tiêu chuẩn, chỉ có nhóm IETF đại diện cho nhóm chỉ đạo kỹ thuật kết nối mạng ( Internet Engineering Stearing Group – IESG) là có quyền chuẩn y các bản RFC có thể trở thành tiêu chuẩn. Cấp bậc của các RFC bao gồm : Đề nghị (Proposed – PS), dự thảo (Draft – DS), bảng đầy đủ (Full) – Tiêu chuẩn Internet (Internet Standart – STD). Mỗi một biên tập phụ, thuộc một tiêu chuẩn STD nào đó đều có một mã số riêng. Kể từ năm 2006 thì tiêu chuẩn số 1 là RFC3700. Một số các STD tạo thành nhiều nhóm nhỏ, gồm những RFC có liên quan với nhau. Một bản RFC thử nghiệm có thể là một tài liệu của IETF, hoặc một bản đệ trình cá nhân lên chủ biên RFC. Trên lý thuyết, thực trạng các bản tài liệu như cái tên của nó ám chỉ - chỉ là những “ đề nghị duyệt thảo và bình luận “ ( Request For Comments ). Trên thực tế ,một số bản tài liệu không được nâng lên mức tiêu chuẩn vì không có người tình nguyện thực hành những chi tiết cụ thể trong thủ tục. Một số tài liệu quan trọng cũng chỉ tồn tại như một “Bản Thảo Internet”, trong khi có những bản RFC chính quy lại trở nên lỗi thời . 6 EBOOKBKMT.COM Một bản RFC tin tức (news) có thể là bất cứ thứ gì, từ những bản RFC hài hước ( những bản này được công bố vào ngày 1-4 – Ngày nói đùa ) về những giao thức sở hữu cho đến những bản RFC chủ chốt được nhiều người biết đến như RFC 1591. Một số bản RFC tin tức được nhóm lại thành một loạt các bài “ tin tức đáng chú ý” (For Your Information – FYI). Tuy nhiên hiện nay ít ai đăng thêm, một số FYI cũ vẫn còn rất thú vị như FYI 18 hay còn gọi là RFC 1983 bản “ từ vựng dành cho người dùng Internet” (Internet User’s Glossary) Một bản RFC tồn kho (historic) là một bản lỗi thời và đã có bản RFC khác thay thế nó. Những bản này nói về một giao thức đã không còn được để ý trong hoàn cảnh Internet hiện tại hoặc đã bị đưa ra khỏi mức tiêu chuẩn hóa vì một lý do nào đó. Một số các RFC lỗi thời còn không được liệt kê trong danh sách các bản tồn kho, vì “ tiến trình tiêu chuẩn hóa “ (Internet Standards Process) thường không cho phép những tham chiếu có tính quy chuẩn (normative references) đối với một RFC đang được tiêu chuẩn hóa, từ một bản RFC có cấp độ thấp hơn. Đồng thời ít người chú ý đến việc giải quyết những chi tiết thủ tục yêu cầu, để những bản RFC được phân loại là tồn kho, và những thay đổi được đánh dấu vào tất cả các RFC phụ thuộc vào nó. Dạng vô danh thường được đặt cho những bản RFC quá cũ không rõ cấp bậc là gì nếu phải công bố. Trong một vài trường hợp những RFC đó còn hoàn toàn không được công bố. Những RFC cũ thường chỉ là những bản “ yêu cầu duyệt thảo và bình luận “, không chú trọng việc đặc tả một giao thức, một chu trình quản lý hoặc bất cứ một thứ gì khác mà các RFC hiện nay đang được dùng để thực hiện. 2. Tổng quan về SIP : Giao thức SIP (Secssion Initiation Protocol ) 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ó một hoặc nhiều người tham gia . 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 hỗ trợ các phiên đơn bá ( unicast ) và quảng bá ( multicast ) tương ứng các cuộc gọi điểm tới điểm và cuộc gọi đa điểm . SIP là một giao thức để thiết lập các phiên truyền thông . Các phiên SIP bao gồm  Hội họp đa phương tiện qua internet . 7 EBOOKBKMT.COM  Các cuộc gọi điện thoại qua internet .  Các phiên video qua internet .  Phân phối đa phuong tiên . Các phần tử của SIP có thể liên lạc thông qua :  Liên lạc cá nhân .  Phát quảng bá .  Thông qua tổ hợp của các quan hệ liên lạc cá nhân hoặc một tổ hợp của tất cả những phương tiên trên . Trong các môi trường IPv4 và IPv6 thông qua :  UDP  TCP  SCTP hoặc TLS trên nền TCP SIP là một giao thức mở rộng đơn giản  Các phương tiên ( Methods ) – Định nghĩa về phiên truyền thông .  Phần mào đầu ( Headers ) – Mô tả về phiên truyền thông .  Phần thông tin báo hay còn gọi là phần thân ( Message Body ) – SDP , ký tự , XML . 3. Nguồn gốc sự phát triển của giao thức SIP : Đầu tiên SIP chỉ đơn thuần là một giao thức dùng để thiết lập phiên quảng bá cho Internet ( từ giữa đến cuối thập kỉ 90 ) . SIP được phát triển bởi SIP Working Group trong IETF. Phiên bản đầu tiên được ban hành vào tháng 3 năm 1999 trong tài liệu RFC 2543 : nó là 1 giao thức dựa trên ý tưởng và cấu trúc của HTTP (HyperText Transfer Protocol) là giao thức trao đổi thông tin của World Wide Web (WWW) và là 1 phần trong kiến trúc Multimedia của IETF. Sau đó, SIP trải qua nhiều thay đổi và cải tiến. Phiên bản mới nhất hiện nay được ban hành trong IETF RFC 3261. RFC 3261 hoàn toàn tương thích ngược 8 EBOOKBKMT.COM với RFC 2543, do đó các hệ thống thực thi theo RFC 2543 hoàn toàn có thể sử dụng với các hệ thống theo RFC 3261. Các giao thức có liên quan đến SIP bao gồm : - Giao thức đặt trước tài nguyên RSVP ( Resource Reservation Protocol ) - Giao thức truyền vận thời gian thực RTTP ( Real Time Transfer Protocol ) - Giao thức cảnh báo phiên SAP ( Session Announcement Protocol ) - Giao thức miêu tả phiên SDP ( Session Description Protocol ) Các chức năng của SIP là độc lập và không phụ thuộc vào bất kỳ giao thức nào thuộc các giao thức trên. Mặt khác SIP có thể hoạt động hỗ trợ 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ể mở rộng thêm các chức năng mới. Sự linh hoạt của 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. Một bản tin SIP có hai phần, phần mào đầu ( Headers ) và phần thân ( Message Body ). Phần thân cho phép phục vụ các ứng dụng khác nhau một cách linh hoạt. Ban đầu phần thân chỉ dùng để chuyển tải các tham số miêu tả phiên SDP như codec, địa chỉ IP đầu cuối, ... Phần thân được sử dụng để mở rộng các ứng dụng của khác nhau của SIP ví dụ như SIP-T cho liên vận PSTN-SIP-PSTN hoặc MSCML (Media Server Control Markup Language) cho dịch vụ hội nghị. Sự phổ cập của SIP đã dẫn tới việc một loạt nhóm làm việc liên quan đến SIP được thành lập. Nhóm SIPPING ( Session Initiation Protocol Project Investigation working group) được thành lập với mục đích nghiên cứu các ứng dụng và phát triển các yêu cầu mở rộng cho SIP. Nhóm SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) có nhiệm vụ chuẩn hoá các giao thức cho các ứng dụng nhắn tin tức thời. Các nhóm làm việc khác là PINT (PSTN and Internet Inter-networking), SPIRITS (PSTN/IN requesting Internet Services). II. Các thành phần bên trong mạng SIP : 9 EBOOKBKMT.COM Thành phần của SIP : bao gồm SIP User Agent ( UA ) và SIP server . 1. SIP User Agent: SIP UA hoặc thiết bị đầu cuối là điểm cuối của dialog : SIP UA gửi - nhận các yêu cầu và trả lời của SIP , nó là điểm cuối của luồng đa phương – bao gồm ứng dụng trong thiết bị đầu cuối hoặc ứng dụng phần cứng chuyên dụng . UA gồm hai phần :  User Agent Client ( UAC ) : ứng dụng của người gọi – khởi tạo yêu cầu (request )  User Agent Server ( UAS ) : chấp nhận , gửi lại , từ chối yêu cầu ( request ) và gửi trả lời cho request đến thay mặt cho người gọi. UA là thực thể SIP mà tương tác với người sử dụng bằng giao diện. 2. SIP Server : SIP server : Cần phân biệt SIP Server và UA server cũng như mô hình client-server . Ở đây , SIP server là một thực thể luận lý , một SIP server có thể có chức năng của nhiều loại server hay nói cách khác một SIP Server có thể hoạt động như các server khác nhau trong các trường hợp khác nhau . Trong SIP Server có các thành phần quan trọng như : Proxy Server , Redirect Server , Location Server , Registrar Server …  Proxy Sever : 10 EBOOKBKMT.COM Có thể xem các Proxy Server như các router thiết bị đầu cuối SIP làm nhiệm vụ chuyển tiếp các 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. Tuy nhiên các Proxy SIP sử dụng nguyên tắc định tuyến phức tạp hơn là chỉ tự động chuyển tiếp bản tin dựa vào bảng định tuyến. Các Proxy Server cũng cung cấp các chức năng khác như : xác định tính hợp lệ của bản tin, xác thực người sử dụng, phân nhánh các request, phân giải địa chỉ, hủy bỏ các cuộc gọi đang chờ. Một Proxy có thể lưu (stateful) hoặc không lưu trạng thái (stateless) của bản tin trước đó, thông thường thì Proxy có lưu trạng thái và chúng duy trì trạng thái đó trong suốt Transaction (khoảng 32 giây). Sự linh hoạt của các proxy SIP cho phép các nhà khai thác và quản trị mạng sử dụng các proxy cho các mục đích khác nhau và trong các vị trí khác nhau trong mạng (chẳng hạn như Proxy biên, Proxy lõi, và Proxy của các doanh nghiệp).  Redirect Server : Truy nhập dữ liệu và dịch vụ định vị để tìm địa chỉ của user và gửi trả về bản tin lớp 300 để thông báo thiết bị là 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ề .  Registrar Sever : Là sever nhận bản tin SIP REGISTER yêu cầu và cập nhật thông tin từ bản tin request vào “ location database “ nằm trong Location Sever .  Location Sever : Lưu thông tin trạng thái hiện tại của người dùng trong mạng SIP . 11 EBOOKBKMT.COM 3. Mối liên hệ giữa các thành phần trong mạng SIP Trong ví dụ thứ nhất, cho ta có một cái nhìn khái quát về chức năng của Proxy Server, Redirect Server, SIP Phone trong mạng. Giả sử thuê bao có tên user1 trong miền dịch vụ do here.com muốn thực hiện một cuộc gọi thoại tới thuê bao có thể là user2 ( thuộc there.com) 12 EBOOKBKMT.COM Chức năng của Proxy, Redirect Server trong mạng SIP 1. Khi User 1 muốn gọi tới User 2, trước hết nó sẽ gửi bản tin INVITE 1 đến Proxy Server 1. Proxy Server 1 chuyển tiếp bản tin tới Redirect Server. 2. Redirect Server này xử lý và trả về mã 3xx thông báo cho Proxy Server tự thực hiện kết nối. 3. Proxy Server 1 gửi bản tin INVITE 2 tới đích trả về bởi Redirect Server ( chính là Stateless Proxy Server 1). Vì đây là Stateful Proxy nên thực chất bản tin INVITE được gửi bởi Stateful Proxy là khác so với bản tin nhận được từ User1(ban đầu). 4. Stateless Proxy Server chuyển tiếp bản tin INVITE tới SIP Statefull Proxy 2. Do là Stateless Proxy nên công việc của nó đơn giản là chuyển tiếp bản tin. 5. SIP Statefull Proxy 2 chuyển tiếp bản tin INVITE tới user2. 6. Khi user2 nhấc máy thì nó sẽ gửi bản tin 200 OK theo chiều ngược lại. 7. Sau khi nhận được bản tin 200 OK, user1 sẽ gửi xác nhận ACK tới user2. 8. Luồng RTP trực tiếp giữa hai thuê bao được thiết lập. Và cuộc gọi được thực hiện. Trong ví dụ thứ hai sẽ mô tả quá trình một SIP Phone đăng kí với với Registrar Server quản lý nó,hoạt động của Location Server, Proxy Server. 13 EBOOKBKMT.COM Chức năng của Location, Registrar Server trong mạng SIP Khi một SIP Phone được kết nối với mạng. Nó liên tục gửi bản tin REGISTER tới Registrar Server để thông báo vị trí hiện tại của nó. Giả sử trong miền dịch vụ có tên chicago.com thì quá trình REGISTER (đăng kí) được tiến hành như sau: 1. Thuê bao có tên Carol gửi bản tin REGISTER tới Registrar Server.Server này tiến hành xác thực. Nếu hợp lệ thì các thông tin đó được lưu trong Location Server. 2. Khi một thuê bao khác (có tên là Bob) gửi bản tin INVITE tới Proxy Server để xin kết nối tới thuê bao Carol. Proxy Server sẽ truy vấn các thông tin về thuê bao bị gọi thông qua Location Server. 3. Proxy Server gửi bản tin INVITE tới thuê bao Carol để thiết lập cuộc gọi. 4. Bản tin SIP Thông điệp SIP gồm 3 phần: start line, header của thông điệp và body. 14 EBOOKBKMT.COM Client gửi yêu cầu (request) và server trả lời bằng response. 1 phiên của SIP bao gồm yêu cầu từ client, 0 hoặc nhiều provisional response và final response từ server. 4.1 SIP response : Status line là dòng bắt đầu của response. Các bản tin đáp ứng được chia thành thành hai nhóm bao gồm 6 loại bản tin, mỗi bản dùng một mã trạng thái nằm trong một dải mã. Khuôn dạng thông điệp SIP SIP version Status code Reason Phrase Cấu trúc Response Line SIP response 15 EBOOKBKMT.COM  Provisional (1xx): Bản tin này dùng để chỉ thị tiến trình nhưng không kết thúc giao dịch SIP (tìm kiếm, rung chuông, xếp hàng).  Final (2xx, 3xx, 4xx, 5xx, 6xx): Bản tin này chỉ thị kết thúc giao dịch SIP. 1xx: Provisional – đã nhận yêu cầu và đang tiếp tục xử lý yêu cầu. Tìm kiếm, rung chuông, xếp hàng đợi, nó được phát khi quá trình xử lý chưa thể kết thúc ngay được. Phía phát cần phải dừng quá trình truyền các yêu cầu khi nhâ ̣n được bản tin này. 2xx: Success – Các yầu đã được xử lý thành công (nhận, hiểu và đã được tiếp nhận). 3xx: Redirection – Cần tiến hành thêm các hoạt động để có thể đáp ứng được các yêu cầu. Chúng được gửi bởi các Redirect Server. 4xx: Client Error – Lỗi do phía Client, các yêu cầu sai cú pháp hoặc không đáp ứng đúng yêu cầu của Server. 5xx: Server Error – Lỗi phía Server, server bị sự cố và không đáp ứng được các yêu cầu hợp lệ. 6xx: Global Failure – Lỗi tổng thể, các yêu cầu không thể được đáp ứng tại bất kỳ server nào. Các lớp Response Mã trả về Mô tả Thông tin 100 Đang thực hiện kết nối 180 Đang đổ chuông 181 Cuộc gọi đang được chuyển tiếp 182 Được đặt vào hàng đợi 183 Phiên đang được xử lý 200 300 301 Thành công Nhiểu lựa chọn Chuyển vĩnh viễn Thành công Chuyển hướng 16 EBOOKBKMT.COM Lỗi Client Lỗi Server 302 305 380 400 401 402 403 404 405 406 407 408 410 413 414 415 416 420 421 423 480 481 482 483 484 485 486 487 488 491 500 501 502 503 Chuyển tạm thời Sử dụng proxy Dịch vụ khác Yêu cầu không hợp lệ Không nhận dạng được Yêu cầu thành toán Bị cấm Không tìm thấy Phướng thức không được phép Không chấp nhận Yêu cầu xác thực Proxy Request timeout Đã dời đi Yêu cầu quá dài URL được yêu cầu quá lớn Không hỗ trợ kiểu media Không hỗ trợ URI Phần mở rộng lỗi Yêu cầu phần mở rộng Khoảng thời gian giữa hai sự kiện quá ngắn Tạm thời chưa sẵn sàng Transaction không tồn tại Phát hiện thấy “loop” (chu trình) Quá nhiều “hop” Địa chỉ không đủ Mật mở không rõ ràng Đang bận Yêu cầu bị hủy Không thể chấp nhận tại đây Yêu cầu chưa được giải quyết Lỗi nội tại trong server Chưa được thực hiện đầu đủ Gateway lỗi Dịch vị không tồn tại 17 EBOOKBKMT.COM 504 505 513 600 603 604 606 Lỗi toàn cục Server timeout Phiên bản SIP không được hỗ trợ Bản tin quá lớn Bận ở khắp mọi nơi Suy sụp Không tồn tại Không thể chấp nhận 4.2 SIP request : Request line là dòng đầu tiên của request. Tên giao thức chỉ ra mục đích của request và request-URI chứa đích của request. Các phương thức SIP Các phương thức SIP có thể xem như là các kiểu thông điệp. Chúng xác định yêu cầu đang được tạo bởi thiết bị của người dùng (hoặc thực thể mạng trong một số trường hợp). Các phương thức SIP cơ bản hiện tại được định nghĩa để sử dụng trong IMS: ACK, BYE, CANCEL, INVITE, REGISTER, UPDATE.. Method Request URI SIP version Cấu trúc Request Line SIP request 4.3 Các trường header Khuôn dạng của các trường header: Tên của trường header: giá trị của trường header Có các trường header bắt buộc và tùy chọn trong mỗi thông điệp. Có 6 trường header có tính bắt buộc trong mỗi SIP thông điệp: To, From, Cseq, Call-ID, Max- Forward, Via. 4.4 Message Body 18 EBOOKBKMT.COM Message Body được tách khỏi trường header bởi dòng trống. Thông điệp SIP có thể mang bất kỳ kiểu nào của body, kể cả body nhiều phần sử dụng mã hóa MIME (Multipurpose Internet Mail Extension ). SIP sử dụng MIME để mã hóa body của nó. Do đó, body của SIP được mô tả giống như phần đính kèm vào email. Đặc tính quan trọng của body là chúng truyền từ đầu cuối đến đầu cuối. Proxy không cần phân tích cú pháp của thông điệp body để định tuyến thông điệp. Thực tế, UA có thể lựa chọn để mã hóa nội dung của thông điệp body end to end. Trong trường hợp này, proxy sẽ không thể biết kiểu phiên nào đang được thiết lập giữa hai UA 4.5 Cấu trúc bản tin SIP  Bản tin Request: INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP ph1.company.com:5060;branch=z9hG4bK83749.1 From: Alice ;tag=1234567 To: Bob Call-ID: [email protected] CSeq: 1 INVITE Contact: Content-Type: application/sdp INVITE sip:[email protected] SIP/2.0 Content-Length: ... v=0 o=alice 2890844526 28908445456 IN IP4 172.18.193.102 s=Session SDP c=IN IP4 172.18.193.102 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000  Bản tin Response: 19 EBOOKBKMT.COM SIP/2.0 200 OK Via: SIP/2.0/UDP ph1.company.com:5060;branch=z9hG4bK83749.1 From: Alice ;tag=1234567 To: Bob ;tag=9345678 Call-ID: [email protected] CSeq: 1 INVITE ContentLength: ... v=0 o=bob 3800844316 3760844696 IN IP4 172.18.193.109 s=Session SDP c=IN IP4 172.18.193.109 t=0 0 m=audio 48140 RTP/AVP 0 a=rtpmap:0 PCMU/8000  Ý nghĩa của các trường trong bản tin: Tiêu đề SIP Mô tả From Thường là AOR(Address of Record) của người gửi. Nó bao gồm SIP hoặc SIPS URI và với tùy chọn tên được hiển thị. To Mô tả người nhận của bản tin SIP, AOR của người nhận. Với chức năng forward hay redirect thi đanh không phải là địa chỉ người nhận. Call-ID Trường nàyseries giốngcủa trường Định nghĩa bản From. tin SIP. Call-ID phải được xác định trong mọi bản tin SIP được gửi bởi tất cả các UA trong một dialog. Cseq Chứa một giá trị nguyên và tên phương thức. Trường này dùng để xác định, săpx xếp, đánh dấu chuỗi SIP request trong một dialog. Cseq có Via thể khác nhau giữa bản tin được truyền lại và truyền mới. Xác định đường đi được chỉ ra request và các response sẽ được gửi. Contact Chứa SIP hoặc SIPS URI của UA muốn nhận được SIP request mới. 20