giới thiệu sip
TRANSCRIPT
Mục lục
CHƯƠNG 1: GIỚI THIỆU SIP..................................................................................3
1.1 SIP LÀ GÌ ?......................................................................................................3
1.2 SIP ADDRESSING (ĐỊA CHỈ CỦA SIP)........................................................3
1.2.1 User Agents :..............................................................................................4
1.2.2 Registrar.....................................................................................................4
1.2.3 Location Service........................................................................................5
1.2.4 Proxy Server...............................................................................................5
1.2.5 Forking.......................................................................................................7
1.2.6 Redirect Server...........................................................................................9
1.2.7 Back-to-Back User Agents (B2BUA)......................................................10
CHƯƠNG 2: CÁCH HOẠT ĐỘNG CỦA GIAO THỨC SIP.................................11
2.1 MÔ HÌNH HOẠT ĐỘNG CỦA SIP..............................................................11
2.1.1 SIP Responses..........................................................................................11
2.2 SIP Requests...................................................................................................12
2.2.1 REGISTER..............................................................................................13
2.2.2 INVITE....................................................................................................14
2.2.3 ACK.........................................................................................................16
2.2.4 CANCEL..................................................................................................17
2.2.5 Options.....................................................................................................18
CHƯƠNG 3: SIP MESSAGE...................................................................................19
3.1 Start line..........................................................................................................20
3.2 Header field.....................................................................................................22
3.2.1 From.........................................................................................................23
3.2.2 To.............................................................................................................23
3.2.3 Call-ID.....................................................................................................23
3.2.4 Via............................................................................................................23
3.2.5 Contact.....................................................................................................25
3.2.6 Record-Route và Route............................................................................26
3.2.7 CSeq.........................................................................................................27
3.2.8 Max-Forwards..........................................................................................28
3.3 SIP Message Body..........................................................................................28
1
3.3.1 Content-Type...........................................................................................29
3.3.2 Content-Length........................................................................................29
3.3.3 Content-Encoding....................................................................................29
3.4 Mối quan hệ giữa Call, Dialog, Transaction và Message...............................30
CHƯƠNG 4: CẤU TRÚC GIAO THỨC SIP..........................................................32
CHƯƠNG 5: XÂY DỰNG SIP STACK DÙNG JAIN SIP.....................................34
5.1 JAIN SIP LÀ GÌ ?...........................................................................................34
5.2 Các bước xây dựng 1 Sip Stack......................................................................34
5.2.1 Các phần mềm và gói phụ thuộc..............................................................34
5.2.2 Sip Client.................................................................................................34
5.2.3 Sip Proxy..................................................................................................39
2
CHƯƠNG 1: GIỚI THIỆU SIP
1.1 SIP LÀ GÌ ?
SIP là viết tắt của cụm từ “Session Initiation Protocal”, là một giao thức truyền tín
hiệu ở tầng ứng dụng (application-level) và được định nghĩa bởi IETF. SIP được
sử dụng để tạo và quản lý các session thông qua mạng IP. Thuật ngữ “Session” là
một phiên làm việc trong quá trình trao đổi media (voice, video,….).
SIP làm việc cùng với một vài các giao thức khác trong tầng ứng dụng để
nhận dạng và truyền session media. Sự nhận dạng và thỏa thuận về media được thực
hiện với Session Description Protocol (SDP). Đối với việc truyền các media stream
(voice, video), SIP sử dụng Real-time Transport Protocol (RTP) hay Secure Real-
time Transport Protocol (SRTP). Còn bảo mật trong quá trình truyền các thông điệp
thì được mã hóa bởi Transport Layer Security (TLS).
SDP được sử dụng để miêu tả về các media session nhằm mục đích thông
báo, mời gọi và thỏa thuận tham số dành cho 1 session. Do đó, để tạo ra một
session, một SIP message luôn mang theo SDP mà cho phép các bên tham gia đồng
ý thiết lập một vài các thông số cần thiết để trao đổi media, cũng như loại media,
địa chỉ truyền tải,…
1.2 SIP ADDRESSING (ĐỊA CHỈ CỦA SIP)
Các thành phần của SIP:
Các thành phần của SIP bao gồm :
User Agents (UAs)
Registras
Proxies
Back-to-Back User Agents (B2BUSs)
1.2.1 User Agents :
Một SIP User Agent (UA) bao gồm 2 thành phần : User Agent Client (UAC) và User Agent Server (UAS).
3
Nhiệm vụ của UAC : tạo ra các SIP request (yêu cầu) gởi cho UAS và thu
nhận các response (phản hồi) được gởi từ UAS .
Nhiệm vụ của UAS : nhận các SIP request được gởi từ UAC và tạo ra các
response gởi cho UAC.
Hình 1. 1 Các thành phần UA
*Lưu ý : SIP độc lập với media session. SIP không dính líu với bất cứ loại media
session nào mà cần được thực hiện. Ví dụ, nếu bạn muốn tăng cường 1 tính năng
nào đó cho media thì bạn phải bổ sung thành phần đó và tích hợp nó với user
interface, còn chính SIP User Agent vẫn không thay đổi.
SIP UA là bộ phận quan trọng của 1 ứng dụng về truyền media. SIP UA
được thực hiện trong nhiều cách khác nhau, có thể là:
Một phần mềm chạy trên PC.
Một ứng dụng trên mobile phone.
Một trạng thái nào đó trong network server : gởi phản hồi tự động khi có yêu
cầu, tự động gởi media chúc mừng sinh nhật,….
1.2.2 Registrar
Registrar là một server mà chấp nhận các registration request (các yêu cầu
được đăng ký) từ các UA. UA cung cấp vị trí hiện tại của nó với 1 SIP Message
truyền đến Registrar Server. 1 SIP UA cần được đăng ký trước khi nó có thể nhận
cuộc gọi. Khi registrar nhận registration request, nó đưa những thông tin mà nó
nhận được vào trong 1 cơ sở dữ liệu được gọi là Location Service.
Tức là, Registrar là 1 SIP endpoint mà nhận các registration request và đưa
các thông tin nó nhận được trong request này vào location service để xử lý.
4
1.2.3 Location Service
Location Service là một cơ sở dữ liệu mà chứa một tập danh sách ánh xạ
giữa Adresses of Record (AORs – địa chỉ công khai dành công UA) và Contact
Addresses (địa chỉ để xác định tên domain cũng như vị trí của người dùng).
Khi Registrar nhận một registration request từ một UA, registrar sẽ đưa
thông tin nó nhận được vào Location Service. Location service cũng được liên hệ
với Proxy Servcers chỉ ra domain chính xác để lấy về thông tin vị trí có thể thực
hiện được cuộc gọi đến người dùng.
Hình 1. 2 Ví dụ về Location Service
1.2.4 Proxy Server
Chức năng của Proxy Server trong Internet :
Một số hãng và công ty sử dụng proxy với mục đích: Giúp nhiều máy tính
truy cập Internet thông qua một máy tính với tài khoản truy cập nhất định, máy tính
này được gọi là Proxy server. Chỉ duy nhất máy Proxy này cần modem và account
truy cập internet, các máy client (các máy trực thuộc) muốn truy cập internet qua
máy này chỉ cần nối mạng LAN tới máy Proxy và truy cập địa chỉ yêu cầu. Những
yêu cầu của người sử dụng sẽ qua trung gian proxy server thay thế cho server thật
sự mà người sử dụng cần giao tiếp, tại điểm trung gian này công ty kiểm soát được
mọi giao tiếp từ trong công ty ra ngoài internet và từ internet vào máy của công ty.
5
Sử dụng Proxy, công ty có thể cấm nhân viên truy cập những địa chỉ web không cho
phép, cải thiện tốc độ truy cập nhờ sự lưu trữ cục bộ các trang web trong bộ nhớ của
proxy server và giấu định danh địa chỉ của mạng nội bộ gây khó khăn cho việc thâm
nhập từ bên ngoài vào các máy của công ty.
Đối với các nhà cung cấp dịch vụ đường truyền internet: Do internet có
nhiều lượng thông tin mà theo quan điểm của từng quốc gia, từng chủng tộc hay địa
phương mà các nhà cung cấp dịch vụ internet khu vực đó sẽ phối hợp sử dụng
proxy với kỹ thuật tường lửa để tạo ra một bộ lọc gọi là firewall proxy nhằm ngăn
chặn các thông tin độc hại hoặc trái thuần phong mỹ tục đối với quốc gia, chủng tộc
hay địa phương đó. Địa chỉ các website mà khách hàng yêu cầu truy cập sẽ được lọc
tại bộ lọc này, nếu địa chỉ không bị cấm thì yêu cầu của khách hàng tiếp tục được
gửi đi, tới các DNS server của các nhà cung cấp dịch vụ. Firewall proxy sẽ lọc tất cả
các thông tin từ internet gửi vào máy của khách hàng và ngược lại.
Chức năng của Proxy Server trong SIP:
Tương tự như chức năng của Proxy Server trong Internet, Proxy Server trong
SIP là một thực thể trung gian, vai trò chính của proxy là định tuyến, nghĩa là bảo
đảm một request được gởi đi đến người dùng. Proxy Server có thể được dùng để
kiểm tra, thống kê, tìm đường truyền kế tiếp, chính sách bắt buộc nào đó,….
Có nhiều loại Proxy khác nhau trong SIP, nhưng 2 loại Proxy thường được nhắc
đến là : outbound proxy và inbound proxy.
Outbound Proxy : Outbound Proxy giúp đỡ các UA để định tuyến các
request đi ra từ các UA. Các UA thường được cấu hình truyền các request
của nó đến một outbound proxy.
Inbound Proxy : giúp định tuyến các request đi ra từ proxy này trực tiếp đến
UA yêu cầu. Khi 1 inbound proxy nhận một request yêu cầu gởi đến 1 user,
inbound proxy sẽ gởi đến Location Service để xác định contact address của
user đó, sau đó gởi trực tiếp đến user.
6
Hình 1. 3 Proxy Server
1.2.5 Forking
Forking của SIP request có nghĩa là nhiều session media có thể được thực
hiện từ 1 request duy nhất. Đây là 1 tính năng mạnh mẽ của SIP.
Với SIP Forking, bạn có thể đăng ký 1 Address of Record mà có nhiều Contact
Adress trong location service.
Ví dụ:
Address of Record Contact Address
Sip: [email protected] Sip:[email protected]
Sip: [email protected] Sip:[email protected]
Sip: [email protected] Sip: [email protected]
.. …
Khi có 1 request gởi đến inbound proxy để thực hiện cuộc gọi đến John, thì
proxy này tìm thấy các vị trí khác nhau này và đưa ra 1 thuật toán để cố gắng liên
lạc với John ở các vị trí khác nhau. Có 2 thuật toán được sử dụng :
Sequential search (tìm tuần tự) : proxy cố gắng tìm lần lượt từng vị trí, vị trí
này xong đến vị trí khác.
7
Parallel search (tìm song song) : proxy sẽ tìm tất cả các vị trí cùng lúc.
Hình 1. 4 Sequential search (tìm tuần tự)
8
Hình 1. 5 Parallel search (tìm song song)
1.2.6 Redirect Server
Redirect Server là UAS mà nhận các request từ User Agent Clients và tự
động tạo ra các responses gởi đến UAC. Các reponses này luôn luôn hướng dẫn
UAC tạo ra request liên lạc với 1 tập các địa chỉ thay thế.
Hình 1. 6 Ví dụ về Redirect Server
9
1.2.7 Back-to-Back User Agents (B2BUA)
Một B2BUA là một thực thể vật lý (là một server), nhận 1 request, sau đó
tính toán lại request và gởi nó đi dưới dạng 1 request mới. Các Response phản hồi
lại request cũng được tính toán lại và gởi đi theo hướng ngược lại. Nó quản lý từ lúc
bắt đầu cho đến khi kết thúc.
B2BUA được sử dụng để cung cấp những tính năng nâng cao, ví dụ dịch vụ
nặc danh, ẩn thông tin người gọi….
10
CHƯƠNG 2: CÁCH HOẠT ĐỘNG CỦA GIAO THỨC SIP
2.1 MÔ HÌNH HOẠT ĐỘNG CỦA SIP
SIP hoạt động dựa trên sự trao đổi các SIP Messages. SIP Message gồm 2
phần là SIP Request và SIP Response. 1 SIP Request cùng với tất cả SIP Response
kết hợp với nó được gọi là 1 transaction. Cũng tương tự như HTTP, khi bạn kết nối
1 web site, trình duyệt của bạn gởi đi 1 HTTP request bao gồm địa chỉ của trang
web mà bạn muốn nhìn thấy. Server chứa website nhận được request và tạo ra 1
response bao gồm nội dung của trang web và hiển thị trên trình duyệt.
SIP requests bắt đầu từ 1 User Agent Client (UAC) đến 1 User Agent Server
(UAS), SIP responses cũng tương tự nhưng theo cách ngược lại từ UAS đến UAC.
Hình 2. 1 Mô hình hoạt động của SIP
2.1.1 SIP Responses
1 Response là 1 mã trạng thái có 3 chữ số. Số đầu tiên định nghĩa loại
response, số đầu tiên là 1 đó là provisonal response, các số khác được gọi chung là
final response.
Giá trị Ý nghĩa Miêu tả
1xx Provisional Request đã nhận được. Tiếp tục xử lý request
2xx Success Request đã được xử lý thành công.
11
3xx Redirection Redirection được gởi đi khi 1 session được chuyển đến 1
địa chỉ khác.
4xx Client Error Reuqest chứa cú pháp lỗi và không được xử lý ở phía
server.
5xx Server Error Server bị lỗi không xử lý được các request hợp lệ.
6xx Global Failure Request không được xử lý ở bất cứ server nào.
Chữ x đại diện cho 1 con số nào đó từ 0-> 9. Ví dụ : 100, 202,301,…
Không giống như HTTP, trong SIP, 1 request có nhiều response. Bất kỳ
request nào cũng phải có ít nhất 1 final repsonse và có thể có nhiều provisional
responses.
Hình 2. 2 SIP Responses
2.2 SIP Requests
Có 6 loại SIP Request thông dụng : REGISTER, INVITE, ACK, CANCEL,
BYE, OPTIONS.
12
2.2.1 REGISTER
Register request được sử dụng bởi 1 User Agent để thực hiện thủ tục đăng ký. UAC
xây dựng một Register request bao gồm các thông tin sau:
Address of Record (AOR) được biểu diễn dưới dạng 1 SIP URI trong trường
đầu đề To.
Ví dụ :
To : sip:[email protected]
To: John Wales <sip:[email protected]>
Vị trí của người dùng (Contact Address) được biễu diễn dưới dạng 1 SIP
URI trong trường đầu đề Contact.
Ví dụ:
Contact: Sip:[email protected]
Contact: John Wales < Sip:[email protected]>
Ví dụ : John Wales muốn đăng ký để thực hiện trao đổi media. John phải
cung cấp địa chỉ vị trí của mình và gởi đến registrar server để đăng ký. Địa chỉ của
Registrar server cũng được biểu diễn dưới dạng SIP URI như
sip:registrar.university.com.vn
Trong mô hình trên Registrar kết hợp với location service trên cùng 1 server.
Khi đăng ký thành công 1 response phản hồi mã trạng thái 200 OK.
Sự lưu trữ trên Location Server có thời gian tồn tại nhất định, nếu bạn muốn
được lưu trữ theo ý muốn bạn sử dụng trường tiêu đề Expires trong Request
Register. Trường Expires được sử dụng trong tất cả các Request để chỉ ra khoảng
thời gian mà request hay message content là hợp lệ.
Ví dụ:
Expires : 60 (kể từ lúc đăng ký đến 60 giây)
13
Expires: 15 Sep 2013 00:00:00 GMT (hạn dùng là 15 tháng 9 năm 2013)
Hình 2. 3 Ví dụ về đăng ký SIP
2.2.2 INVITE
Một UAC tạo ra 1 INVITE Request để khởi tạo 1 session với một UAS.
Request này có thể được gởi trực tiếp từ UAC đến UAS hay phải qua 1 hay nhiều
proxy mà giúp định tuyến request này.
Một khi UAS nhận được request, nó tạo ra một vài provision response để
thông báo tuyến trình của cuộc gọi. Ví dụ, reponse có mã trạng thái 180 chỉ ra đang
thông báo cho bên được gọi. Nếu bên được gọi đã nhận được, 1 final response có
mã trạng thái 200 OK được tạo ra và phản hồi đến người gọi.
Lưu ý, SIP chỉ truyền tín hiệu giữa bên gọi và bên được gọi, còn việc trao đổi
media stream đó là nhiệm vụ của Real-time Transport Protocol (RTP) và Sesson
Description Protocol (SDP) – các bạn đừng quá lo lắng, RTP và SDP không quá
khó hiểu, chúng ta sẽ tìm hiểu nó trong những chương sau. SIP Request sẽ dính kèm
theo SDP, SDP này được gọi là “SDP offer” . Ví dụ, bạn muốn trao đổi voice hay
video, bên gọi và bên được gọi phải có cùng codecs, bên gọi và bên được gọi cũng
14
phải cung cấp địa chỉ IP, Port để trao đổi media stream. Codec, IP, Port được miêu
tả trong SDP, sau đó RTP có trách nhiệm truyền các media stream.
Ví dụ, Alice muốn thực hiện voice chat đến John, các thông số được kèm theo trong
SDP:
Media types : voice.
Codec : Adaptive Multirate – AMR, Pulse Code Modulation -PCM
IP và Port của Alice để thực hiện voice : 23.17.32.16:4000.
1 final response 200 OK được phản hồi nếu John nhận được thành công, trong
response này cũng chứa 1 SDP của John, SDP này được gọi là “SDP anwser” bao
gồm các thông số sau:
Media types : voice
Codec : PCM (John không có AMR)
IP và Port của John để thực hiện voice là : 45.23.2.5:3000.
Hình 2. 4 Bản tin INVITE trong SIP
Một INVITE request cũng có thể được gởi đi khi một cuộc đối thoại đang
được thực hiện, trong trường hợp này bạn có thể xem INVITE request mới này là 1
re-INVITE. Thông thường re-INVITE được sử dụng để chỉnh sửa hay bổ sung các
thông số của 1 session đang tồn tại. Ví dụ, Alice đang voice chat với John, trong lúc
15
này Alice muốn John mở webcam để thấy mặt nhau. Trong trường hợp này, Alice
phải gởi 1 INVITE mới trong một cuộc đối thoại đang tồn tại để bổ sung vào SDP
thành phần video. SDP thay đổi như sau :
Media types : voice và video
Codecs dành cho voice : AMR
Codecs dành cho video : H.261
IP và Port của Alice để thực hiện voice : 23.17.32.16:4000.
IP và Port của Alice để thực hiện video : 23.17.32.16:4001.
2.2.3 ACK
ACK Request được sử dụng để xác nhận rằng UAC đã nhận được final
response từ 1 INVITE request. Tức là, sau khi UAC nhận được final response, nó sẽ
tự tạo ra 1 request khác để thông báo với UAS rằng UAC đã nhận được final
response, request này được gọi là ACK.
Hình 2. 5 Bản tin ACK trong SIP
16
2.2.4 CANCEL
1 UAC tạo ra 1 CANCEL request để hủy bỏ 1 request đang chờ xử lý. Ví dụ,
Alice gọi John, vì thế UA của Alice tạo ra 1 INVITE requset. Khi INVITE được
nhận bởi UA của John, nó gởi 180 provisional response và bắt đầu thông báo đến
John. John không tiếp nhận cuộc gọi này trong khi Alice vẫn chờ và Alice quyết
định gác máy. Để gác máy, Alice đã gởi 1 CANCEL request đến John. Khi
CANCEL request này được tiếp nhận bởi UA của John, UA sẽ dừng chuông báo và
cuộc gọi được hủy bỏ. UA của John tạo ra 2 response phản hồi CANCEL request :
200 OK response (dành cho CANCEL request) và 487 “Request terminated”
response (dành cho INVITE request).
Hình 2. 6 Bản tin CANCEL trong SIP
BYE Request được sử dụng để kết thúc 1 media session đang được thực
hiện. BYE Chỉ được gởi bởi các UA đang tham gia trong media session. Ví dụ,
Alice và John đang thực hiện voice chat với nhau, một lúc sau Alice (hoặc John)
muốn kết thúc ,cô ấy gởi 1 BYE Request để kết thúc cuộc trò cuộc này.
2.2.5 Options
OPTIONS Request được sử dụng để truy vấn về tính năng thực hiện session
media của 1 UA hay Server , đồng thời khám phá những tính năng có sẵn của nó.
17
OPTIONS được sử dụng khi tìm hiểu các thông tin về phương thức hổ trợ, codec,
….
Hình 2. 7 Bản tin OPTIONS trong SIP
18
CHƯƠNG 3: SIP MESSAGE
SIP là giao thức dựa trên ký tự. Có nghĩa là thông tin được trao đổi bên trong
giao thức được mã hóa dưới dạng chuỗi hay ký tự. SIP messages được chia thành
nhiều dòng ký tự riêng biệt được gọi là line. Mỗi Line là 1 chuỗi các ký tự nối liền
nhau và ngăn cách với line khác bởi 2 ký tự Carriage Return (phím xuống dòng)
và Line Feed (tín hiệu xuống dòng).
Có 2 loại SIP messages : requests và responses. Cả hai loại đều có 1 Start
line, 1 hay nhiều header fields (trường tiêu đề), một empty line – chỉ ra kết thúc của
header fields, và 1 message body.
Hình 3. 1 SIP message
Header fields bao gồm : field name và field value, ngăn cách nhau bởi dấu 2
chấm và kết thúc bằng ký tự xuống dòng.
Ví dụ :
To : sip:[email protected]
Contact: Sip:[email protected]
19
Message body không bắt buộc phải có, chúng được sử dụng để chứa một vài
loại thông tin khác như thông tin SDP,…
3.1 Start line
Trong SIP requests, start line được gọi là request line, nó chứa : tên loại
request (INVITE, BYE, CANCEL,…), Request-URI và protocol version (phiên bản
giao thức SIP) tất cả được tách biệt bằng khoảng trắng. Request-URI là địa chỉ của
user hay server mà request này sẽ gởi đến.
Tên loại request <khoảng trắng> Request-URI <khoảng trắng> Protocol
version
Ví dụ : INVITE sip:[email protected] SIP 2.0
Trong đó:
Loại request là INVITE
Request-URI : sip:[email protected]
protocol version : SIP 2.0
Trong SIP response, start line được gọi là status line (dòng trạng thái), nó bao
gồm : protocol version, status code và một cụm từ diễn đạt status code – reason
phrase. Mỗi thành phần cách nhau bằng 1 ký tự khoảng trắng.
Protocol-version <khoảng trắng> status-code <khoảng trắng> reason phrase
Vi dụ : SIP 2.0 180 Ringing
Trong đó:
Protocol-version : SIP 2.0
Status –code : 180
Reason phrase : Ringing
Dưới đây là 1 bảng miêu tả status code và reason phrase thường thấy trong SIP
20
Status
code
Reason Phrase Status
code
Reason Phrase
100 Trying 302 Moved Temporarily
180 Ringing 305 Use Proxy
181 Call is being forwarded 380 Alternative Service
182 Queued 400 Bad Request
183 Session Progress 401 Unauthorized
200 OK 402 Payment Required
300 Multiole choices 403 Forbidden
301 Moved permanently 404 Not found
405 Method not allowed 485 Ambiguous
406 Not acceptable 486 Busy here
407 Proxy authentication required 487 Request terminated
408 Request time-out 488 Not acceptable here
410 Gone 491 Request pending
413 Reques entity too large 493 undesirable
414 Request-URI too large 500 Internal Server error
415 Unsupported media type 501 Not implemented
416 Unsupported URI scheme 502 Bed gateway
420 Bad extension 503 Service unavailable
412 Extension required 504 Server time-out
423 Interval too brief 505 SIP version not supported
480 Temporarily not available 513 Message too large
481 Call leg/transaction does not
exist
600 Busy everywhere
482 Loop detected 603 Decline
483 Too many hops 604 Does not exist anywhere
484 Address incomplete 606 Not acceptable
21
3.2 Header field
Header field được bắt đầu sau start line trong requests và responses, chúng
cung cấp thông tin về request hay response hoặc message body mà nó chứa. Mỗi
header field bao gồm 1 filename và 1 field value tách biệt nhau bởi dấu : .
Fieldname:fieldvalue
Thứ tự trước sau của các header field trong SIP message không quan trọng.
Ví dụ:
To : sip:[email protected]
Contact: Sip:[email protected]
Hay Contact trước , To sau đều được cả
Contact: Sip:[email protected]
To : sip:[email protected]
Nếu 1 header field có nhiều field value khác nhau thì các field value này
được tách biệt nhau bằng dấu phẩy và thứ tự của chúng rất quan trọng.
Ví dụ :
Route: sip:proxy1.ocean.com , sip:proxy2.ocean.com ,
sip:proxy3.ocean.com
Header fields có thể chứa nhiều tham số (parameter), mỗi tham số bao gồm
tên tham số và giá trị tham số được tách biệt nhau bằng dấu bằng =,tham số này
cách biệt tham số khác hoặc field value bằng dấu chấm phẩy ; .
Fieldname:fieldvalue;parametername = parametervalue
Ví dụ:
From: sip:[email protected];tag=34522549
Về 1 số header field quan trọng.
22
3.2.1 From
From header field chỉ ra địa chỉ của người gọi biễu diễn dưới dạng SIP URI,
được lưu giữ trong location service dưới dạng Address of Record(AOR).
Ví dụ : From: sip:[email protected] ,
From: John Wales <sip:[email protected]>
From header field cũng chứa tham số bắt buộc tag. Tham số tag này được sử
dụng cho mục đích nhận biết 1 dialog ( cuối phần này chúng tôi sẽ giải thích về
Dialog, Call và Transaction).
Ví dụ : From: sip:[email protected];tag=34522549
3.2.2 To
To header field là 1 header field yêu cầu phải có trong mỗi SIP message,
được sử dụng để chỉ ra địa chỉ AOR của người nhận.
Ví dụ: To: sip:[email protected] , To: John Wales <sip:[email protected]>
To header field cũng có tham số tag nhưng không bắt buộc, giá trị của tham
số tag của To header được sử dụng nhận dạng 1 dialog.
Ví dụ : To: sip:[email protected];tag=34522549
3.2.3 Call-ID
Call-ID header field bắt buộc phải có trong tất cả SIP requests và responses.
Nó là một phần của Dialog được sử dụng để nhận dạng Call giữa 2 UA. Call-ID
được tạo ra bởi UA dưới dạng 1 chuỗi kết hợp với tên host hay địa chỉ IP của UA
cách biệt nhau bằng dấu @.
Ví dụ : Call-ID: [email protected]
3.2.4 Via
Via header field ghi lại tất cả địa chỉ host hoặc IP của UA và proxy mà 1
request đi qua, để bắt buộc 1 response trả về cũng phải đi con đường này theo chiều
ngược lại với request. Mỗi khi request đi qua 1 proxy sẽ tạo ra 1 Via địa chỉ proxy
23
này vào message. Còn response sao chép tất cả Via của request, mỗi khi response đi
qua 1 proxy sẽ xóa giá trị Via đầu tiên trong message.
Via header field bao gồm 2 trường:
Trường sent-protocol : chứa giao thức trao đổi gởi message.
Ví dụ : SIP/2.0/UDP , SIP/2.0/TCP,…
Trường sent-by : chứa tên host hoặc địa chỉ IP và port nếu có.
Các tham số dành cho Via:
Received : bổ sung đến Via nếu UA hay proxy mà request đi qua có địa chỉ
IP chỉ là địa chỉ mạng cục bộ. Lúc này, received sẽ chứa địa chỉ IP của NAT
hay firewall proxy, tức là địa chỉ toàn cầu (Internet).
Ví dụ: Via: SIP/2.0/TCP 192.168.1.2; received=12.4.5.50.
Trong đó, 192.168.1.2 là địa chỉ mạng cục bộ nên received chứa địa chỉ IP
của NAT.
Branch : được tính toán từ hàm băm của Request-URI, To, From , Call-ID và
CSeq để nhận biết 1 transaction (cuối phần này chúng tôi sẽ giải thích dialog,
call và transaction).
Ví dụ: Via: SIP/2.0/UDP 5.4.3.2:5060; branch= z9hG4bKl740ws
24
Hình 3. 2 1 ví Message via SIP
3.2.5 Contact
Contach header field được tạo ra bởi UA, và cung cấp một SIP URI để có thể
liên lạc trực tiếp giữa các UA dành cho các request tương lai nhưng phải cùng 1
dialog với request đầu tiên. Điều này có nghĩa, các request tương lai trong 1 dialog
được gởi trực tiếp đến peer UA bởi địa chỉ trong Contact header field.
Ví dụ : Contact: sip:[email protected]
25
Hình 3. 3 1 ví Message Contact SIP
3.2.6 Record-Route và Route
Record-Route header field chứa danh sách các firewall proxy dưới dạng SIP URI
mà request đầu tiên đi qua, được sử dụng để bắt buộc tất cả các request trong tương
lai phải đi qua các firewall proxy có trong danh sách này.
Firewall Proxy không cho phép liên lạc trực tiếp các UA hay các thiết bị
được bảo vệ bởi nó, bắt buộc sự liên lạc phải thông qua nó. Do đó, trong trường hợp
này Contact header field không thể hoạt động được.
Đối với các request kế tiếp, nội dung của Record-Route trong request đầu
tiên sẽ được sao chép lại vào Route header field của request kế tiếp thuộc cùng 1
dialog. Route hoạt động như Record-Route, chỉ khác là Record-Route ghi lại địa chỉ
của các Firewall proxy mỗi khi request đi qua nên nội dung của nó luôn được cập
nhật, còn nội dung của Route không bao giờ được thay đổi trong các request tiếp
theo.
26
Hình 3. 4 Record-Route
3.2.7 CSeq
CSeq header field là 1 header field bắt buộc trong mỗi request. CSeq chứa số
nguyên (gọi là CSeq number) và kiểu request, có sự phân biệt chữ hoa và chữ
thường. CSeq number được khởi tạo ở thời điểm bắt đầu 1 call và được tăng thêm 1
cho mỗi request mới thuộc cùng 1 dialog, ngoại trừ CANCEL và ACK request.
CSeq number được sử dụng để phân biệt 1 request trước đó được truyền lại hay 1
request mới. Kiểu request trong CSeq thể hiện mối tương quan giữa các request và
response trong cùng 1 transaction.
27
Hình 3. 5 Hình biểu diễn CSeq
3.2.8 Max-Forwards
Max-Forwards header field chứa 1 số nguyên dương, được sử dụng để chỉ ra
số bước truyền lớn nhất mà 1 SIP request có thể đi qua. Giá trị của Max –Forwards
sẽ giảm đi mỗi khi request đi qua 1 proxy. Khi proxy nhận request có Max-
Forwards là 0, request bị loại bỏ và gởi 1 reponse “483 Too Many Hops” đến người
gởi.
Ví dụ: Max-Forwards : 70
3.3 SIP Message Body
SIP requests và responses có thể chứa nhiều message body. Message body
thường là 1 SDP chứa các đối tượng: text, image, application, voice, video,..
Message body được chuyển đổi qua lại giữa các UA. Các proxy không được
thêm, xóa, sửa message body.
28
Để tăng khả năng của message body, một số Sip header field được sử dụng:
Content-Type, Content-Length, Content-Encoding.
3.3.1 Content-Type
Content-Type header field được sử dụng để chỉ ra kiểu media trong message
body. Kiểu media có định dạng type/sub-type, nếu header field này không được
miêu tả thì mặc định là application/sdp.
Một số Content-Type thông dụng trong Sip Request và Response :
Content-Type Use
application/sdp SDP dính kèm trong INVITE, ACK hay UPDATE
request
application/xml+dialog XML dialog
application/xml+conf XML conference info
Application/cpim CPIM
text/plain Plain text
text/html HTML text
multipart/mixed Chứa nhiều đối tượng
3.3.2 Content-Length
Content-Length được sử dụng để chỉ ra số các octet (octet là khối dữ liệu có
kích thước 8 bit) trong message body. Content-Length:0 chỉ không có message
body.
Ví dụ : Content-Length: 349
3.3.3 Content-Encoding
Content-Encoding header field được sử dụng để chỉ ra lược đồ mã hóa được
áp dụng cho message body. Điều này cho phép UAS xác định lược đồ giải mã cần
thiết để hiểu được message body.
Ví dụ: Content-Encoding: gzip
29
Hình 3. 6 Content-Encoding
3.4 Mối quan hệ giữa Call, Dialog, Transaction và Message
Message : là chuỗi ký tự riêng lẽ được trao đổi giữa 1 server và 1 client. Có 2
loại message : Request và Response.
Transaction : xảy ra giữa client và server, bao gồm tất cả các message từ
request đầu tiên được gởi từ client cho đến final response được gởi từ server.
Nếu request là INVITE và final request không phải 2xx, thì ACK cũng thuộc
cùng 1 transaction. Ngược lại, ACK dành cho 2xx response là 1 transaction
tách biệt.
Dialog : là mối quan hệ peer-to-peer giữa 2 UA tồn tại 1 thời gian nào đó. 1
dialog được nhận dạng bởi Call-ID, tag của From header field (trong request)
và tag của To header field (trong response).
Call : bao gồm tất cả Dialog có liên quan. 1 call có thể gọi là 1 session.
30
Hình 3. 7 Mối quan hệ giữa Call, Dialog, Transaction và Message
31
CHƯƠNG 4: CẤU TRÚC GIAO THỨC SIP
Giao thức SIP hoạt động dưới dạng một tập hợp các bước xử lý độc lập riêng
lẽ nhau, những bước xử lý này được gọi là Layer (lớp). Chúng ta đã từng biết qua
một vài các giao thức nổi tiếng cũng hoạt động theo mô hình Layer như bộ giao
thức TCP/IP. Tuy nhiên, SIP cũng chỉ là 1 giao thức nằm trong bộ giao thức
TCP/IP, để tránh sự nhầm lẫn với các Layer của TCP/IP nên các Layer của SIP
chúng ta tạm đặt là sublayer (lớp con) , ví dụ Transport layer của SIP thành
Transport sublayer để phân biệt Transport layer của TCP/IP và Transport layer của
SIP.
Các Sublayer của giao thức SIP:
SIP Syntax and encoding : là layer thấp nhất được định nghĩa trong SIP. Nó
là một tập các quy tắc mà định nghĩa về sự định dạng và cấu trúc của mỗi
SIP Message. Nói đơn giản là nó cho các thực thể hiểu và biên dịch các SIP
message. Ví dụ, khi UA nhận được 1 SIP Message, thì UA cần phải biết sự
khác nhau giữa các loại message, các tham số bắt đầu và kết thúc của mỗi
header,... Đó là nhiệm vụ của Syntax and encodeing sublayer.
SIP transport sublayer: nó định nghĩa phía client gởi request và nhận
response như thế nào và phía server nhận request và gởi response như thế
nào thông qua mạng. Tất cả các thực thể SIP đều phải có transport sublayer.
Nó có hai thành phần: phía client gọi là client transport, và phía server gọi là
server transport.
SIP transaction sublayer: là bộ phận chủ yếu của SIP. 1 Transaction được
định nghĩa là một request được gởi từ client đến server và tất cả các reponse
được kết hợp với request này. Nhiệm vụ của transaction sublayer là quản lý
sự truyền lại của tất cả các response liên quan đến request, và thời gian chờ
đợi. Chỉ UA và stateful porxy (chúng ta sẽ tìm hiểu trong phần sau) có
transaction layer. Nó có 2 thành phần: phía client gọi là client transaction và
phía server gọi là server transaction.
32
SIP core sublayer: đó là tất cả các thực thể của SIP : UAC, UAS, registrar,
stateful proxy (chúng ta sẽ tìm hiểu trong phần sau), stateless proxy.
33
CHƯƠNG 5: XÂY DỰNG SIP STACK DÙNG JAIN SIP
5.1 JAIN SIP LÀ GÌ ?
JAIN SIP là Java API Specification dành để phát triển SIP trong môi trường
J2SE. JAIN SIP API là low-level API và cung cấp cho người phát triển ứng dụng
các tính năng sau:
Xây dựng và phân tích SIP Message.
Gởi và nhận SIP Message ở transaction sublayer.
Gởi và nhận SIP Message ở transport sublayer.
Ngoài ra, JAIN SIP API cũng cung cấp tính năng cho SIP Dialog làm cho
người viết ứng dụng dễ dàng truy cập và xử lý SIP Dialog.
5.2 Các bước xây dựng 1 Sip Stack
5.2.1 Các phần mềm và gói phụ thuộc
Trình gỡ rối dùng để thực hiện chương trình là Netbeans phiên bản IDE 8.0
Có thể download Netbeans tại địa chỉ: https://netbeans.org/downloads/
JAIN SIP mã nguồn mở
Link downloand: https://jsip.java.net/
5.2.2 Sip Client
Sip Client có các tính năng sau:
Kết nối 2 peer (máy tính, phone,..) thông qua mạng Internet.
Thực hiện voice chat giữa 2 peer.
5.2.2.1Giao diện phần mềm Sip Client
34
Hình 5. 1 Giao diện Sip Client
Sip port : port thực hiện kết nối dành cho giao thức SIP.
Voice Port : Port thực hiện kết nối để trao đổi Audio.
Button Connect : thực hiện khởi động sẵn sàng kết nối.
Button Disconnect : ngắt kết nối mạng.
Label Initialize : hiển thị thông tin địa chỉ IP và Port của peer. Địa chỉ này
dùng để kết nối 2 peer.
Lable Status : hiển thị trạng thái kết nối.
Destination : là địa chỉ IP mà peer gởi INVITE Request.
Button Yes :
phía client gởi INVITE request ở Client.
phía Server chấp nhận thực hiện voice chat.
Button No:
Phía client hủy bỏ khi đang gởi INVITE, hoặc kết thúc voice chat.
Phía server không chấp nhận thực hiện voice chat, hoặc kết thúc việc
đang thực hiện voice chat.
Tracer : hiển thị nội dung Request và Response.
35
5.2.2.2Các trạng thái
Chúng ta định nghĩa một số trạng thái để thể hiện quá trình chuyển tiếp từ
trạng thái này sang trạng thái khác. Ví dụ, khi peer đang ở giao đoạn sẵn sàng chờ
kết nối - chúng ta đinh nghĩa trạng thái này IDLE. Khi peer đang ở trạng thái IDLE
– client bấm button YES để gởi INVITE , thì client từ trạng thái IDLE chuyển sang
trạng thái WAIT-PRO, còn Server chuyển sang trạng thái RINGING,…
Các trạng thái : IDLE, WAIT_PROV, WAIT_FINAL, ,
WAIT_ACK , RINGING ,ESTABLISHED .
36
Trạng thái Định nghĩa Vào trạng thái Chuyển sang trạng
thái
IDLE HelloPhone sẽ đi
vào trạng thái này
khi user bấm vào
button Connect,
thể hiện trạng thái
sẵn sàng.
-client hoặc
server bấm vào
button No để kết
thúc cuộc gọi.
- Client bấm
button No hủy bỏ
sự chờ đợi phản
hồi từ server.
-client bấm button
YES, client chuyển
sang trạng thái
WAIT_PROV.
-Server nhận được
INVITE , chuyển sang
trạng thái RINGING.
WAIT_PROV HelloPhone phía
client đi vào trạng
thái này khi client
gởi 1 INVITE và
chỉ chuyển sang
trạng thái khác
khi client nhận
được Provisonal
hay Final
Response
Client bấm
button YES khi
đang ở trạng thái
IDLE.
-Client nhận được
Provisonal Response,
chuyển sang trạng thái
WAIT_FINAL.
-Client nhận được
Final Response, client
gởi ACK request,
chuyển sang trạng thái
ESTABLISHED và
bắt đầu truyền và nhận
media.
WAIT_FINAL HelloPhone phía
client đi vào trạng
thái này, khi
client nhận 1
Provisonal
response và được
chuyển trạng thái
Client đang ở
trạng thái
WAIT_PROV thì
nhận được 1
Provisional
Response.
-Client nhận được
Final Response (200
OK), client gởi ACK
request, chuyển sang
trạng thái
ESTABLISHED và
bắt đầu truyền và nhận
37
khi client nhận
được Final
Response
media.
- Server không chấp
nhận cuộc gọi, tạo ra
“486 Busy response”.
Client chuyển sang
trạng thái IDLE.
-Client bấm button
NO để hủy bỏ cuộc
gọi và CANCEL
request được tạo ra.
HelloPhone trở về
trạng thái IDLE
ESTABLISHED Client và Server
phải cùng ở trạng
thái này để thực
hiện cuộc gọi.
- Client nhận
được Final
Response và gởi
đi ACK
Message.
-Server nhận
được ACK
Message.
- client hoặc server kết
thúc cuộc gọi. Cient
và Server trở về trạng
thái IDLE.
RINGING Server đang ở
trạng thái IDLE,
nhận được 1
INVITE request.
Server gởi đi 180
Provisional
Response. Lưu ý,
trong trạng thái
này Server chưa
Server nhận được
1 INVITE và gởi
đi Provisonal
Response.
-Server chấp nhận
cuộc gọi và tạo ra 200
OK response. Server
chuyển sang trạng thái
WAIT_ACK.
- Server không chấp
nhận cuôc gọi và tạo
ra 486 final response.
Server chyển sang
38
chấp nhận cuộc
gọi.
trạng thái IDLE.
-Server nhận được
CANCEL reuqest và
gởi đi 487 response.
Server chuyển sang
trạng thái IDLE.
WAIT_ACK Server đang ở
trạng thái
RINGING và đợi
ACK message để
chuyển sang trạng
thái
ESTABLISTED
Server đang ở
trạng thái
RINGING và
chấp nhận cuộc
gọi, tạo ra 200
OK response.
- Server nhận được
ACK request và
chuyển sang trạng thái
ESTABLISHED.
5.2.3 Sip Proxy
5.2.3.1 Giao diện phần mềm
39
Hình 5. 2 Giao diện Sip Proxy
5.2.3.2 Tính năng
Xây dựng 1 Sip proxy server đơn giản , proxy này có các tính năng sau:
Bao gồm Sip registrar và location service.
Registrar khá đơn giản, nhiệm vụ nhận REGISTER request để đăng ký và
thông tin được cập nhật vào location service.
Chỉ thực hiện tính năng trao đổi riêng lẽ giữa hai peer.
Intant Messaging đơn giản có tính năng chat bằng ký tự giữa 2 peer bởi
sử dụng MESSAGE request.
Tính năng gọi điện giữa 2 client.
40