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

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

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

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

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ẻ

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

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

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êuchuẩ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à thanhlọ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ừakhô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ự ánARPANET 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

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àiliệ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

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 ứngdụ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ạiinternet , 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ácphiê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

− 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 :

− 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 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 :

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ửitrả 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ềuloại server hay nói cách khác một SIP Server có thể hoạt động như các server khác nhautrong 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 :

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 địnhtuyế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ủabả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áccuộ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ácnhà 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à trongcá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ácdoanh 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 tinlớ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ôngqua địa chỉ trả về

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 ProxyServer, Redirect Server, SIP Phone trong mạng Giả sử thuê bao có tên user1 trongmiề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)

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 đếnProxy 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ựchiệ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ựchiện

Trong ví dụ thứ hai sẽ mô tả quá trình một SIP Phone đăng kí với với RegistrarServer quản lý nó,hoạt động của Location Server, Proxy Server

Chức năng của Location, Registrar Server trong mạng SIPKhi một SIP Phone được kết nối với mạng Nó liên tục gửi bản tin REGISTERtớ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

Client gửi yêu cầu (request) và server trả lời bằng response 1 phiên của SIP bao gồmyê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ảndù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

• 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íaphá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

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ý

414 URL được yêu cầu quá lớn

415 Không hỗ trợ kiểu media

481 Transaction không tồn tại

482 Phát hiện thấy “loop” (chu trình)

488 Không thể chấp nhận tại đây

491 Yêu cầu chưa được giải quyết

501 Chưa được thực hiện đầu đủ

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

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 Proxykhô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ợpnà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 Re q u es t:

INVITE s i p:b o b @ p r oxy .c o mp a n y c om SIP/2.0

Via: SIP/2.0/UDP

ph1.company.com:5060;branch=z9hG4bK83749.1

From: Alice <s ip:ali c e@c om p a ny .c om >;tag=1234567

To: Bob <s ip:bob@p r oxy c ompany c om>

SIP/2.0 200 OK

Via: SIP/2.0/UDPph1.company.com:5060;branch=z9hG4bK83749.1From: Alice <s ip:alic e @ c ompan y c om >;tag=1234567To: Bob <s ip:bob@p r oxy .c ompan y c om >;tag=9345678Call-ID: 12345601 @ ph 1 c ompan y c om

CSeq: 1 INVITE Length:

Content-v=0o=bob 3800844316 3760844696 IN IP4 172.18.193.109 s=Session SDP

c=IN IP4 172.18.193.109 t=0 0m=audio 48140 RTP/AVP 0 a=rtpmap:0 PCMU/8000

 Ý nghĩa c ủa c á c t rư ờ ng t r ong 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 Trường này giống trường From

Call-ID Định nghĩa series của bản 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ó thể khác nhau giữa bản tin được truyền lại và truyền mới

Via 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

Allow Liệt kê tập các phương thức SIP được hỗ trợ bởi UA.

Supported Liệt kê tập các phần mở rộng của SIP hỗ trợ bởi UA

Require Trường này rất giống như trường Supported nhưng là của các UA ở

xa cần thiết cho một transaction được xử lý

5 Chức năng của SIP

5.1 Thiết lập, sửa đổi và kết thúc phiên

SIP độc lập với kiểu của phiên đa phương tiện được điều khiển và kỹ thuật sử dụng để

mô tả phiên Nó rất hữu ích cho hội nghị, cuộc gọi audio, whiteboard được chia sẻ và cácphiên chơi game Các phiên bao gồm các luồng RTP (Real Time Protocol) mang audio vàvideo thường xuyên được mô tả bằng SDP, nhưng có một vài kiểu phiên khác có thể được

mô tả với các giao thức mô tả khác SIP được sử dụng để phân phối mô tả phiên giữa cácbên tham gia tiềm năng Khi mô tả phiên được phân phối, SIP có thể sử dụng để thỏathuận và sửa các tham số của phiên và kết thúc phiên

Ví dụ sau đây mô tả tất cả các chức năng này B muốn có một phiên audio-video với A

và dự định dùng codec PCM (Pulse Code Modulation) để mã hóa voice Trong ví dụ này,bên phân phối phiên bao gồm B gửi cho A mô tả phiên với codec PCM A thích sử dụngcodec ADPCM vì nó tốn ít băng thông hơn, do đó A thuyết phục B sử dụng ADPCM.Cuối cùng cả hai sử dụng codec ADPCM, nhưng phiên không thể được thiết lập cho đếnkhi việc thỏa thuận này kết thúc

Đột nhiên, ở giữa phiên audio-video, A quyết định muốn bỏ thành phần video A sửa

5.2 Tính di động của người sử dụng

