Download pdf - Mang Final

TÌM HIỂU VỀ GIAO THỨC SESSION INITIATION PROTOCOL VÀ SESSION DESCRIPTION PROTOCOL June 29, 2013

GVHD: TS Lưu Thanh Trà | 1

LỜI CẢM ƠN

Đầu tiên, chúng em xin gửi lời cám ơn sâu sắc đến giảng viên hướng dẫn của nhóm, Tiến sĩ Lưu Thanh Trà vì những sự giúp đỡ nhiệt tình và tận tụy của thầy trong quá trình làm bài tiểu luận này.

Chúng tôi cũng gửi lời cám ơn đến các thành viên lớp VP2009 vì đã giải quyết cho chúng tôi nhiều khúc mắc, khiến cho bài tiểu luận này này được hoàn thành thuận lợi.

Lê Thúc Trình

Trương Hoàng Trí



MỤC LỤC

Giao thức khởi tạo phiên (SIP) ................................................................................... 3 CHƯƠNG 1.

1.1 Vài nét về giao thức khởi tạo phiên ....................................................................................... 3

1.2 Một số khái niệm trong SIP ........................................................................................................ 4

1.3 Một cách thiết lập phiên đơn giản: ......................................................................................... 6

1.4 SIP Clients và Server ...................................................................................................................12

1.4.1 User Agent (UA) ......................................................................................................................13

1.4.2 SIP Server ..................................................................................................................................14

1.4.3 SIP URI ........................................................................................................................................16

1.4.4 Bản tin SIP .................................................................................................................................17

1.5 Tính năng của SIP .........................................................................................................................37

Giao thức mô tả phiên ..................................................................................................39 CHƯƠNG 2.

2.1 Vài nét về giao thức mô tả phiên ...........................................................................................39

2.2 Mô tả các trường của SDP: .......................................................................................................41

2.3 Mô hình Offer Answer ................................................................................................................44

2.3.1 Quy tắc để tạo một yêu cầu ................................................................................................45

2.3.2 Quy tắc tạo một thông điệp trả lời..................................................................................45

Tài liệu tham khảo: ........................................................................................................................................46



GIAO THỨC KHỞI TẠO PHIÊN (SIP) CHƯƠNG 1.

1.1 Vài nét về giao thức khởi tạo phiên

Giao thức khởi tạo phiên (Session Initiation Protocol) là một giao thức báo hiệu được sử dụng để thiết lập, thay đổi, kết thúc các phiên trong mạng IP, một phiên có thể đơn giản là một cuộc gọi điện thoại 2 chiều, một thông báo danh sách các tin nhắn hoặc một hội nghị sử dụng truyền thông đa chiều

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 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 theo IETF RFC 3261, 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. Từ khi SIP được công bố, hàng trăm nhà sản xuất đã bắt đầu bán ra trên toàn cầu máy chủ và điện thoại có tính năng SIP.

Đ thư c hi n chư c na ng đi u khi n phi n, SIP ho trơ 5 chư c na ng sau

Định vị người dùng (User Location) Xác định vị tr thi t bi đa u cuo i kha ch ha ng

Năng lực người dùng (User capabilities): Xác định phương tiện và các thông số

được sử dụng.

ng ngườ ng User availability): Xác định trạng thái và tính sẵn sàng của

thuê bao bị gọi để bắt đầu thiết lập đường truyền.

l n ion setup): Thiết lập các thông số của phiên cho cả thuê bao

chủ gọi và thuê bao bị gọi.

n l n Session management): Tạo, kết thúc, và sửa đổi phiên.

SIP là một phần trong bộ giao thức chuẩn cho truyền dòng tin đa phương thức do

IETF khuyến nghị như RSVP (giao thức giữ trước tài nguyên), RTP (giao thức truyền

tải theo thời gian thực), RTCP (giao thức điều khiển truyền tải thời gian thực), SAP

