1.4 Bản tin SIP
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 tiếp, song song tìm kiếm.
Thí dụ
Request-Disposition: redirect 9) Require
Trường header Require được dùng để ghi ra những đặc điểm và phần mở rộng mà UAC yêu cầu UAS hỗ trợ để xử lý yêu cầu. Một đáp ứng 4020 Bad Extension được gửi trả bởi UAS ghi ra những đặc điểm không hỗ trợ trong trường header Unsupported. Nếu các đặc điểm có hỗ trợ và dùng được nhưng lại không được yêu cầu, trường header Supported sẽ được dùng.
Thí dụ
Require: rel100 10)Route
Trường header Route được dùng để cung cấp thông tin tuyến đường đi cho các yêu cầu qua các proxy. RFC 3261 giới thiệu 2 phương pháp định tuyến là: định tuyến cứng và định tuyến tổn thất. Trong định tuyến cứng, proxy phải sử dụng URI đầu tiên trong trường header Route để ghi lại Request-URI, mà sau đó sẽ được chuyển đi. Trong định tuyến tổn thất, proxy không ghi lại Request-URI, nhưng proxy này hoặc là chuyển yêu cầu với URI đầu tiên trong trường header Route, hoặc là nó chuyển yêu cầu tới phần tử định tuyến tổn thất khác. Trong định tuyến tổn thất, yêu cầu phải đi qua mọi server trong danh sách trong header Route trước khi nó được định tuyến dựa vào Request-URI. Trong định tuyến cứng, yêu cầu chỉ phải định tuyến qua các server mà có trong trường header Route với Request-URI được ghi đè lên tại mỗi bước nhảy. Nếu định tuyến là định tuyến tổn thất thì có thêm thơng số lr.
Thí dụ
Route: <sip: proxy@example.com; lr>