SIP không thể phân phối mô tả phiên cho các bên tham gia cho đến khi họ được định

vị Người dùng có thể thường xuyên được liên lạc tại vài vị trí Khi đó, họ có vài địa chỉ

IP khác nhau phụ thuộc vào máy mà họ sử dụng và muốn nhận phiên đến chỉ tại vị tríhiện tại của họ Ví dụ, người khác có thể muốn nhận phiên mời trên máy trạm của họ vàobuổi sáng khi người sử dụng đến nơi làm việc, trên máy tính tại nhà vào buổi tối và trênđiện thoại cầm tay khi họ đi du lịch

SIP URI: người sử dụng trong môi trường SIP được định nghĩa bởi SIP UniformResource Identity (URI) Khuôn dạng của SIP URI tương tự như địa chỉ email, bao gồmusername và domain name:

sip: B@thanglong.com

Trong ví dụ trước, nếu chúng ta tra cứu SIP server (điều khiển domain company.com)chúng ta sẽ tìm thấy người sử dụng có username là B URI của B có thể làSIP:b@131.160.1.112, chỉ ra rằng host có địa chỉ IP là 131.160.1.112 có username là B.Registration (đăng ký): chú ý rằng, người sử dụng đăng ký vị trí hiện tại của họ choserver nếu họ muốn được tìm thấy Trong ví dụ trên, B đang làm việc trên laptop củamình có địa chỉ IP là 131.160.1.112 Tên login là B B đăng ký vị trí hiện tại của mình vớiserver của công ty Bây giờ A muốn gọi B A muốn có địa chỉ SIP Public của B sip:

B@thanglong.com) vì nó được in trong business card của B

Vì vậy, khi server tại thanglong.com được liên hệ và hỏi về B, nó biết nơi mà B có thểliên lạc và kết nối được tạo

6 Thiết lập và hủy cuộc gọi SIP:

Trước tiên ta tìm hiểu hoạt động của máy chủ ủy quyền và máy chủ chuyển đổi

+ Hoạt động của máy chủ ủy quyền (Proxy Server)

Hoạt động của Proxy server được trình bày như trong hình ….Client SIPuserA@yahoo.com gửi bản tin INVITE cho userB@hostmail.com để mời tham gia cuộcgọi.

Các bước như sau:

+ Bước 1: userA@yahoo.com gửi bản tin INVITE cho UserB ở miền hostmail.com, bảntin này đến proxy server SIP của miền hostmail.com (Bản tin INVITE có thể đi từ Proxyserver SIP của miền yahoo.com và được Proxy này chuyển đến Proxy server của miềnhostmail.com)

+ Bước 2: Proxy server của miền hostmail.com sẽ tham khảo server định vị (Locationserver) để quyết định vị trí hiện tại của UserB

+ Bước 3: Server định vị trả lại vị trí hiện tại của UserB (giả sử là UserB@hostmail.com).+ Bước 4: Proxy server gửi bản tin INVITE tới userB@hostmail.com Proxy server thêm

+ Bước 5: UAS của UserB đáp ứng cho server Proxy với bản tin 200 OK.

+ Bước 6: Proxy server gửi đáp ứng 200 OK trở về userA@yahoo.com

+ Bước 7: userA@yahoo.com gửi bản tin ACK cho UserB thông qua proxy server

+ Bước 8: Proxy server chuyển bản tin ACK cho userB@hostmail.com

+ Bước 9: Sau khi cả hai bên đồng ý tham dự cuộc gọi, một kênh RTP/RTCP được mởgiữa hai điểm cuối để truyền tín hiệu thoại

+ Bước 10: Sau khi quá trình truyền dẫn hoàn tất, phiên làm việc bị xóa bằng cách sửdụng bản tin BYE và ACK giữa hai điểm cuối

Hoạt động của máy chủ chuyển đổi địa chỉ (Redirect Server):

Hoạt động của Redirect Server được trình bày như hình

Các bước như sau:

+ Bước 1: Redirect server nhân được yêu cầu INVITE từ người gọi (Yêu cầu này có thể

đi từ một proxy server khác)

+ Bước 2: Redirect server truy vấn server định vị địa chỉ của B

+ Bước 3: Server định vị trả lại địa chỉ của B cho Redirect server

+ Bước 4: Redirect server trả lại địa chỉ của B đến người gọi A Nó không phát yêu cầuINVITE như proxy server.

+ Bước 5: User Agent bên A gửi lại bản tin ACK đến Redirect server để xác nhận sự traođổi thành công

+ Bước 6: Người gọi A gửi yêu cầu INVITE trực tiếp đến địa chỉ được