(giao thức thông báo phiên), SDP (giao thức mô tả phi n . SIP kho ng pha i la mo t giao

thư c hoa t đo ng đo c la p.

Vi tr cu a SIP trong nga n p giao thư c đa phương ti n SIP la mo t giao thư c thuo c lơ p

ư ng du ng trong mo h nh TCP IP.



SDP Media coding

SIPH.323 RTP/RCTP DNS DHCP

TCP UDP

IP

AALx

ATM

PPP

V.90 Ethernet 802.11

Lớp ứng dụng

Lớp truyền tải

Lớp mạng

Lớp vật lý/

liên kết

Báo hiệu Phương tiện Tiện ích

HÌNH 1 : S IP TRO NG MÔ HÌ NH T CP/ I P

1.2 Một số khái niệm trong SIP

Cuo c go i (call mo t cuo c go i la một giao tiếp giữa ta t ca ca c tha nh vi n trong phi n

được mơ i bơ i mo t ta i nguy n chung.

Client: là một chương trình ứng dụng gửi đi những yêu cầu SIP. Client có thể ảnh

hưởng trực tiếp hoặc không đến người sử dụng. Cli nt được chứa trong các Proxy và

UA (Uers Agent).

Ho i nghi (Con r nc hội nghị là một phi n đa phương ti n. ộ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, thoa i hai tha nh vi n.

Đoa n thoa i (dialog mo t đoa n giư a ca c co uan h ngang ha ng va no được duy

tr trong mo t khoa ng thơ i gian. o t đoa n thoa i được thi t la p bơ i ca c ba n tin SIP,

cha ng ha n như 2 đa p ư ng cho y u ca u INVIT .

Đa p ư ng k t thu c (Final R spon la đa p ứng kết thúc một phiên giao dịch SIP, bao

gồm ca c lơ p đa p ứng sau: 2xx, 3xx, 4xx, 5xx, 6xx.



Lơ i mơ i (invitation la y u cầu gửi từ User hoặc S rvic đề 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 (Parall l s arch trong một quá trình tìm kiếm song song, một

pro y đư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.

Đa p ư ng ta m thơ i (provisional r spon đa 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 1 la đa p ư ng ta 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 (s ssion th o đặ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 ác định

bởi chuỗi t n ngươ i du ng, phi n nha n da ng, kiểu mạng, kiểu địa chỉ và địa chỉ các

phần tử trong trường nguồn.

Giao di ch SIP (SIP transaction giao di ch SIP la ua tr nh ả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ừ cli nt đến server cho

đến đáp ứng k t thu c từ Server gửi trả lại Cli nt. 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 INVIT tương ứng nhưng chứa một

giao dịch của riêng nó.

a n tin dư li u gư i giư a ca c pha n tư SIP, no như la mo t pha n cu a giao thư c. Co hai

loa i ba n tin đo la ba n tin y u ca u va ba n tin đa p ư ng.

Yêu cầu la mo t ba n tin SIP được gư i tư cli nt tơ i s rv r nha m mu c đ ch y u ca u hoa t

đo ng.

Đa p ư ng la ba n tin SIP được gư i tư s rv r tơ i cli nt, no ch ra tra ng tha i cu a y u ca u

gư i tư cli nt tơ i s rv r.

Pro y hươ ng ra mo t pro y ma nha n y u ca u tư mo t cli nt. Tho ng thươ ng, ca u

h nh vơ i pro y hươ ng ra, hoa c la no co th ho c tho ng ua vi c ca u h nh tư đo ng.



Pro y, Pro y S rv r no la pha n tư trung gian, hoa t đo ng gio ng như la s rv r va

client.

Stat ul Pro y la pro y co duy tr tra ng tha i giao di ch cli nt va s rv r trong ua

tr nh ư ly y u ca u.

Stat l ss Pro y la pro y ma kho ng duy tr tra ng tha i giao di ch cli nt va s rv r khi

no ư ly y u ca u.

R dir ct S rv r ma y chu chuy n ti p, no la S va pha t ca c tho ng điệp trả lời 3

đa p la i ca c y u ca u ma no nha n được.

T (Transaction s r giao di ch ngươ i du ng la ua tr nh ư ly lơ p giao thư c ma na m

tr n lơ p giao di ch.

C ( s r g nt Cli nt la thư c th ta o y u ca u mơ i, du ng cơ ca u tra ng tha i giao

di ch cli nt đ gư i y u ca u.

S ( s r g nt S rv r la thư c th pha t đa p ư ng tra lơ i y u cầu SIP. Đa p ư ng co

th la cha p nha n, tư cho i, chuy n ti p y u ca u.

1.3 Một cách thiết lập phiên đơn giản:

Hình dưới đây chỉ ra các thông điệp SIP được trao đổi giữa 2 thiết bị sử dụng SIP. 2

thiết bị đó có thể là điện thoại SIP hoặc máy tính chạy ứng dụng SIP (softclients).

Chúng ta giả thiết rằng cả 2 thiết bị được kết nối vào mạng Int rn t và các địa chỉ IP

của các thiết bị đều đã biết.



HÌNH 2: THIẾT LẬP PHIÊN ĐƠN GIẢN

Để bắt đầu cuộc gọi, Tesla gửi SIP INVIT m ssag đến Marconi. INVITE chứa đựng những chi tiết như kiểu của phiên, call ID. Đây có thể là một cuộc phiên audio đơn giản, cũng có thể là phiên hội nghị (vieo conference) hoặc là game trực tuyến.

INVITE message chứa đựng những trường sau:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b

Max-Forwards: 70

To: G. Marconi <sip:[email protected]>

From: Nikola Tesla <sip:[email protected]>;tag=76341

Call-ID: j2qu348ek2328ws

CSeq: 1 INVITE

Subject: About That Power Outage...

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 158

v=0

o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org

s=Phone Call

c=IN IP4 100.101.102.103

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000



Những trường được liệt kê trong INVIT m ssag được gọi là header. Nó có dạng H ad r Valu CRLF. Dòng đầu tiên của m ssag được gọi là start line, chỉ ra METHOD, ở đây là INVIT , R u st- RI, sau đó là SIP v rsion, tất cả được phân cách bởi khoảng trắng.

Mỗi dòng của SIP m ssag được phân cách bởi một kí tự CRLF (Carriage Return Line Feed). Request-URI là một hình thức đặc biệt của SIP URI và nó chỉ ra địa chỉ nơi request sẽ được gửi đến.

Trường đầu tiên của H ad r sau start lin là Via. Trường này chứa SIP v rsion, sau đó là giao thức transport, ở đây là DP, tiếp theo là một khoảng trắng, kế tiếp là hostname, một dấu : và tiếp theo là số port, port mặc định của SIP là 5060. Thông số branch là transaction id n i i r. Khi thông điệp r u st này được trả lời, thông điệp trả lời sẽ chứa cùng số branch với thông điệp request.

Trường tiếp theo là Max-Forwards. Nó được khởi tạo là một số nguyên lớn nào đó, và giảm dần sau mỗi lần đi ua SIP s rv r, được sử dụng để chống loop.

Trường tiếp theo là To và From, chỉ ra originator và destination của SIP Request. SIP R u st được dẫn đường nhờ vào Request- RI thay vì To. Đó là vì R u st-URI có thể thay đổi và viết lại mỗi khi r u st được chuyển tiếp, trong khi đó To RI thì không đổi. Khi một nhãn được sử dụng, SIP URI được đóng trong dầu <>. Nhãn tên có thể hiện thị trong quá trình cảnh báo, nhưng sẽ không được sử dụng bởi giao thức.

Trường Call-ID là một trường identifier, sử dụng để định danh cho một phiên SIP. Cùng với Call-ID, mỗi party trong phiên cũng sử dụng một trường định danh, gọi là Tag, nằm trong To và From mỗi khi phiên được thành lập.

Khi bắt đầu thiết lập phiên, INVITE thiết lập một Call-ID và From Tag duy nhất. Khi trả lời cho INVITE, UA trả lời bằng cách tạo To Tag. Sự kết hợp giữa local Tag, remote Tag và Call-ID ác định duy nhất một phiên, được gọi là một dialog. Dialog được định danh bởi nhiều trường bởi tính đa chiều của nó.

Trường tiếp th o là CS , hay Command s u nc . Trường này chứa một con số, sau đó là tên m thod, trong trường hợp này là INVITE. Con số này tăng lên mỗi khi request mới được gửi. Trong ví dụ này, CS được khởi tạo là 1. Tuy nhiên nó có thể có những giá trị khác.



Trường Via kết hợp với Max-Forwards, To, From, Call-ID và CS đại diện cho yêu cầu tối thiểu của một header set trong bất cứ SIP r u st m ssag nào. Các trường khác có thể như những tùy chọn, cung cấp thêm thông tin cho một thông điệp cụ thể nào đó.

Trường Contact là bắt buộc trong thông điệp INVITE, chứa những SIP URI của thiết bị truyền thông của Tesla. URI này có thể sử dụng để dẫn đường trực tiếp đến Tesla. Trường tùy chọn Subject hiện diện trong ví dụ này. Nó không được sử dụng bởi giao thức, nhưng nó có thể hiển thị trong quá trình báo hiệu, cho người nhận thêm thông tin để ra quyết định khi nào thì đồng ý cuộc gọi.

Content-Type và Content-Length chỉ ra thân của thông điệp là thuộc kiểu nào, ở đây là SDP, và chiều dài là bao nhiêu octet.

HÌNH 3: VÍ DỤ VỀ CONTENT-LENGTH

SDP chứa những thông tin cần thiết để thiết lập một phiên.

Dữ liệu ở trong ví dụ:

HÌNH 4 Ý NGHĨ CÁC THÔNG SỐ SDP



Connection IP address: (100.101.102.103)

Media format (audio)

Port number (49170)

Media transport protocol (RTP)

Media encoding (PCM u law)

Sampling rate (8000Hz)

INVITE là một ví dụ về thông điệp SIP request. Có tất cả 6 thông điệp được định nghĩa trong tài liệu RFC 3261. Thông điệp tiếp theo là 180 Ringing, gửi để trả lời cho thông điệp INVIT . Thông điệp này chỉ ra rằng arconi đã nhận được INVITE message và báo hiệu đã hoạt động. Báo hiệu có thể là chuông r o, đèn báo…

180 Ringing là một ví dụ về SIP r spons m ssag . Thông điệp trả lời được đánh số và được phân lớp bởi chữ số đầu tiên của con số. Rất nhiều thông điệp SIP r spons được xây dựng dựa trên HTTP v1. Ví dụ bạn thường hay thấy lỗi 404 Not Found. Thông điệp này nằm trong class 4xx. Tức là những thông điệp báo lỗi.

Số trong thông điệp response chỉ ác định đường của thông điệp trên máy chủ hoặc user. Reason phrase, ở đây là Ringing được đề nghị bởi chuẩn, tuy nhiên bất cứ từ nào cũng có thể sử dụng trong trường hợp này.

Cấu trúc 180 Ringing như sau

SIP/2.0 180 Ringing


;received=100.101.102.103

To: G. Marconi <sip:[email protected]>;tag=a53e42



CSeq: 1 INVITE

Contact: <sip:[email protected]>

Content-length: 0

Thông điệp được tạo bằng cách copy rất nhiều trường trong header của thông điệp INVITE, bao gồm Via, To, From, Call-ID và CS , sau đó nó thêm vào một dòng start line chứa version SIP, response code, và reason phrase.

Thông điệp response còn chứa trường contact, chứa địa chỉ mà Marconi có thể liên lạc trực tiếp mỗi khi phiên được thiết lập



Các trường còn lại tương tự như thông điệp INVITE.

Khi arconi đồng ý nhận cuộc gọi, một thông điệp SIP r spons 200 OK được gửi đi. Thông điệp này chỉ ra kiểu của phiên thoai được yêu cầu bởi người gọi được chấp nhận. 200 OK là một ví dụ của success class response.

Cấu trúc của thông điệp 200 OK như sau

SIP/2.0 200 OK


;received=100.101.102.103




CSeq: 1 INVITE

Contact: sip:[email protected]


Content-Length: 155

v=0

o=Marconi 2890844528 2890844528 IN IP4 tower.radio.org

s=Phone Call

c=IN IP4 200.201.202.203

t=0 0



Thông điệp này được xây dựng giống như 180 Ringing. Và các thông số trong SDP gồm những thông tin sau:

End-point IP address (200.201.202.203);

Media format (audio);

Port number (60000);

Media transport protocol (RTP);

Media encoding (PCM μ-Law)

Sampling rate (8,000 Hz).

ước cuối cùng là xác nhận phiên bằng một yêu cầu ACK.

ACK sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP lab.high-voltage.rg:5060;branch=z9hG4bK321g

Max-Forwards: 70

sip:[email protected]






CSeq: 1 ACK

Content-Length: 0

Để kết thúc phiên, một thông điệp Y R u st được gửi đi

BYE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf

Max-Forwards: 70

To: Nikola Tesla <sip:[email protected]>;tag=76341

From: G. Marconi <sip:[email protected]>;tag=a53e42


CSeq: 1392 BYE

Content-Length: 0

Sau đó, một thông điệp 200 OK được gửi trở lại để trả lời cho request BYE.

1.4 SIP Clients và Server

Giao thức SIP gồm hai thành phần chính là:

User agent

Network Server



HÌNH 5 TƯƠNG TÁC GIỮA CÁC THÀNH PHẦN TRONG SIP

1.4.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 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 ,đâ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 Int rn t, đ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).

http://www.3cx.vn/voip-sip/voip-faq.php



HÌNH 6 SƠ ĐỒ USER AGENT

1.4.2 SIP Server

Máy chủ mạng bao gồm:

Máy chủ ủy quyền (Proxy server) : là một chương trình trung gian, nhận SIP request từ một UA hoặc một Proxy server khác và hoạt động như là một người thay thế cho một server và một client trong các yêu cầu trả lời hoặc chuyển tiếp. Giống như một router chuyển tiếp các gói IP, một Proxy server chuyển tiếp các thông điệp SIP ở tầng ứng dụng. Một proxy server có thể sửa 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 tuy nhiên, phải theo những quy tắc rất nghiêm ngặt trong tiêu chuẩn RFC 3261.

Một số đặc điểm của Proxy server:

Proxy server không gửi yêu cầu, nó chỉ trả lời request từ một UA. (CANCEL và ACK là những trường hợp ngoại lệ)

Proxy server không có khả năng truyền thông (media capabilitites)

Pro y s rv r không phân tích thông điệp ở thân, nó phụ thuộc hoàn toàn vào header fields



HÌNH 7: PROXY SERVER

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 địa chỉ khác và gửi lại cho đầu cuối. Giống như Pro y server, Redirect Server sử dụng databas để tìm một user. Tuy nhiên, thông tin về user được gửi trực tiếp về UA gửi request, chứ không chuyển tiếp đi.



HÌNH 8: REDIRECT SERVER

Máy chủ đăng ký (Registrar Server):. Registrar nhận các SIP REGISTER request, tất cả các request khác được trả về 501 Not Impl m nt d. Các thông tin này được sử dụng để cung cấp cho các s rv r khác trong lĩnh vực quản trị. Ví dụ như pro y s rv r hoặc redirect server. Trong một r gistration r u st, trường To chứa tên của r sourc được đăng kí, và trường contact chứa contact URIs.

1.4.3 SIP URI

Địa chỉ SIP thường là Uniform Resource Identifiers (URI) trong hầu hết các trường hợp. SIP URI chứa từ khóa sip với normal SIP URI hoặc sips với Secure SIP URI. S cur SIP nghĩa là một thông điệp SIP được gửi đi sử dụng URI này sẽ được bảo vệ sửu dụng TLS khi đi ua mỗi hop. Sau từ khóa sẽ là 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: [email protected]: 5060; transport=udp; user=ip; method = INVITE; ttl =1; maddr =240.101.102.103

mailto:[email protected]



Một số SIP URI, chẳng hạn như REGISTER, Request-URI không có us rnam , 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ố us r đượ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ố m thod đượ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 ca 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 RI, 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.

1.4.4 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 ca u và đa p ư ng. ản tin y u ca u có 6 loại, được khai báo trong trường thông số ch thi ( thod . ản tin đa p ư ng được pha n th o lơ p, nó có thông số ma tra ng tha i (Status Cod và ta có thể xem các loại bản tin.

1.4.4.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 ca u và đa p ư ng đều sử dụng chung một định dạng cơ bản được uy đị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 h ad r (tiêu đề) và và một phần thân bản tin tùy chọn.

a n tin SIP co khuo n da ng như sau

Dòng bắt đầu

Header 1: Giá trị header 1



Header 4: Giá trị header 4….

Thân bản tin

HÌNH 9: KH O N D NG 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

1.4.4.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 ca 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 ca 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 để á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 DT F

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.



INVITE

Chỉ thị INVITE được dùng để thiết lập media session 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ó pha n tha n ba n tin

chứa thông tin của người gọi. Tha n ba n tin cu ng có thể chứa các thông phiên khác như

là danh sách các tài nguyên hoặc là thông tin bảo mật. Nếu INVITE không chứa thông

tin media của 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 một dialog sẽ tạo ra một Call-ID duy nhất đượ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 ca u mới cho cùng Call-ID. Header To và

From chứa địa chỉ remote (đi a ch a và local(đi a ch no i bo . Nhãn From Tag na m

trong INVITE, và S t nh đ n nhãn To Tag trong bất kỳ đa p ư ng nào. Nhãn To Tag

trong 200 OK (ba o y u ca u tha nh co ng đáp trả INVITE được sử dụng trong trường

header To của ACK, và tất cả các y u ca 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 một cuộc hội thoại.



UAS

INVITE

UAC

180 Trying

100 Trying

Media session

ACK

200 OK

sdp UAC

sdp UAS

HÌNH 10: INVITE REQUEST

INVITE được gửi cho một cho một đoạn thoại đang tồn tại có cùng Call-ID giống như

INVITE ban đầu và chứa cùng cùng nhãn To tag và From Tag. Đôi khi nó được gọi là re-

INVITE, thông điệp yêu cầu đó được sử dụng để thay đổi các đặc tính của phiên hoặc

r r sh (làm mới) trạng thái của dialog. CSeq điều khiển chuỗi số được tăng do đó

UAS có thể phân biệt re-INVITE với 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 vẫn tiếp tục như thể re-

INVITE chưa từng được gửi. Một re-INVITE phải không được gửi bởi UAC cho tới khi

đa p ư ng cuối cùng 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 đường trunk bắt tín hiệu của cùng trunk tại cùng thời điểm.

Header Expires trong INVITE cho UAS biết y u ca u của cuộc gọi tồn tại trong bao lâu.

Thí dụ, UAS có thể để lại một yêu cầu INVITE chưa đáp trả hiển thị trong suốt một

khoảng thời gian được chỉ định trong header Expires. Một khi phiên được thiết lập,

header Expires không có y ngh a, h ad r na y ch co y ngh a trong ua tr nh thi t la p

phiên.



Một ví dụ về INVITE request:

INVITE sip:[email protected];user=phone SIP/2.0

Via: SIP/2.0/UDP salzburg.edu.at:5060;branch=z9hG4bK1d32hr4

Max-Forwards:70

To: <sip:[email protected];user=phone>

From: Christian Doppler <sip:[email protected]>

;tag=817234

Call-ID: 12-45-A5-46-F5-43-32-F3-C2

CSeq: 1 INVITE

Subject: Train Timetables

Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE,

NOTIFY



Content-Length: 195

v=0

o=doppler 2890842326 2890844532 IN IP4 salzburg.edu.at

s=-c=IN IP4 50.61.72.83

t=0 0

m=audio 49172 RTP/AVP 97 98 0

a=rtpmap:97 iLBC/8000

a=rtpmap:98 SPEEX/8000


Các trường header bắt buộc phải có trong một y u ca u INVIT đó là

ACK

Chỉ thị ACK được sử dụng đ xác nha n đa p ư ng cuối cùng cho y u ca u INVIT . No

không được du ng đ tho ng ba o cho ca c y u ca u kha c. Đáp ứng cuối cùng được định

nghĩa ở các lớp 2xx, 3xx, 4xx, 5xx, 6xx.



Cseq không bao giờ tăng cho một ACK, tuy nhiên Cseq Method bị thay đổi ở ACK.

Một ACK có thể chứa thân bản tin co 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

SDP ở thân bản tin, ACK có thể không chứa SDP ở thân bản tin. ACK có thể không được

sử dụng để thay đổi sự mô tả media đã đượ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 CK được sử dụng trong

một số ki ch ba 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

media có thể không được biết khi mà INVITE ban đầu được khởi ta o và gửi.

Với đáp ứng 2xx, ACK là toàn trình ( nd-to-end), nhưng đo i với tất cả các đáp ứng k t

thu c kha c, nó được thực hiện th o ki u nha y bươ c (hop-by-hop khi co ma t stat ul

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 pro y s rv r ma la m pha t sinh CK. 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 dưới.



HÌNH 11: SO SÁNH END TO END VÀ HOP-TO-HOP

o t stat ul pro y nha n ba n tin CK phải a c đi nh CK sẽ được chuyển hay không tr n luo ng về tới proxy hay UA khác hay không. Có nghĩa là CK th o 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(so nha n da 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 S. CK trong bước này không được proxy chuyển tiếp.

CSeq: 3 ACK


Content-Length: 172

v=0

o=bowditch 2590844326 2590944532 IN IP4 salem.ma.us

s=Bearing

c=IN IP4 salem.ma.us

t=0 0

m=audio 32852 RTP/AVP 96 0

a=rtpmap:96 SPEEX/8000




Các trường header bắt buộc trong y u ca u CK là:

BYE

Chỉ thị Y đượ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ị Y ch được gư i bơ i ca c đang tham gia trong phi n, pro y hoa c la ca c tha nh vi n thư 3 kha c kho ng được ph p gư i. o t s gư i tra vơ i đa p ư ng 481 (Dialog Transaction Do s Not ist thoa i giao di ch kho ng to n ta i cho y u ca u Y ma no kho ng bi t đ n trong đoa n thoa i.

Các trường header bắt buộc trong y u ca u Y là: Call-ID, CSeq, From, To, Via, Max-Forwards.

BYE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP port443.hotmail.com:54212;branch=z9hG4bK312bc

Max-Forwards:70

To: <sip:[email protected]>;tag=63124

From: <sip:[email protected]>;tag=9341123

Call-ID: 34283291273

CSeq: 47 BYE

Content-Length: 0

REGISTER

Chỉ thị R GIST R đượ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ị R GIST R đượ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 ca u tìm tuyến đường cho Contact này. Tùy thuộc vào header Contact và Expires của yêu ca u R GIST R, 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 ca u R GIST R. Việc sử dụng các header Request-URI, To, From, và Call-ID trong y u ca u R GIST R không khác là mấy so với các y u ca u khác. Request-URI chỉ chứa tên miền của r gistrar s rv r. Y u ca u R GIST R 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 ca u. Nó yêu cầu cùng Call-ID cho mo i hoa t đo ng đa ng k được sử dụng bởi cu ng mo t .

Một UA gửi y u ca u R GIST R có thể nhận đáp ứng 3 (chuy n ti p y u ca u hoặc là 4xx (lỗi y u ca u .

Request Header Hoạt động của Registrar

Contact: *

Expires:0

Hủy tất cả những đăng kí

Contact:


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:


Expires: 45


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.



CANCEL

C NC L dùng để cắt đứt một yêu cầu INVIT đang chờ. Nó có thể được tạo ra bởi cả UA và proxy server, khi một đáp ứng 1xx chứa một tag đã được nhận, nhưng không nhận được trả lời cuối cùng từ server. UÂ sử dụng m thod này để hủy bỏ một cuộc gọi đang chờ.

CANCEL là y u ca u th o kiểu nha 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 trùng với vơ i gia tri ranch ID cu a INVIT mà nó tiến hành 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 đa p ư ng 200 OK.

Khi mà y u ca u th o 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.

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.

Cấu trúc header của SIP

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 ca u được đánh địa chỉ. Các phần tử SIP có thể cấp Request-

URI với giản đồ sip và sips .

SIP Version

Cả bản tin y u ca u và đa 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.

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 đa p ư ng 413 R u st ntity Too Larg (thư c th y u ca u ua lơ n , khi mà việc xử lý bản tin lớn khiến cho server không thể tải được.

Nhãn tag

Nhãn tag là số ngẫu nhiên nhỏ hơn 232, nó được thêm vào trong h ad r To và From để ác định tính duy nhất của đoạn thoại. H ad r To trong INVIT ban đầu không chứa tag. Th o RFC 3261, người gọi đưa ra nhãn tag trong h ad r From (còn th o RFC 2543 thì một 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 h ad r 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 va o trong y u ca u CK.

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 S khác, và do đó yêu cầu INVIT đã 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 S. Đ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 “<>”.

1.4.4.3 Bản tin đáp ứng

Các bản tin đa p ư ng được phân biệt với các bản tin y u ca u bằng một dòng trạng thái

(Status-lin được đặt ở dòng khởi đầu của bản tin (bản tin y u ca u là dòng yêu cầu).

Dòng trạng thái của bản tin đa 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à đa p ư ng y u ca 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 đa 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

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 ế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ơ uan đă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 đồ RI 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, 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 chuyể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 giải mã được: không thể giải mã phần thân của S/MIME

5xx – sự cố của 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ó



- 504 Máy chủ bị hết giờ

- 505 Phiên bản không được hỗ trợ: máy chủ không hỗ trợ phiên bản giao thức

SIP này

- 513 Thông điệp quá lớn

6xx - sự cố toàn mạng

- 600 Tất cả mọi nơi đều bận

- 603 Từ chối

- 604 Không tồn tại ở bất cứ đâu

- 606 Không được chấp nhận

+ Các bản tin SIP có khuôn dạng t t, tương tự như HTTP. ào đầu của bản tin SIP

cũng tương tự như HTTP và SIP cũng hỗ trợ MIME (một số chuẩn về email).

1.4.4.4 Thiết lập và huỷ cuộc gọi SIP

Phiên gọi SIP giữa 2 điện thoại



HÌNH 12: MÔ TẢ MỘT PHIÊN GỌI SIP GIỮ 2 ĐIỆN THOẠI

- Máy gọi gửi một tín hiệu mời (INVITE)

- Máy được gọi gửi trả một thông tin hồi đáp 100 – Thử

- Khi máy được gọi bắt đầu đổ chuông, một tín hiệu hồi đáp 180 – Đổ chuông – được

gửi trả

- Khi bên gọi nhấc máy, máy được gọi gửi một tín hiệu hồi đáp 200 – OK

- Máy gọi hồi đáp với ACK – tiếp nhận



- Lúc này cuộc gọi đích thực được truyền dưới dạng dữ liệu thông qua RP

- Khi người gọi dập máy, một yêu cầu BYE được gửi đến cho máy gọi

- Máy gọi phản hồi với tín hiệu 200 - OK.

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

HÌNH 13: MÔ TẢ HOẠT ĐỘNG CỦA MÁY CHỦ UỶ QUYỀN

+ Client SIP [email protected] gửi bản tin INVITE cho [email protected] để mời tham gia cuộc gọi.

+ ước 1: [email protected] 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). + ước 2: Proxy server của miền hotmail.com sẽ tham khảo s rv r định vị (Location s rv r để quyết định vị trí hiện tại của UserB.

+ ước 3 S rv r định vị trả lại vị trí hiện tại của UserB (giả sử là [email protected]).







+ ước 4: Proxy server gửi bản tin INVITE tới [email protected]. Proxy server thêm địa chỉ của nó trong một trường của bản tin INVITE. + ước 5: UAS của s r đáp ứng cho server Proxy với bản tin 200 OK. + ước 6: Proxy server gửi đáp ứng 200 OK trở về [email protected]. + ước 7: [email protected] gửi bản tin ACK cho UserB thông qua proxy server. + ước 8: Proxy server chuyển bản tin ACK cho [email protected] + ướ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. + ướ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)

HÌNH 14: MÔ TẢ HOẠT ĐỘNG CỦA MÁY CHỦ CHUYỂN ĐỔI ĐỊA CHỈ

Hoạt động của R dir ct S rv r được trình bày như hình .Các bước như sau

+ ước 1 R dir ct s rv r 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).

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

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







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

+ ước 5: User Agent bên A gửi lại bản tin CK đến R dir ct s rv r để xác nhận sự trao đổi thành công.

+ ướ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 R dir ct s rv r (đến . Người bị gọi đá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.5 Tính năng của SIP

Tích hợp với các giao thức đã có của IETF

Các giao thức khác của IETF có thể xây 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 (Resource Reservation Protocol) : Giao thức giành trước tài nguyên mạng.

RTP (Real-time transport Protocol) : Giao thức truyền tải 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 trong phiên kết nối

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

MIME (Multipurpose Internet Mail Extension - Mở rộng thư tín Int rn t đa mục đích

Giao thức thư điện tử

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ở

Đơn giản và có khả năng mở rộng

SIP có rất ít bản tin, không có các chức năng thừa nhưng SIP có thể sử dụng để thiết lập những phiên kết nối phức tạp như hội nghị… Đơn giản, gọn nhẹ, dựa trên khuôn dạng văn bản, SIP là giao thức ra đời sau và đã khắc phục được điểm yếu của nhiều giao thức trước đây.



Các phần mềm của máy chủ ủy quyền, máy chủ đăng kí, máy chủ chuyển đổi địa chỉ, máy chủ định vị… có thể chạy trên các máy chủ khác nhau và việc cài đặt thêm máy chủ hoàn toàn không ảnh hưởng đến các máy chủ đã có. Chính vì thế hệ thống chuyển mạch SIP có thể dễ dàng nâng cấp.

Hỗ trợ tối đa sự di động của đầu cuối

Do có máy chủ ủy quyền, máy chủ đăng ký và máy chủ chuyển đổi địa chỉ hệ thống luôn nắm được địa điểm chính xác của thuê bao. Thí dụ thuê bao với địa chỉ [email protected] có thể nhận được cuộc gọi thoại hay thông điệp ở bất cứ địa điểm nào qua bất cứ đầu cuối nào như máy tính để bàn, máy ách tay, điện thoại SIP

Dễ dàng tạo tính năng mới cho dịch vụ và dịch vụ mới

Là giao thức khởi tạo phiên trong mạng chuyển mạch gói SIP cho phép tạo ra những tính năng mới hay dịch vụ mới một cách nhanh chóng. Ngôn ngữ xử lý cuộc gọi (Call Processing Language) và Giao diện cổng kết nối chung (Common Gateway Interface) là một số công cụ để thực hiện điều này. SIP hỗ trợ các dịch vụ thoại như chờ cuộc gọi, chuyển tiếp cuộc gọi, khóa cuộc gọi… (call waiting, call orwarding, call blocking… , hỗ trợ thông điệp thống nhất…… Với SIP rất nhiều dịch vụ di động mới được hỗ trợ.




GIAO THỨC MÔ TẢ PHIÊN CHƯƠNG 2.

2.1 Vài nét về giao thức mô tả phiên

Giao thức mô tả phiên (Session Description Protocol – SDP đầu tiên được định nghĩa trong RFC 2327. Nó được phát triển bởi IETF MMUSIC work group. Mục đích ban đầu của SDP là để mô tả các phiên thiết lập trên Internet multicast backbone (MBỎNE). Ứng dụng đầu tiên của SDP là thử nghiệm trên Session Announcement Protocol (SAP), sử dụng để gửi và nhận thông báo của phiên ON . Thông điệp SAP chứa đựng thông điệp SDP trong thân của nó, và là khuôn mẫu cho SIP. Mặc dù nó được thiết kế cho multicast, SDP đã được ứng dụng cho những vấn đề tổng quát hơn trong việc mô tả những phiên đa phương tiện được thành lập dựa trên SIP. SDP hiện tại được đặc tả bởi RFC 4566, RFC 2327

SDP chứa những thông tin sau về một phiên media:

IP address (IPv4 or IPv6 address or host name);

RTP pro i l (thường sử dụng RTP/AVP RTP/ mặc dù có thể có những giao thức khác như SAVP);

Port number (được sử dụng bởi UDP or TCP cho việc vận chuyển)

dia typ (audio, vid o, int ractiv whit board…

Media encoding scheme (PCM A-Law, P G II vid o…

Ngoài ra, SDP còn chứa thông tin khác như

Chủ để của phiên

Thời gian bắt đầu và kết thúc phiên

Thông tin liên lạc về phiên

Giống như SIP, SDP sử dụng mã hóa văn bản. Một thông điệp SDP bao gồm một loạt các dòng, gọi là i lds, tên được viết tắt bằng một chữ cái viết thường, và ở một trật tự xác định để đơn giản hóa việc phân tích. Tập hợp các SDP field từ RFC4566 được chỉ ra ở bảng dưới. Thứ tự trong bảng này chính là thứ tự trong SDP



Optional field có thể được bỏ qua, tuy nhiên nó phải ở thứ tự đúng nếu có. SDP không được thiết kế để dễ dàng mở rộng, và các quy tắc phân tích rất nghiêm ngặt. Cách duy nhất để mở rộng hoặc thêm một khả năng mới cho SDP là định nghĩa một thuộc tính mới. Tuy nhiên, các thuộc tính chưa biết có thể được bỏ qua. Bộ phân tích SDP phải khổng được bỏ qua một field chưa biết, một field bắt buộc bị mất tích hoặc một dòng nằm ngoài chuỗi (out of sequence). Ví dụ về thông điệp SDP chưa rất nhiều tùy chọn:

v=0

o=johnston 2890844526 2890844526 IN IP4 43.32.1.5

s=IETF Update

i=This broadcast will cover the latest from the IETF

u=http://www.sipstation.com

e=Alan Johnston [email protected]

p=+1-314-555-3333 (Daytime Only)

c=IN IP4 225.45.3.56/236

b=CT:144



t=2877631875 2879633673



m=video 23422 RTP/AVP 31

a=rtpmap:31 H261/90000

Dạng tổng quát của một thông điệp SDP là:

X-thống số 1, thông số 2… thông số N

Mỗi dòng bắt đầu bởi một chữ cái viết thường, ví dụ x. Không bao giờ có khoảng trắng giữa chữ cái và dấu ‘=’, và có đúng 1 kí tự trắng ở giữa các thông số. Mỗi field có một số lượng thông số ác định. Mỗi dòng kết thúc với CRLF.

2.2 Mô tả các trường của SDP:

Protocol Version

v-field chứa version của SDP. Bởi vì version hiện tại của SDP là 0, một thông điệp SDP đúng sẽ bắt đầu bằng v-0.

Origin

o-field chứa thông tin về nguồn gốc các phiên và định danh của các phiên. Field này dùng để nhận diện phiên. Field này bao gồm:

o=username session-id version network-type address-type address

Thông số username chứa orginator’s login. S ssion-id là một Network Time Protocol (NTP), một số ngẫu nhiên sử dụng để đảm bảo tính duy nhất. Thông số version là một số nguyên tăng th o mỗi sự thay đổi của phiên, được khuyến cáo có giá trị là NTP timestamp. Thông số network-type luôn luôn là IN cho Internet. Address-type có thể pà IP4 hoặc IP6.

Session Name and Information

s-field chứa tên của phiên. Nó có thể chứa bao nhiêu kí tự tùy ý, miễn là khác 0. Trường tùy chọn i- i ld chưa thông tin về phiên. Nó có thể chứa bao nhiêu kí từ tùy thích.

URI

Trường tùy chọn u-field chứa một uniform resource indicator (URI) và những thông tin khác về phiên.

E-mail Address and Phone Number



Trường tùy chọn e- i ld chưa địa chỉ email của host của phiên. Nếu một tên hiển thị được sử dụng, địa chỉ email sẽ nằm trong dấu <>. Trường tùy chọn p-field chứa một số điện thoại. Số điện thoại phải được ghi ở dạng toàn cầu, bắt đầu bằng dấu +, sau đó là mã quốc gia, một khoảng trằng hoặc dầu -, tiếp theo là mã vùng và số điện thoại. Cả khoảng trắng và dấu – đều được hiểu là kí tự trắng trong SDP. Một comment có thể được đặt trong dầu ().

Connection Data

Trường c-field chứa thông tin về kết nối m dia. Trường này có cấu trúc

c=network-type address-type connection-address

Thông số network-typ được định nghĩa là IN cho Int rn t. ddr ss typ là IP4 cho IPv4 và IP6 cho IPv6. Connection-addr ss là địa chỉ IP sẽ được gửi đi gói media, có thể là multicast hoặc unicast. Nếu là multicast, connection-address chứa:

connection-address=base-multicast-address/ttl/number-of-addresses

Trong đó ttl là tim -to-live, number-of-addresses chỉ ra có bao nhiêu địa chỉ multicast được bao gồm, bắt đầu bởi base-multicast-address.

Bandwidth

Trường tùy chọn b- i ld chưa thông tin về băng thông yêu cầu. Nó có dạng

b=modifi er:bandwidth-value

Thông số modifier có thể là CT cho conference hoặc AS cho những ứng dụng cụ thể. CT được sự dụng cho phiên multicast để uy định tổng băng thông có thể sử dụng bởi tất cả người tham gia trong phiên. S được sử dụng để uy định băng thông của một single site. Thông số Bandwidth-valu được uy định là kB/s.

Time, Repeat Times and Time Zones

Trường t-field chứa thời gian bắt đầu và thời gian kết thúc phiên

t=start-time stop-time

Thời gian được uy định sử dụng NTP timestamps. Với mỗi phiên định kì, một stop-time của zero chỉ ra rằng phiên tiếp diễn đến vô cùng. Một start-time và stop-time zero cho một phiên định kì chỉ ra rằng nó là vĩnh viễn. Trường tùy chọn r- i ld chưa thông tin về thời gian lặp lại, có thể uy định trong NTP hoặc uy định bằng ngày, giờ, phút.



Trường này được sử dụng nếu một phiên định kì kéo dài một sự thay đổi từ ban ngày so với thời gian tiêu chuẩn hoặc ngược lại.

Media Announcements:

Trường tùy chọn m- i ld chưa thông tin về kiểu của phiên m dia. Trường này có cấu trúc:

m=media port transport format-list

Thông số media có thể là audio, video, text, application message, image hoặc control. Thông số port chứa port number. Thông số transport chứa giao thức transport của RTP pro il được sử dụng. Tập hợp RTP profiles ở trong bảng sau. Format-list chứa những thông tin về m dia. Thông thường, nó chứa kiểu m dia payload định nghĩa ở RTP audio video profile. Nhiều hơn 1 m dia payload có thể được liệt kê, cho phép nhiều codecs cho một phiên media. Ví dụ, trường media sau liệt kê 3 codes:

m=audio 49430 RTP/AVP 0 6 8 99

Attributes:



Trường tùy chọn a-field chứa những thuộc tính của phiên đang hoạt động. Trường này có thể sử dụng để mở rộng SDP, cung cấp nhiều thông tin hơn về phiên media. Nếu user không hiểu hoàn toàn, thuộc tính này có thể bỏ qua.

2.3 Mô hình Offer Answer

Việc sử dụng SDP với SIP được đưa ra trong các tài liệu RFC 3264. Thông điệp mặc định ở SIP là ứng dụng/ SDP. Bên mời liệt kê tất cả các khả năng truyền thông họ sắn sàng nhận trong SDP, thương trong cả INVITE hoặc CK. Người được gọi liệt kê các khả năng truyền thông của họ trong thông điệp 200 OK. Vì SDP được phát triển cho các phiên multicast, rất nhiều trường có ít hoặc không có ý nghĩa trong bối cảnh thành lập phiên dùng SIP. Để duy trì khả năng tương thích với SDP, một số trường bắt buộc đều được bao gồm. Một SIP điển hình sử dụng SDP bao gồm version, origin, subject, time, connection, và một hoặc nhiều thuộc tính khác. Subject và time không sử dụng bởi SIP, tuy nhiên,chúng vẫn được đưa vào để tương thích.

SIP sử dụng kết nối, media và thuộc tính để thiết lập phiên giữa các s. Trường origin sử dụng hạn chế với SIP. Thông thường, session-id được giữ là hằng số trong suốt một phiên SIP và v rsion tăng lên mối khi SDP thay đổi.

Bởi vì các loại phiên m dia và các cod cs được sử dụng là một phần của negotiation connection, SIP có thể sử dụng SDP để chi định nhiều lựa chọn loại phương tiện.

Ví dụ, Tesla muốn thiết lập một cuộc gọi audio với 2 audio codecs. Trong SDP chứa trong thông điệp INVITE của SIP:

v=0

o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org

s=-c=IN IP4 100.101.102.103

t=0 0

m=audio 49170 RTP/AVP 0 8


a=rtpmap:8 PCMA/8000


a=rtpmap:32 MPV/90000

Các codecs tham chiếu bởi RTP/AVP profile number 0,8 và 32.

ên được gọi là Marconi trả lời cuộc gọi, chọn codecs thứ 2 cho trường m dia đầu tiên, và từ chối trường media thứ 2, chỉ muốn PCM-A Law

v=0



o=Marconi 2890844526 2890844526 IN IP4 tower.radio.org

s=-c=IN IP4 200.201.202.203

t=0 0


a=rtpmap:8 PCMA/8000


Nếu cuộc gọi audio này là không thể chấp nhận, Tesla sẽ gửi một yêu cầu CK, sau đó là một yêu cầu Y để kêt thúc cuộc gọi. Ngược lại, một phiên audio sẽ được thiết lập và RTP packet sẽ tiến hành trao đổi. Ví dụ này cho thấy, trừ khi số lương và trật tự truyền thông được duy trì, bên mời sẽ không biết chắc chắc đó là phiên m dia đã được chấp nhận hay từ chối bởi người được gọi.

2.3.1 Quy tắc để tạo một yêu cầu

Một yêu cầu SDP phải bao gồm tất cả các trường bắt buộc (this includes v=, o=, s=, c=,

and t=). Nó thông thường bao gồm một trường m dia (m= nhưng điều này là không bắt buộc. Dòng media chứa tất cả các codecs liệt kê theo một thứ tự nhất định. Ngoại lệ duy nhật là nếu có thiết bị đầu cuối hô trợ một số lượng lớn các codecs. Các khả năng được chấp nhận nhất hoặc ưa thích nhất sẽ được liệt kê. Các loại phương tiện truyền thông khác nhau bao gồm vid o, audio, t t, SRP, FCP…

2.3.2 Quy tắc tạo một thông điệp trả lời

Một thông điệp trả lời SDP cho một yêu cầu phải được xây dựng trên những quy tắc này. Câu trả lời phải có cùng số m-lines ở cùng thứ tự giống như một thông điệp answer. Dòng media cá nhân có thể bị từ chối bằng cách đăt port numb r về 0. Dòng được chấp nhận bằng việc gửi những số port khác 0.Trọng tải niêm yết cho từng loại phương tiện truyền thông phải là một tập hợp con của các trọng tải được liệt kê.Thông thường, chỉ có một tải trọng duy nhất được chọn.



TÀI LIỆU THAM KHẢO:

Các tài liệu RFC

[1] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handl y, and . School r, SIP S ssion Initiation Protocol, RFC 3261, Jun 2002.

[2] Ros nb rg, J., Obtaining and sing Globally Routabl s r g nt ( RIs (GRUU) in th S ssion Initiation Protocol (SIP , dra t-ietf-sip-gruu-15 (work in progress), October 2007.

[3] Ros nb rg, J., H. Schulzrinn , and P. Kyzivat, Indicating s r g nt Capabilities in the- S ssion Initiation Protocol (SIP , RFC 3840, ugust 2004.

[4] Johnston, ., and O. L vin, S ssion Initiation Protocol (SIP Call Control—Conferencing or s r g nts, CP 119, RFC 4579, ugust 2006.

[5] Roach, ., S ssion Initiation Protocol (SIP)-Sp ci ic v nt Noti ication, RFC 3265, June 2003.

[6] P track, S., and L. Conroy, Th PINT S rvic Protocol t nsions to SIP and SDP for IP cc ss to T l phon Call S rvic s, RFC 2848, Jun 2000.

[7] Rosenberg, J., H. Schulzrinn , and O. L vin, S ssion Initiation Protocol (SIP Event

[8] Understanding the SIP Protocol, Alan B. Johnston, 3rd edition.