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
Trang 1ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN
MÔN: CÔNG NGHÊ ̣ MẠNG VÀ TRUYỀN THÔNG HIÊ ̣N ĐẠI
"SIP / VOIP"
Giảng viên: PGS.TS Lê Trung Quân
Sinh viên: Trương Hoàng An – CH1502026
Trương Xuân Vinh – CH1502044
TP HỒ CHÍ MINH, NĂM 2016
Trang 2Mu ̣c lu ̣c
1 Giao thức SIP 4
1.1 Tổng quan 4
1.2 Kiến trúc của SIP 5
1.2.1 SIP User Agent (UA) 6
1.2.2 SIP Server – UA Server 6
1.2.3 SIP Proxy Server 6
1.2.4 SIP Redirect Server 7
1.2.5 SIP Registrar Server / Resigntration Server 7
1.2.6 SIP Location Server 7
1.3 Các thông điê ̣p trong giao thức SIP 7
1.3.1 SIP Request 7
1.3.2 SIP Response 8
1.3.3 Cấu trúc thông điê ̣p của giao thức SIP 10
1.4 Thiết lâ ̣p cuô ̣c go ̣i trong SIP 12
1.4.1 Thư ̣c hiê ̣n cuô ̣c go ̣i thông qua Proxy Server 13
1.4.2 Thư ̣c hiê ̣n cuô ̣c go ̣i thông qua Rediect Server 13
1.4.3 Registration 14
1.5 Các giao thức trong SIP 15
1.5.1 RSVP ( Reource Revervation Protocol ) : Giao thức chiếm trước tài nguyên mạng 15
1.5.2 RTP ( Real Time Tranpsport Protocol ) : Giao thức vận chuyển thời gian thực 16
1.5.3 RTCP(Real-Time Transport Control Protocol) 17
1.5.4 RTSP ( Real Time Streaming Protocol ) : Giao thức tạo luồng thời gian thực 17
1.5.5 SDP ( Session Description Protocol ) : Giao thức mô tả phiên kết nối đa phương tiện 17
1.5.6 MIME ( Multipurpose Internet mail Extension – Mở rộng thư tín Internet đa mục đích 17
2 VoIP 18
2.1 Tổng quan VoIP 18
2.2 Các đă ̣c tı́nh của VoIP 19
2.2.1 Ưu điểm 19
2.2.2 Nhược điểm 20
2.2.3 Những khó khăn khi triển khai dịch vụ 21
2.3 Kiến trúc của VoIP 21
2.3.1 Tiến trình hoạt động của VoIP 22
2.3.2 Mô hı̀nh phân lớp chức năng 22
2.4 Các kiểu kết nối sử dụng VoIP 23
2.4.1 Computer to Computer 23
2.4.2 Computer to phone 23
Trang 32.4.3 Phone to phone 24
2.5 Vấn đề bảo mật trong VoIP 24
3 Demo 25
3.1 Ki ̣ch bản 25
3.2 Thử nghiê ̣m thư ̣c tiễn 28
4 Tài liê ̣u tham khảo 29
Trang 41 Giao thức SIP
1.1 Tổng quan
Trước đây khi đề cập đến VoIP, tiêu chuẩn quốc tế thường được đề 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, H.225, Q.931 hoạt động dựa trên H.323 là rất chặt chẽ và phức tạp Nhưng 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ẳn H.323, vì VoIP là một trong những dịch vụ sẽ rất phát triển trong tương lai
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 thông quan internet, hội nghị thoa ̣i và các ứng dụng tương tự có liên quan đến các phương tiện truyền thông (media) như âm thanh, hình ảnh và dữ liệu
SIP sử dụng các bản tin Request (INVITE) để thiết lập các phiên hô ̣i thoa ̣i và để mang các thông tin
mô tả các thông số kênh truyền của phiên truyền dẫn SIP hỗ trợ các phiên đơn người dùng (unicast)
và đa người dùng (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
Các cuộc gọi điện thoại qua internet
Các phiên video qua internet
Phân phối đa phương 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 – unicast
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
Khối mào đầu (Headers) – Mô tả về phiên truyền thông
Phần thông tin báo (Message Body) – SDP , ký tự , XML
Đầu tiên giao thức 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) Giao thức 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 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
Trang 5RFC 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
Một bản tin SIP có hai phần, phần mào đầu và phần thân 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ư SIPT 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ổ biến 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 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 Internetworking), SPIRITS (PSTN/IN requesting Internet Services)
1.2 Kiến trúc của SIP
Hı̀nh 1 – Mô hı̀nh kiến trúc của một hê ̣ thống giao tiếp SIP
SIP gồm 2 thành phần lớn là SIP client – UA client (là thiết bị hỗ trợ giao thức SIP như SIP phone),
và SIP server – UA Server (là thiết bị trong mạng xử lý các bản tin SIP) Trong SIP server có các thành phần quan trọng như: Proxy server, Redirect server, Location server, Registrar server
Trang 61.2.1 SIP User Agent (UA)
Mục đích của SIP là làm cho các session có thể thiết lập giữa các UA Một UA là một hệ thống cuối cùng hoạt động trên danh nghĩa của người dùng Một UA 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 UA khác
Một UA phải duy trì trạng thái trên các cuộc gọi mà nó khởi tạo hoặc tham gia vào Một trạng thái nhỏ nhất của các cuộc gọi được thiết lập bao gồm: các thẻ Local và Remote, Call-ID, các trường Local và Remote CSeq, cùng với việc thiết lập hướng và các thông tin cần thiết của các phương tiện Remote Cseq thì lưu trữ các thông tin cần thiết để phân biệt giữa một Re-INVITE và một Re-Transmission Một Re-INVITE được sử dụng để thay đổi các tham số session của một cuộc gọi đã thực hiện hoặc chưa xử lý Nó sử dụng như một Call-ID nhưng CSeq thì được gia tăng bởi vì nó là một Request mới Một INVITE được truyền lại chứa Call-ID và CSeq giống như INVITE trước
UA duy trì trạng thái của một cuộc gọi trong thời gian tối thiểu là 32 giây
Một UA chứa một ứng dụng Client và một ứng dụng Server
Hı̀nh 2 – Giao tiếp của UAC và UAS
Hai thành phần trên là một User Agent Client (UAC) và một User Agent Server (UAS) UAC bắt đầu các Request trong khi UAS thì tạo ra các Response Trong một session, UA thường điều khiển
cả UAC và UAS Một SIP User Agent cũng phải hỗ trợ SDP để mô tả Media Một UA phải hiểu rõ danh sách các trường nhu cầu mở rộng trong một Request Nếu không biết các trường này có thể bị
lờ đi bởi một UA
1.2.2 SIP Server – UA Server
SIP servers là các ứng dụng mà nó chấp nhận các SIP Request và Response đến chúng Không nên lẫn lộn SIP Server với một User Agent Server hoặc Client-Server Một SIP Server là một kiểu khác biệt của thực thể Bởi vì SIP Server cung cấp các dịch vụ và chức năng với UA, chúng sẽ hỗ trợ cả TCP, TLS và UDP để truyền tải
1.2.3 SIP Proxy Server
Trang 7Proxy Server: là thực thể trong mạng SIP làm nhiệm vụ chuyển tiếp các SIP 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 Proxy Server cũng cung cấp các chức năng xác thực trước khi cho khai thác dịch vụ
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, proxy có lưu trạng thái, chúng duy trì trạng thái trong suốt transaction (khoảng 32 giây) Một Proxy Server khác biệt với một User Agent hoặc Gateway ở ba điểm sau:
Một Proxy Server không đưa ra các Request, nó chỉ đáp ứng các Request từ một User Agent (A CANCEL Request là một ngoại lệ trong quy tắc này)
Một Proxy Server không có khả năng về Media
Một Proxy Server thì không phân tích các thông điệp, mà chỉ dựa vào các Header Field 1.2.4 SIP Redirect Server
Redirect Server: là thực thể trong mạng SIP làm nhiệm vụ 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ề
1.2.5 SIP Registrar Server / Resigntration Server
Registrar server: là server 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 Server Registration Server thường yêu cầu các User Agent đăng ký để xác thực, vì vậy các cuộc gọi đi vào không bị chiếm đoạt bởi các User không được xác thực Phụ thuộc vào sự hiện diện của các trường, Register Request có thể được sử dụng bởi một User Agent để lấy lại một danh sách của các Registration hiện thời, làm sạch tất cả Registrations, hoặc thêm vào một Registration URI Để bảo vệ Registration, TLS phải được sử dụng như HTTP Digest không cung cấp nhu cầu bảo vệ toàn vẹn
1.2.6 SIP Location Server
Location Server: lưu thông tin trạng thái hiện tại của người dùng trong mạng SIP
1.3 Các thông điê ̣p trong giao thức SIP
1.3.1 SIP Request
SIP Requests là các thông điệp được gửi từ các máy Client đến các Server để cần khẩn một SIP Operation RFC 3261 xác định các SIP Request hoặc Method làm cho UA và Proxy có thể tới vị trí của các User và khởi đầu, sửa đổi, Tear-down các session
INVITE:chỉ ra rằng các Recipient User hoặc các service bị cuốn vào trong một session Bạn
có thể sử dụng method mày để sửa đổi cấu thành của các session được thiết lập trước Thân của Message INVITE phải bao gồm phần mô tả các Media Session được thiết lập hoặc chỉnh sửa, mã hóa trên SDP Một Response thành công (200 OK Response)chỉ ra sự sẳn sàng của các Called Party khi tham gia vào kết quả của một session media Nó bắt đầu một session
ACK: xác nhận UAC đã nhận được Response cuối cùng đến một Request INVITE ACK được sử dụng chỉ với các Request INVITE ACK gửi End-To-End cho một 200 OK Response Proxy trước hoặc UAC thì gửi các ACK cho các Response cuối cùng khác ACK Request có thể bao gồm một thông điệp với phần mô tả các session cuối cùng nếu Request INVITE không chứa phần mô tả các session này
Trang 8 OPTION: UA sử dụng Request OPTION để truy vấn một UAS về khả năng của nó Nếu UAS có khả năng truyền các session tới các User, nó đáp ứng khả năng thiết lập của UAS
BYE: sử dụng BYE để yêu kết thúc các session được thiết lập trước
CANCEL: làm cho các UAC và Network Server có thể hủy một yêu cầu tiến trình bên trong, như INVITE Điều này không ảnh hưởng đến việc hoàn thành các Request mà UAS
đã gửi đi các Response cuối cùng
REGISTER: client sử dụng REGISTER Request để đăng ký với các thông tin tương ứng AOR của người dùng và SIP servers
PRACK: đảm bảo độ tin cậy tạm thời của các Response lớp 1xx
UPDATE: cập nhật tạm thời các session
REFER: chuyển giao call đến bên thứ ba sử dụng các thông tin liên quan được cung cấp trong các Request
SUBSCRIBE: báo cáo một sự kiện vừa diễn ra, ví dụ như cập nhật sự hiện của các user
NOTIFY: sử dụng để thông báo sự kiện đã diễn ra
MESSAGE: một phương thức để chỉ việc mang đi một message
Hı̀nh 3 – Giao tiếp bằng các thông điê ̣p Request và Response
1.3.2 SIP Response
Một server gửi SIP Response tới một Client để chỉ ra trạng thái của một SIP Request mà Client trước đó đã gửi tới Server UAS hoặc Proxy thì tạo ra các SIP Responses trong Response đến một SIP Request mà UAC khởi đầu SIP Response là các con số từ 100 đến 699 SIP Responses là một nhóm giống như 1xx,2xx đến 6xx SIP Response được phân loại như Provisional và Final
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)
Trang 9 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
180: đổ chuông : Máy được gọi đổ chuông, và gửi bản tin chuông về cho bên gọi
181: cuộc gọi đang chuyển hướng: May được gọi lập trình chuyển hướng đến một máy khác trong khi nó đang bận hoặc không xử lý cuộc gọi của bên gọi
182 : đang xếp hàng đợi : chờ đợi vì có nhiều yêu cầu đến cùng lúc 183: Phiên đang tiến hành: Có phiên cuộc gọi khác đang đựơc tiến hành với máy đựợc gọi
200 OK phản hồi thành công : được dùng khi bên được yêu cầu trả lời thành công yêu cầu của bên yêu cầu: ỏ ví dụ trên ta dùng hai bản tin 200 ok Trong đó bản tin đầu tiên do máy được gọi phản hồi lại máy gọi khi nó trả lời thành công bản tin chuông Còn trong bản tin
200 OK thứ hai do máy gọi phản hồi đến máy được gọi khi nó đã gọi thành công cuộc gọi
và chấp nhận kết thúc cuộc gọi
3xx: Phản hồi chuyền hướng
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 thất bại
400: yêu cầu sai
401: không được quyền: chỉ dùng với cơ quan đăng kiểm, các proxy phải dùng yêu cầu cấp phép cho proxy 407
402: yêu cầu trả tiền :Dự trữ để phòng trong tương lai: Ví dụ khi bạn dùng điện thoại di động, tiền trong tài khoản của bạn gần hết, trước khi thiết lập cuộc gọi theo yêu cầu của bạn thì tổng đài sẽ thêm một thông báo:"Tài khoản của bạn sắp hệt , xin vui lòng nạp thêm để có thê tiếp tục sử dụng"
403: cấm
404: Không tìm thấy người dùng:"Thuê bao quý khách vừa gọi Không có, xin vui lòng thứ lại"
Trang 10 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 bây giờ không còn được sử dụng nữa:"Thuê bao quý khách vừa gọi hiện đang tạm khóa, mong quý khách vui lòng gọi lại sau"
413: Đơn vị yêu cầu quá lớn: "cuộc gọi không thể thực hiện được"
414: URI của yêu cầu quá tải :"mạng quá tải"
415: kiểu phương tiện không được hỗ trợ: ví dụ : tin nhắn đa phương tiện không thể gửi đến
và nhận từ một số máy di động không hỗ trơn GPRS
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ủa giao thức SIP không đúng nên máy chủ không hiểu được
421: Yêu cầu có phần mở rộng
423: Quãng quá ngắn
480: tạm thời không hoạt động
481: cuộc gọi/giao dịch không tồn tại
482: phát hiện thấy lặp
483: quá nhiều chặng trung tuyến
484:địa chỉ không hoàn chỉnh
485: tối nghĩa
486: đang bận
487: yêu cầu bị chấm dứt
488: Không được chấp nhận tại đây
491: yêu cầu đang chờ
493: không thể giải mã được : Không thể giải mã phần thân của S/MIME
5xx: Lỗi máy chủ
500: lỗi bên trong máy chủ
501: chưa khai báo: Phương thức yêu cầu SIP này chưa đựơc khai báo ở đây
502: gateway sai
503: dịch vụ không có
505: phiên bản không được hỗ trợ: Máy chủ không hỗ trợ giao thức SIP này
513: thông điệp quá lớn
1.3.3 Cấu trúc thông điê ̣p của giao thức SIP
Một SIP message gồm có các phần sau:
Một Start-Line
Một hoặc nhiều header field
Trang 11 Một dòng rỗng để chỉ ra kết thúc header field
Một tùy chọn phần thân của thông điệp
Bạn phải kết thúc Start-Line,mổi dòng Message-Header,và một dòng rỗng bằng trình tự
Carriage return Line Feed(CRLF)
Start-Line cho một SIP Request là một Request-line Start-line cho một SIP Response là Status-line Request-line chỉ rõ SIP Method, Request-URI và phiên bản của SIP Status-line thì mô tả phiên bản của SIP, mã của SIP Response và một tùy chọn Reason Phrase Reason Phrase là một nguyên văn
mô tả của mã 3 ký từ SIP Response
Hı̀nh 4 – Cấu trúc thông điê ̣p Request
Hı̀nh 5 – Cấu trúc thông điê ̣p Response
Một thông điệp SIP được soạn ra từ các Header Field mà nó truyền tín hiệu và thông tin Routing đến các thực thể SIP Network SIP có hình thức giống như HTTP Header(RFC 2616) Các Header Field được xác định kiểu như Header Field Mô tả chức năng của các SIP Header:
From: chỉ ra sự giống nhau lúc bắt đầu của các SIP Request Từ Header thường là AOR của bên gửi Nó chứa một SIP hoặc các SIP URI và một tùy chọn hiển thị tên
To: cho biết mong muốn có người nhận của một SIP Request Đi đến Header là một AOR của người nhận Nó cũng chứa SIP hoặc SIP URI và tùy chọn hiển thị tên
Call-ID: trường này nhận ra một dãy serie của một message Call_ID phải giống hệt nhau để tất cả các SIP Request và SIP Response gửi đi bằng các UA khác nhau với cùng một dialog
Trang 12 Cseq: được soạn ra của một giá trị số nguyên và tên method Trường này nhận ra Orders và tiếp tục các SIP Request trong một dialog Cseq cũng có sự khác biệt trong việc gửi lại một message và một message mới
Via: chỉ ra cách lấy đường dẫn bởi một request và xác định nơi mà response cần gửi đi
Contact: nhận biết một SIP hoặc SIP URI nơi mà UA muốn nhận một SIP Request mới
Allow: cho phép danh sách Header của SIP Method nhận hỗ trợ của UA mà tạo ra message
Supported: tất cả phần mở rộng của SIP hỗ trợ bởi UA Phần mở rộng của SIP là các RFC khác và RFC 3261 Miêu tả các thẻ option giống như 100rel trong RFC 3262
Require: về nghĩa nó giống như Supported Header, nhưng sự hỗ trợ của phần mở rộng SIP ở các UA từ xa phải đến các giao tác để được xử lý
Content-type: chỉ ra kiểu của thân message mà đính kèm với SIP Request hoặc Response phải được hiện ra nếu SIP Message có một thân
Content-Length: xác định kích thước của thân message SIP Request và SIP Response cũng chứa các Header Field
1.4 Thiết lâ ̣p cuô ̣c go ̣i trong SIP
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ác phiê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ác bên tham gia tiềm năng Khi mô tả phiên được phân phối, SIP có thể sử dụng để thỏa thuậ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ụng codec 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 đến khi 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 phiên chỉ có audio Khi B quyết định cuộc hội thoại đã kết thúc, phiên được kết thúc 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ào buổ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 Uniform Resource Identity (URI) Khuôn dạng của SIP URI tương tự như địa chỉ email, bao gồm username 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ọ cho server 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ủa mì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ới server 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
Trang 13business 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
1.4.1 Thư ̣c hiê ̣n cuô ̣c go ̣i thông qua Proxy Server
Hoạt động của Proxy server được trình bày như trong hình ….Client SIP userA@yahoo.com gửi bản tin INVITE cho userB@hotmail.com để mời tham gia cuộc gọi
Hı̀nh 6 – Cuộc gọi thực hiê ̣n thông qua Proxy Server
Các bước như sau:
Bước 1: userA@yahoo.com gửi bản tin INVITE cho UserB ở miền hotmail.com, bản tin này đến proxy server SIP của miền hotmail.com (Bản tin INVITE có thể đi từ Proxy server SIP của miền yahoo.com và được Proxy này chuyển đến Proxy server của miền hotmail.com)
Bước 2: Proxy server của miền hotmail.com sẽ tham khảo server định vị (Location server)
để quyết định vị trí hiện tại của UserB.// Từ proxy server của mien hotmail.com nó sẽ đến location server de dinh vi vị tri hien 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@hotmail.com)
Bước 4: Proxy server gửi bản tin INVITE tới userB@hotmail.com Proxy server thêm địa chỉ của nó trong một trường của bản tin INVITE
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
1.4.2 Thư ̣c hiê ̣n cuô ̣c go ̣i thông qua Rediect Server
Trang 14Hı̀nh 7 – Cuô ̣c go ̣i đươ ̣c thực hiê ̣n thông qua Redirect Server 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ầu INVITE 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ỉ đượctrả lại bởi Redirect server (đến B) Người bị gọi B đáp ứng với chỉ thị thành công (200 OK), và người gọi đáp trả bản tin ACK xác nhận Cuộc gọi được thiết lập
1.4.3 Registration
Hı̀nh 8 – Mô hı̀nh đăng kı́ của User trong SIP