1.4 Bản tin SIP
1.4.5.2 Khuôn dạng thỏa thuận (viết tắt) (Compact Form)
SIP cung cấp kỹ thuật thực hiện tên trường header ở dạng viết tắt. Cách này rất hữu ích trong trường hợp mà bản tin cần truyền quá lớn (chẳng hạn khi sử dụng UDP nó vượt quá mức MTU). Dạng thỏa thuận có thể thay thể cho dạng chính tắc của tên trường header tại mọi thời điểm mà không cần thay thế cú pháp của bản tin.
Header Field Compact Form (dạng viết tắt)
Accept – Contact a Allow – Event u Call – ID i Contact m Content – Encoding e Content – Length l Content – Type C Event o From f Subject s
Supported k
To t
Via v
Bảng 1.2 Các dạng viết tắt của mợt sớ trường header1.4.5.3 Các trường header có trong cả yêu cầu và đáp ứng 1.4.5.3 Các trường header có trong cả yêu cầu và đáp ứng
1) Call-ID
Trường header Call-ID là bắt buộc trong tất cả các yêu cầu và đáp ứng. Nó là phần của đối thoại, chỉ được sử dụng để nhận dạng cuộc gọi giữa hai user agent.
Call-ID chỉ xuất hiện giữa các cuộc gọi, trừ trường hợp Call-ID trong yêu cầu đăng kí. Tất cả những đăng kí cho user agent có thể được dùng với cùng Call-ID. Một Call-ID luôn luôn được tạo bởi user agent và không bao giờ được chỉnh sửa bởi server.
Dạng viết tắt của Call-ID là i Thí dụ:
Call – ID: 34a5d55c@192.168.0.1 Call – ID: 44fer23eifd423
Call – ID: 3586638330920312@port34.carrier.com 2) Contact
Trường header Contact được sử dụng để truyền đạt URI mà chỉ định nguồn được yêu cầu hoặc là khởi tạo yêu cầu, điều này phụ thuộc vào việc header này nằm trong yêu cầu hay là đáp ứng. Khi mà một trường header Contact được nhận, thì URI có thể được giấu kín và sử dụng để tìm đường cho u cầu trong một đoạn thoại. Thí dụ, một trường header Contact nằm trong bản tin 200 OK đáp ứng bản tin INVITE có thể cho phép thơng báo bản tin ACK và nhiều yêu cầu khác nữa trong cuộc gọi này để tránh proxy và đi trực tiếp tới bên được gọi. Tuy nhiên, việc có mặt của trường header Record – Route trong yêu cầu trước đó hoặc là trong cấu hình định tuyến tới proxy mặc định trong UA có thể được ưu tiên trong cái hoạt động này.
Các trường header Contact phải có mặt trong bản tin yêu cầu INVITE và đáp ứng 200 OK để thực hiện lời mời. Trường header Contact có thể có trong các đáp ứng 1xx, 2xx, 3xx, và 485.
Chỉ trong yêu cầu REGISTER, mới có dạng đặc biệt Contact: *,với Expires: 0 (mọi thẻ đăng kí đều khơng được chấp nhận). Một trường header Contact có thể chứa tên hiển thị, tên hiển thị thường được để trong dấu ngoặc kép “” (nếu khơng có dấu ngoặc kép thì không đảm bảo việc được gửi đi), trong trường hợp này thì URI sẽ nằm
Thơng thường thơng số được khai báo thêm cho người dùng trong trường header Contact đó là: q, và expires. Chúng nằm sau URI và ngăn cách bởi dấu chấm phẩy “;”. Giá trị thông số q dùng để chỉ thị độ ưu tiên, nó là một số hệ thập phân nằm trong dải từ 0 tới 1. Nếu khơng có thơng số q, thì giá trị q trong danh sách các Contact sẽ mặc định là 1. Nếu có nhiều giá trị trong header Contact thì các giá trị này được ngăn cách bởi dấu “,”.
Header Contact có dạng viết tắt là m Thí dụ
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> ;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1 m: <sips:bob@192.0.2.4>;expires=60
3) CSeq
Trường header CSeq là trường header bắt buộc có trong mọi yêu cầu. Header này bao gồm một số thập phân và một chỉ thị yêu cầu. Phần số thập phân là một số nguyên (nó có giá trị ≤ 231) và nó tăng cho mỗi yêu cầu. Thơng thường nó bắt đầu từ 1 cho mỗi yêu cầu. Trừ yêu cầu CANCEL và ACK, hai yêu cầu này dùng số CSeq của yêu cầu INVITE để làm tham chiếu.
Header này dùng để phục vụ cho các giao tác của đoạn thoại. Nó được dùng để phân biệt yêu cầu mới và yêu cầu đã được truyền. Và nó có duy nhất một giá trị trong một cuộc hội thoại.
Header Nghĩa của header
CSeq: 1 INVITE Số thứ tự lệnh được khởi tạo là 1 cho INVITE khởi tạo CSeq: 432 REFER Số chuỗi lệnh được đặt là 432 cho yêu cầu REFER
CSeq: 7549 INVITE Nếu đây là yêu cầu đầu tiên của user agent cho thoại thì hoặc là CSeq được tạo với giá trị ban đầu là 7549, hoặc là yêu cầu đã được tạo từ trước cho Call-ID này có giá trị là 7548 hoặc nhỏ hơn.
Bảng 1.3. Thí dụ về header Cseq
Mỗi UA duy trì khoảng cách số chuỗi lệnh của riêng nó. Thí dụ, giả sử trường hợp khi mà UA 1 thiết lập phiên tới UA 2 và khởi tạo số CSeq của nó là 1. Khi UA 2 khởi tạo yêu cầu (như là INVITE hoặc là BYE), nó sẽ tính khoảng CSeq của riêng nó, hồn tồn phụ thuộc vào số CSeq được sử dụng bởi UA 1.
Trường header date phản ánh thời gian khi mà yêu cầu hoặc là đáp ứng được gửi đi.
Thí dụ về header Date: Date: Fri, 7 Oct 2008 18:31:00 GMT 5) From
Trường header From là trường header được yêu cầu để chỉ thị việc khởi tạo yêu cầu. Nó được dùng để nhận dạng thoại. Trường header From chứa URI, nó có thể chứa các thơng số URI như là “transport”, “maddr” hoặc là “ttl”. Trường header From có thể chứa một nhãn “tag”, được sử dụng để xác định thành phần gọi. Trường header From có thể chứa tên hiển thị, trong trường hợp này URI đặt trong ngoặc < >. Trường này có dạng viết tắt là f.
Trường header Giải thích
From: <sip:duongtien@doan.com>; tag=7549
Một SIP URI với một nhãn tag From: Thanh Thao
<sip:thao@gmail.com>; tag=4975
SIP URI hiển thị tên f: “Jame Bardeen”
<sip:family24@telephone.com; transport=tcp>; tag= 31705
Dùng dạng viết tắt của trường header, có hiển thị tên trong dấu “” cùng với SIP URI có một thơng số trong <>.
Bảng 1.4 Thí dụ về header From
6) Record-Route
Trường header Record-Route được sử dụng để bắt buộc các tuyến đi phải qua proxy cho tất cả các chuỗi yêu cầu trong phiên giữa 2 UA. Thơng thường, sự có mặt của trường header Contact cho phép các UA gửi bản tin một cách trực tiếp qua các proxy, được dùng trong yêu cầu ban đầu (mà có thể liên quan tới việc tìm kiếm dữ liệu để cấp phát cho phía bị gọi). Proxy chèn địa chỉ của nó vào trong trường header Record-Route nạp chồng lên đó, và bắt buộc các yêu cầu sau phải thực hiện theo tuyến đó, bao gồm trường header Route chứa địa chỉ của proxy mà bắt các proxy này phải tính đến (nạp chồng ở đây là để chiếm quyền ưu tiên).
Một proxy thực hiện chèn thêm URI của nó vào trong trường header Record- Route đang tồn tại. UAS sao chép header Record-Route vào trong đáp ứng 200 OK để trả lời yêu cầu. Trường header này được chuyển đi một cách nguyên vẹn bởi các proxy về UAC. UAC này sau đó chứa danh sách trong header Record-Route ghi thêm vào header Contact, để thực hiện cho đáp ứng 200 OK dùng trường header Route trong tất cả các yêu cầu sau. Do header Record-Route là song hướng, bản tin trong hướng phản
hồi cũng sẽ đi qua các proxy theo thứ tứ ngược lại. Thông số “lr” chỉ thị proxy server hỗ trợ định tuyến tổn thất. Thí dụ Record-Route: <sip:proxy1.carrire.com; lr>, <sip: firewall33.corporation.com; lr> Record-Route: <sip:139.23.1.44; lr> 7) Retry-After
Trường header Retry-After có thể được sử dụng với đáp ứng 500 (Server Internal Error: lỗi do server) hoặc 503 (Service Unavailable: dịch vụ không khả dụng) để chỉ ra dịch vụ mong đợi khơng có giá trị trong bao lâu từ khi Client yêu cầu, và với đáp ứng 404 (Not Found: không tìm thấy), 413 (Request Entity Too Large: thực thể yêu cầu quá lớn), 480 (Temporarily Unavailable: tạm thời không khả dụng), 486 (Busy Here: đang bận), 600 (Busy Everywhere: bận toàn mạng), hoặc là 603 (Decline: từ chối) để chỉ ra khi nào phía bị gọi khả dụng trở lại. Giá trị của trường này phải là một số nguyên giây (hệ thập phân) sau thời gian đáp ứng.
Phần chú thích tùy chọn có thể được dùng để thêm thông tin về thời gian sẽ gọi lại. Thông số tùy chọn này là “duration” chỉ thị sau bao lâu phía bị gọi sẽ có thể bắt đầu với thời gian bắt đầu là có thể chấp nhận được. Nếu khơng có thơng số “duration”, dịch vụ sẽ giả định là đợi tới khi kết thúc thì thơi.
Thí dụ:
Retry-after: 18000; duration=3600 8) Subject
Trường header này cung cấp việc tổng kết hoặc là đặc tính của cuộc gọi, cho phép lọc cuộc gọi mà khơng cần phân tích việc mơ tả phiên. Nó được UA dùng để hiển thị cuộc gọi. Nội dung của trường này có thể hiển thị trong q trình thơng báo, giúp người dùng trong việc quyết định có chấp nhận cuộc gọi hay khơng. Trường này có dạng viết tắt là s.
Thí dụ:
Subject: hoan thanh do an s: co len
9) Supported
Trường header Supported được sử dụng để ghi ra tất cả những phần mở rộng hỗ trợ bởi UAC và UAS
Trường header Supported chứa danh sách các nhãn tùy chọn, nhãn này phải nằm trong danh sách ngăn xếp chuẩn RFC. Nếu để trống, thì nó có nghĩa là khơng có phần mở rộng nào được hỗ trợ. Trường này có dạng viết tắt là k.
Thí dụ:
Supported: rel100
Tag Nghĩa
events SIP Events
join Tham gia điều khiển cuộc gọi gốc
path Trường header path
rel100 Hỗ trợ đáp ứng dự phòng tin cậy (PRACK)
replaces Thay thế điều khiển cuộc gọi gốc
timer đặc điểm bộ đếm thời phiên
Bảng 1.5. Các nhãn mở rộng
10)To
Trường header này dùng để chỉ thị phía nhận u cầu. Nó có cùng cú pháp với trường From. Các đáp ứng và yêu cầu phải có trường header To, chỉ ra phía nhận trong yêu cầu. Bất kỳ đáp ứng nào khởi tạo bởi một UA sẽ chứa trường header này và thêm vào một trường nhãn “tag”. Bất kỳ đáp ứng nào phát sinh bởi proxy cũng phải có một nhãn “tag” thêm vào trường header To.
Header To cho phép hiển thị tên, trong trường hợp này thì URI phải được đặt trong dấu < >. Header To có dạng viết tắt là t.
Thí dụ: trường header To
Trường header Mơ tả
To: sip: babage@engine.org; tag=2443a8f7
Một SIP URI đơn với một nhãn tag và không hiển thị tên
To: Thomas Edison
<sip:edison@electric.com>
Hiển thị tên được dùng, do SIP URI ở trong dấu <>
t: “Jim B”<break@bell.org> Header với dạng viết tắt và hiển thị tên với một SIP URI ở trong dấu ngoặc <>
Bảng 1.6. Thí dụ về header To
11)Via
Trường header Via ghi các tuyến được đưa ra trong yêu cầu, và được sử dụng để đáp ứng lại phía phát. Số nhận dạng (branch ID) trong giá trị trường header Via cấp một số nhận dạng giao dịch và được các proxy sử dụng để phát hiện các vòng lặp.
Các UA tạo yêu cầu ghi địa chỉ của nó trong header Via của yêu cầu. Header này rất quan trọng để tìm đường cho các đáp ứng. Một proxy chuyển tiếp yêu cầu, nó thêm header Via chứa địa chỉ của nó vào đầu danh sách của header Via. Khi proxy thêm header Via, đi kèm với nó là nhãn branch ID. Một UA hoặc là proxy tạo một đáp ứng trả lời yêu cầu, nó sao chép tất cả header Via trong yêu cầu vào trong đáp ứng. Proxy nhận được một đáp ứng, nó sẽ kiểm tra phần đầu danh sách header Via để đảm bảo rằng nó tìm được địa chỉ của nó. Nếu khơng thấy thì đáp ứng đã nhầm đường và do đó nó sẽ bị từ chối. Nếu đúng thì Header Via trên cùng sẽ bị gỡ bỏ và đáp ứng chuyển tiếp tới địa chỉ được chỉ ra trong header Via tiếp theo.
Giá trị trường header Via chứa tên giao thức và phiên bản và giao thức truyền tải được sử dụng để gửi bản tin (thí dụ, SIP/2.0/UDP, SIP/2.0/TCP) , địa chỉ của client hoặc địa chỉ mạng. Có thể chứa cả số cổng mà muốn nhận đáp ứng, các thông số như là “maddr”, “ttl”, “received”, và “branch” (thông số branch phải bắt đầu với con số “z9hG4bK”). Giao thức truyền tải được định nghĩa ở đây là: “UDP”, “TCP”, “TLS”, và “SCTP”. Thông số ”received”sử dụng trong trong đáp ứng tìm đường. Thơng số ”branch” được UA và các proxy thêm vào trong trường header Via để nhận dạng tính duy nhất của phiên. Thơng số ”maddr” và ”ttl” được dùng trong truyền tải multicast.
1.4.5.4 Các header trong yêu cầu
1) Accept
Header Accept được sử dụng để chỉ thị kiểu bản tin phương tiện có thể chấp nhận trong mạng, nó nằm ở phần thân bản tin. Trường header mơ tả các loại hình phương tiện, nó có khn dạng kiểu/kiểu phụ. Nếu khơng có mặt trường này trong bản tin, thì giả định khn dạng thân bản tin có thể nhận là application/sdp. Nó có thể có nhiều kiểu phương tiện cùng với tham số ưu tiên là q. Dấu sao “*” có thể được dùng để khai báo cho tất cả các kiểu phụ.
2) Accept-Encoding
Trường header Accept-Encoding chỉ ra giản đồ mã hóa thân bản tin có thể nhận. Mã hóa được dùng để đảm bảo rằng một bản tin SIP với phần thân bản tin lớn phải thỏa mãn (vừa) dữ liệu đồ UDP(datagram). Thông số q được thiết lập để xác định quyền ưu tiên. Nếu nó khơng được đưa ra, thì giả định mã hóa sẽ là text/plain.
Thí dụ:
Accept-Encoding: text/plain Accept-Encoding: gzip 3) Accept-Language
Trường header Accept-Language, nó dùng để chỉ ngơn ngữ có thể dùng. Phần ngơn ngữ được khai báo có thể dùng cho cụm từ giải thích trong đáp ứng, cho thông tin trường header như là Subject, hoặc là những thân bản tin. Dạng viết tắt của ngôn ngữ được định nghĩa trong chuẩn ISO-693. Header này dùng thông số q cho phép tham chiếu nhiều ngôn ngữ được khai báo với các độ ưu tiên khác nhau.
Thí dụ:
Accept-Language: fr (ngôn ngữ được dùng ở đây là Tiếng Pháp)
Accept-Language: ea; q=0.5, en ;q=0.9, fr; q=0.2 (thứ tự ưu tiên ngôn ngữ dùng là: tiếng Anh, Tây Ban Nha, tiếng Pháp).
4) Call-Info
Trường header Call-Info cung cấp thêm thông tin về chủ gọi và ngược bị gọi, nó phụ thuộc việc nó được tìm thấy trong u cầu hay đáp ứng. Mục đích của URI được chỉ thị bởi thơng số “propose”. Thơng số “icon” chỉ rõ hình ảnh có phù hợp với việc trình diễn của chủ gọi hoặc bên được gọi hay không. Thông số “info” mô tả chủ gọi hoặc là bên gọi nói chung, chẳng hạn như qua trang web.
Thí dụ
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, <http://www.example.com/alice/> ;purpose=info
5) Proxy-Authorization
Trường header Proxy-Authorization cho phép Client nhận thực nó với Proxy. Giá trị trường Proxy-Authorization bao gồm các ủy quyền có chứa thơng tin nhận thực của UA cho Proxy và/hoặc về phạm vi hoạt động của tài nguyên được yêu cầu. Trường header này mang thông tin điều kiện xác nhận về một UA trong một yêu cầu gửi tới server. UA có thể nhận được trả lời là đáp ứng 407 (Proxy Authentication Required: Proxy yêu cầu nhận thực) chứa thông tin yêu cầu. Một proxy khi nhận được một yêu cầu chứa trường header Proxy-Authorization, sẽ tìm kiếm giá trị của nó. Nếu thấy, thì đưa vào xử lý. Nếu xác nhận là đúng, thì tiếp tục duy trì u cầu đó khi mà chuyển tới proxy tiếp theo (hình 1.6).
6) Proxy-Require
Trường header Proxy-Require được dùng để ghi ra các đặc điểm và những phần mở rộng mà user agent yêu cầu proxy hỗ trợ để xử lý yêu cầu. Một đáp ứng 420 Bad Extension (phần mở rộng lỗi) được gửi trả bởi 1 proxy ghi ra các đặc điểm không được hỗ trợ trong trường header Unsupported. Proxy mặc định bỏ qua các trường header và các đặc điểm mà nó khơng hiểu. Trường Proxy-Require là cần thiết để UAC biết chắc
chắn những đặc điểm mà nó khơng hiểu bởi proxy. Trường Support ghi ra những điểm mà proxy hỗ trợ nhưng khơng được u cầu.
Thí dụ
Proxy-Require: timer
Hình 1.6 Nhận thực đa uỷ quyền.
7) Max-Forwards
Trường header Max-Forwards dùng để chỉ thị số bước nhảy tối đa mà bản tin yêu cầu trong SIP có hiệu lực. Giá trị của trường header này giảm khi mà mỗi proxy chuyển tiếp yêu cầu. Proxy nhận được header Max-Forwards mà có giá trị là 0 thì nó sẽ từ chối bản tin và gửi một đáp ứng 483 Too Many Hops (lặp quá nhiều) trở lại phía phát yêu cầu.
Max-Forwards là trường header bắt buộc trong yêu cầu khởi tạo. Giá trị bước nhảy khuyến nghị là 70.
Thí dụ
Max-Forward: 10 8) Request-Disposition
Trường header này dùng để yêu cầu server hoặc là proxy, redirect, khởi tạo nối