trả lại bởi Redirect server (đến B) Người bị gọi B đáp ứng với chỉ thị thành công (200OK), và người gọi đáp trả bản tin ACK xác nhận Cuộc gọi được thiết lập

Ngoài ra SIP còn có các mô hình hoạt động liên mạng với SS7 (đến

PSTN) hoặc là liên mạng với chồng giao thức H.323

III- Các giao thức hỗ trợ trong SIP

Các giao thức khác của IETF có thể sử dụng để xây dựng những ứng dụng SIP SIP cóthể hoạt động cùng với nhiều giao thức như :

− RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên mạng

− RTP ( Real-time tranpsport Protocol ) : Giao thức vận chuyển thời gian thực

− RTSP ( Real Time Streaming Protocol ) : Giao thức tạo luồng thời gian thực

− SAP ( Session Advertisement Protocol ) : Giao thức thông báo phiên kết nối

− SDP ( Session Description Protocol ) : Giao thức mô tả phiên kết nối đa phươngtiện

− MIME ( Multipurpose Internet mail Extension) : Mở rộng thư tín Internet đa mụcđích

− HTTP ( Hypertext Transfer protocol ) : Giao thức truyền siêu văn bản

− COPS ( Common Open policy Service ) : Dịch vụ chính sách mở chung

− OSP ( Open Settlement protocol ) : Giao thức thỏa thuận mở

1 RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên mạng

RSVP là một cơ chế báo hiệu dùng để dành riêng tài nguyên trên một mạng RSVPkhông phải là một giao thức định tuyến Việc quyết định tuyến do IGP (gồm cả các mởrộng TE) và CSPF.

Công việc của RSVP là báo hiệu và duy trì tài nguyên dành riêng qua một mạng TrongMPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-plane layer); không

có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-plane) Khi sử dụng chocác mục đích khác (như VoIP hay DLSW + reservations), RSVP có thể được dùng đểdành riêng không gian hàng đợi công bằng có trọng số (WFQ – Weighted Fair Queuing)hay xây dựng các ATM SVC

- RSVP có ba chức năng cơ bản:

* Thiết lập và duy trì đường đi (Path setup and maintenance)

* Hủy đường đi (Path teardown)

* Báo lỗi (Error signalling)

- RSVP là một giao thức trạng thái mềm (soft-state protocol) Nghĩa là cần lặp lại báohiệu trên mạng để làm mới định kỳ cho nó Với RSVP, một yêu cầu bị hủy nếu nó đượcchỉ định xóa khỏi mạng bằng RSVP hay hết thời gian dành riêng (reservation times out)

1.1 Các loại thông điệp trong RSVP :

Có 6 loại thông điệp trong RSVP như sau :

a) Path – sử dụng để yêu cầu tài nguyên dành trước

b) Resv – Gửi đáp ứng bản tin đường để thiết lập và duy trì dự trữ tài nguyên.c) PathTear - Sử dụng đề xóa dự trữ tài nguyên khỏi mạng theo hướng đi

d) ResvTear – Sử dụng để xóa bỏ tài nguyên khỏi mạng theo hướng về

e) PathErr – Thông báo lỗi bản tin Path

f) ResvErr- Thông báo lỗi bản tin Resv

g) ResvConf – Là một bản tin tùy chọn, gửi ngược lại tới phía gửi của bản tin Resv đề xác nhận rằng tài nguyên dự trữ xác định thực sự đã được cài đặt

h) ResvTearConf- Sử dụng để xác nhận dự trữ tài nguyên xác định đã bị xóa khỏimạng.

Bước 1: Ứng dung trên Host A sẽ tạo 1 phiên đến máy đích co Ip : 128.32.32.69 bằng RSVP tại host A

Bước 2 : Tại host A , RSVP sẽ tạo bản tin Path và sẽ gửi đến router gần nhất R1 nhằm

đưa đến địa chỉ 128.32.32.69

Bước 3 : Bản tin Path tiếp tục thông qua R5 và R4 cho đến khi đến đích là Host B

Bước 4 : Ứng dụng tại host B sẽ tiếp nhận RSVP này và kiểm tra phiên 128.32.32.69 Kiểm tra xem các bản tin này có tồn tại trong phiên không

Bước 5 : Host B sử dụng RSVP tạo ra bản tin Resv gửi ngược lại R4 về địa chỉ gửi là

24.1.70.210

Bước 6 : Bản tin Resv tiếp tục thông qua R5 và R1 cho đến khi tới Host A.

A Thiết lập và duy trì đường đi:

a.Thiết lập đường đi (Path Setup):

R4

R5

R3 R2

R1

Host A

24.1.70.210

Host B 128.32.32.69

RES

V

3 1

2