II. So sỏnh chuyển mạch mềm và chuyển mạch truyền thống
4.3. Trường tiờu đề trong bản tin SIP
Cỏc trường tiờu đề của SLP giống nh cỏc trường tiờu đề của HTTP về cả cỳ phỏp vế ngữ nghĩa. Cỏc trường tiờu đề khỏc cú thể được bổ sung khi cú yờu cầu. Proxy khụng loại bỏ hoặc thay đổi cỏc trường tiờu đề mà khụng được định nghĩa trong đặc tả này.
1. Trường tiờu đề chung (general-header)
Cỏc trường tiờu đề chung ỏp dụng cho tất cả cỏc bản tin yờu cầu và bản tin đỏp ứng Cỏc tờn trường liờu đề chung cú thể được mở rộng khi kết hợp với sự thay đổi về phiờn bản giao thức. Tuy nhiờn, trường tiờu đề mới hoặc đang thử nghiệm cú thể cú nghĩa nh cỏc trường tiờu đề chung nếu tất cả cỏc bờn trong phiờn truyền thụng đều nhận biết được chỳng là cỏc trường tiờu đề chung. Cỏc trường tiờu đề chung khụng nhận biết được xử lý nh cỏc trường tiờu đề thực thể (entity-header).
2. Trường tiờu đề thực thể(entity-header)
Cỏc trường tiờu đề thực thể định nghĩa siờu thụng tin về thõn bản tin hoặc nếu thõn bản tin khụng cú mặt thỡ nú thể hiện cỏc tài nguyờn dể định danh theo yờu cầu. Thuật ngữ "entity-header" là thuật ngữ của HTTP/1.1 , ở dú thõn của đỏp ứng cú thể chứa phiờn bản thay đổi của thõn bản tin. Thõn của bản tin ban dầu được gọi là "thực thể" (entity).
3. Trường tiờu đề yờu cầu (reqllesl-header)
Cỏc trường ticu đề yờu cầu cho phộp Client chuyển qua cỏc thụng tin bổ sung cho yờu cầu và cỏc thụng tin về Client đến Server. Cỏc trường này hoạt động
nh cỏc bộ thay đổi theo yờu cầu với nghĩa tợng trng nh cỏc tham số của ngụn ngữ lập trỡnh.
4. Trường tiờu đề đỏp ứng (response-header)
Cỏc trường tiờu đề đỏp ứng cho phộp Server bỏ qua cỏc thụng tin bổ sung về đỏp ứng khi khụng thể dặt trong trạng thỏi dờng dõy (status-line). Cỏc trường tiờu đề này đưa ra thụng tin về Server và về cỏc truy nhập xa hơn đến tài nguyờn được định danh bởi Requesl-URI.
Tuy nhiờn, trường tiờu đề mới hoặc dang thử nghiệm cú thể cú nghĩa nh
trường "Response-hẹader" nếu tất cả cỏc bờn trong phiờn truyền thụng đều nhận biết được chỳng là cỏc trường “response-header". Cỏc trường tiờu đề khụng nhận biết được xử lý nh cỏc trường tiờu đề thực thể.
5. Cỏc tiờu đề end-to-end vàhop-by-hop
Cỏc tiờu đề end-to-end phải được phỏt đi mà khụng cú sự khỏc nhau nào qua tất cả cỏc Proxy, trong khi tiờu đề hop-by-hop cú thể thay đổi hoặc bổ sung tại cỏc Proxy.
6. Khuụn dạng trường tiờu đề (header-field-fonnal)
Cỏc trường tiờu đề kể trờn (general-header, request-header, response-header, và entity-header) đều cú khuụn dạng giống nhau. Chúng bao gồm tờn trường, theo sau bởi dấu ":" và giỏ trị của trường. Khuụn dạng của trường tiờu đề bản tin:
message-header = field-name ":" [ field-value ]CRLF field-name = token
field-value = * (field-content / LWS)
field-content = < Là cỏc Octet cấu thành field'value và hoặc là *TEXT-UTF8 hoặc là cỏc tổ hợp token, separators và quoted-string >
7. Tiờu đề chấp nhận (Accept)
Khi khụng chấp nhận tiờu đề hiện cú tức là cú sự xuất hiện của trường Accept, Server sẽ phỏt đi một giỏ trị mặc định của ứng dụng sdp. Vớ dụ:
accept: application/sdp; lever = 1 , application/x-private, text/html
8. Tiờu đề Accept-encoding
Trường tiờu đề yờu cầu Accept-encoding cũng giống nh tiờu đề Accept và biểu diễn sự chấp nhận của đỏp ứng.
Cỳ phỏp phần tiờu đề ngụn ngữ chấp nhận quy định về lệnh trong ngụn ngữ dựa vào tham số ỏp dụng vào SLP tết như thế nào. Trường tiờu đề yờu cầu Accept- language cho phộp Client thụng bỏo cho Server ngụn ngữ nú mong muốn để nhận reason-phrases, miờu tả phiờn hay mó trạng thỏi được truyền tải bởi thõn bản tin. Một Proxy cú thể sử dụng trường này để trợ giỳp việc lựa chọn đớch đối với cỏc cuộc gọi.
10. Tiờu đề cho phộp (Allow)
Trường tiờu đề thực thể (entity-header) liệt kờ tập hợp cỏc chỉ thị được hỗ trợ bởi tài nguyờn định nghĩa bởi yờu cầu URL. Mục đớch của trường này là thụng bỏo đến người nhận cỏc chỉ thị giỏ trỡ kết hợp với tài nguyờn một cỏch chớnh xỏc. Trường tiờu đề Allow cú mặt trong đỏp ứng 405 và trong đỏp ứng Options.
Allow = "Allow" ":" l#method
11. Tiờu đề cho phộp (Allthorization)
UAS muốn xỏc định bản thõn mỡnh với mỏy chủ sau khi nhận được đỏp ứng 401, nú cú thể làm điều này bằng cỏch đa trường tiờu đề yờu cầu Authorization vào một yờu cầu. Giỏ trị trường Authorization bao gồm cỏc ủy nhiệm chứa thụng tin cho phộp UAS biết phạm vi hoạt động của tài nguyờn đó được yờu cầu.
12. Tiờu đề Call-ID (chỉ số cuộc gọi)
Trường tiờu đề chung Call-ID xỏc định một lời mời thành viờn hoặc tất cả cỏc đăng ký của một Client thành viờn một cỏch duy nhất. Chỳ ý rằng một hội nghị đa phương tiện đơn giản cú thể thờm vài cuộc gọi với cỏc Call-ID khỏc nhau, nếu người sử dụng mời nhiều lần khỏc nhau đến cựng một hội nghị.
Đối với một yờu cầu INVITE, một UAS bị gọi khụng nờn cảnh bỏo với người sử dụng đú nếu người sử dụng đó đỏp ứng lại Call-ID trong yờu cầu INVRRE. Nếu người sử dụng đó là một thành viờn của hội nghị và cỏc tham số của hội nghị đó được chứa trong một miờu tả phiờn khụng cú thay đổi thỡ UAS bị gọi này cú thể chấp nhận cuộc gọi bất chấp Call-ID. Một lời mời cho Call-ID hoặc
phiờn hiện tại cú thể thay đổi cỏc tham số của hội nghị. Một ứng dụng của Client cú thể đa ra một chỉ thị đơn giản tới người sử dụng về cỏc tham số của hội nghị đó được thay đổi và chấp nhận cuộc gọi tự động hoặc nú cú thể yờu cầu người sử dụng xỏc nhận.
Một người sử dụng cú thể được mời đến cựng một hội nghị hoặc cuộc gọi sử dụng nhiều Call-id khỏc nhau. Client cú thể loại phỏt hiện những bản sao này bằng cỏch nú sử dụng cỏc nhận dạng trong miờu tả phiờn.
Chỉ thị Register (đăng ko và Option (tựy chọn) sử dụng giỏ trị Call-id để yờu cầu được giống hoàn toàn với đỏp ứng. Tất cả cỏc yờu cầu Register đa ra bởi một Client phải cú cựng một Call-ld.
Khuụn dạng:
Call-id = ( "Call-ld"I"i" )":"local-id"@"host Local-id = 1 *uric
13. Tiờu đề giao dịch (Contact)
Trường tiờu đề chung Contact cú thể xỏc nhận trong yờu cầu INVITE, ACK, Register và trong đỏp ứng lxx, 2xx, 3xx và 485. Nó cung cấp URL để người sở dụng cú thể cú cỏc giao tiếp xa hơn. Cỏc yờu cầu INVITE và ACK cú thể chứa tiờu đề Contact để chỉ ra vị trớ khởi tạo yờu cầu.
Đỏp ứng INVITE lxx: Một UAS gửi một đỏp ứng lxx cú thể chốn vào tiờu đề đỏp ứng Contact. NÃ cũng cú ý nghĩa nh đỏp ứng lxx và đỏp ứng LNVITE 2xx. Chú ý rằng yờu cầu CANCEL khụng được gửi đến địa chỉ đú.
Đỏp ứng LNVITE 2xx: Một Server gửi một đỏp ứng 2xx cú thể chốn vào một tiờu đề đỏp ứng Contact để chỉ ra vị trớ SIP trong cựng một Call-ID. Trường tiờu đề Contact chứa địa chỉ của Server hoặc Proxy, nếu trạm ở phớa sau tường lửa. Giỏ trị tiờu đề được sao chộp vào trường Request-uri của yờu cầu tiếp theo cho cuộc gọi nóy. Nếu đỏp ứng khụng chứa tiờu đề Record-route thỡ địa chỉ trong
trường tiờu đề Contact được bổ sung nh phần tử cuối cựng trong trường tiờu đề route.
Yờu cầu Register: Yờu cầu Register cú thể chứa trường tiờu đề Contact, nú chỉ ra vị trớ người sử dụng cú thể đến. Yờu cầu Register định nghĩa trường "*" chỉ được sử dụng với expire "O" để loại bỏ tất cả cỏc đăng ký người sử dụng đặc biệt. Một tham số expire tựy chọn chỉ ra thời gian kết thỳc của đăng ký. Nếu Contact nào khụng cú tham số expire thỡ trường tiờu đề expire được sử dụng nh giỏ trỡ mặc định.
Đỏp ứng 2xx Register: Một đỏp ứng Register cú thể quay về tất cả cỏc vị trớ mà người sử dụng hiện tại cú thể đạt đến. Một tham số expire mặc định chỉ ra thời gian kết thỳc của đăng ký.
Đỏp ứng 3xx và 485: Trường tiờu đề đỏp ứng Contact cú thể sử dụng chung với mó đỏp ứng 3xx và 485 để chỉ ra một hoặc nhiều địa chỉ thay thế. Nó cú thể xuất hiện trong cỏc chỉ thị BYE, INVITE, OPTLON. Trường tiờu đề Contact chứa URL đưa ra vị trớ mới hoặc tờn của User để thử hoặc cú thể là cỏc tham số truyền bổ sung đặc biệt.
Đỏp ứng 300, 301, 302, 485 chứa trường Contact với địa chỉ URL mới. Client sao chộp cỏc phần tử "user", "password", "hoạt", "port" và "user param" của Urlcontact vào URL yờu cầu định hướng yờu cầu đền địa chỉ dặc tả bởi tham số "maddr" và "port", sử dụng giao thức truyền tải trong "transport param". Một trường tiờu đề đỏp ứng Contact cú thể chứa bất kỳ URI thớch hợp để chỉ ra bị gọi nào cú thể đạt được, khụng hạn chế đến SLP-URL.
Cỏc tham số sau được định nghĩa:
- q: giỏ trị q chỉ ra u tiờn tơng đối giữa vị trớ cho trước (O<q< 1 ), q càng lớn độ ưu tiờn càng cao.
- Action: tham số này được sử dụng khi đăng ký với yờu cầu Register. Nếu tham số này khụng được đặc tả thỡ hoạt động xảy ra phụ thuộc vào cấu hỡnh Server,
khi đú trong cỏc đỏp ứng của nú, cỏc bản sao nờn chỉ ra chế độ được sử dụng. Tham số này khụng được chỳ ý trong cỏc yờu cầu khỏc nhau.
- Expire: tham số expire chỉ ra thời gian hiệu lực của URL.
14. Tiờu đề mó húa nội dung (Content-Encoding)
Giỏ trị của trường tiờu đề thực thể Content-encoding chỉ ra cỏc mó húa phự hợp được ứng dụng trong phần thõn bản tin, vỡ vậy cơ chế giải mó phải được ứng dụng để đạt được kiểu truyền thụng trong trường tiờu đề Content-type. Nếu nhiều mó húa được dựng trong bản tin thỡ mó húa phải được sắp xếp phự hợp theo thứ tự chỳng được dựng.
Client cú thể dựng mó húa Content và phần thõn của yờu cầu. Nếu Server khụng cú khả năng mó húa phần thõn hoặc phần khụng thể nhận biết được bất kỳ giỏ trị Content-encoding nào, thỡ nú phải gửi đỏp ứng 415, liệt kờ cỏc mó húa cú thể chấp nhận trong.tiờu đề Accept-encoding. Một Server cú thể ỏp dụng Content- encoding vào phần chớnh trong cỏc đỏp ứng. Server chỉ được sử dụng cỏc mó húa dó liệt kờ trong tiờu đề Accept-encoding trong yờu cầu.
15. Tiờu đề dộ dài nội dung (Content-length)
Giỏ trị trường tiờu đề Contenl-length chỉ ra kớch cỡ phần chớnh của bản tin. Là số Octet tớnh theo thập phõn gửi đến phớa nhận. Cỏc ứng dụng nờn dựng trường này để chỉ ra kớch cỡ phần chớnh của bản tin đó truyền đi, bất kể kiểu phương tiện gỡ của thực thể.
Giỏ trị Content-length > 0 đều được sử dụng giỏ trị bằng khụng khi phần thõn trong bản tin khụng cú). Nếu Server nhận yờu cầu UDP cú trường Content- length, mà giỏ trị của nú lớn hơn kớch cỡ của phần thõn bản tin gửi trong yờu cầu, thỡ Client tạo ra đỏp ứng 400. Nếu cú dữ liệu bổ sung trong gói UDP sau khi byte cuối cựng của thõn bản tin được đọc thỡ Server phải xử lý phần dữ liệu nh bản tin riờng. Điều này cho phộp nhiều bản tin được đặt trong cựng một gúi UDP. .
Giỏ trị trường tiờu đề Content-type chỉ ra kiểu truyền thụng của thõn bản tin gửi đến phớa nhận.
17. Tiờu đề Cseq
Cseq do chớnh Client bổ sung vào mỗi yờu cầu. Trường tiờu đề Cseq trong thõn bản tin yờu cầu chứa chỉ thị yờu cầu và số lượng chuỗi được chọn theo yờu cầu của Client, với một giỏ trị Call-ID. Số lượng chuỗi phải là một số nguyờn khụng dấu 32 bịt.
Giỏ trị khởi tạo của nú là tựy ý nhưng phải nhỏ hơn 231. cỏc yờu cầu ACK và CANCEL phải chứa cựng giỏ trị Cseq nh ưtrong yờu cầu INVITE trong khi yờu cầu BYE với Cseq khụng cao hơn sẽ tạo ra đỏp ứng 400.
Một Server của UAS phải nhờ số lượng chuỗi cao nhất đối với bất kỳ yờu cầu LNVLTE nào trong cựng giỏ trị với Call-ID, Server phải đỏp lại bất kỳ yờu cầu LNVLTE nào với cựng một số lượng chuỗi thấp hơn.
18. Tiờu đề thời gian (Da te)
Là một trường tiờu đề chung phản ỏnh thời gian khi yờu cầu hoặc đỏp ứng được gửi đi lần đắu. Vỡ vậy, cỏc bản tin truyền đạt cú cựng giỏ trị trường tiờu đề dữ liệu nh bản tin đầu tiờn.
19. Tiờu đề mó húa (Ellcryptioll)
Trường tiờu đề mó húa chung đặc tả nội dung được mó húa. Trường tiờu đề này thường sử dụng cho cỏc yờu cầu và cỏc đỏp ứng end-to-end (đầu cuối tới đầu cuối). Yờu cầu được mó húa dựa trờn khua cụng khai của thực thể gọi là trường tiờu đề "To".
Đỏp ứng được mó húa dựa trờn khúa cụng khai truyền trong trường tiờu đề khúa đỏp ứng Chỳ ý rằng bản thõn khúa cụng khai khụng được sử dụng để mó húa. Điều này phụ thuộc vào từng thuật toỏn được sử dụng.
Đối với bất kỳ bản tin đó được mó húa nầo, thỡ ít nhất cú phần thõn bản tin và cú thể cỏc trường tiờu đề khỏc được mó húa để giải mó thõn bản tin, sau đú thực
hiện ghộp bản tin ban đầu đến đường dõy yờu cầu và đến cỏc tiờu đề của bản tin ban đầu. Tiờu đề bản tin trong phần đó giải mó thay thế hoàn toàn tiờu đề bản tin trong phần bản tin ban đầu với cỏc trường cú cựng tờn.
Mó húa chỉ để cung cấp sự bớ mật: phớa đớch khụng dỏm bảo rằng yờu cầu hoặc đỏp ứng từ phớa gửi được liệt kờ trong tiờu đề bản tin From mà phớa đớch chỉ đảm bảo rằng phớa gửi sử dụng khúa cụng khai của phớa đớch. Tuy nhiờn, cỏc Proxy khụng cú khả năng thay đổi yờu cầu hay đỏp ứng.
Vỡ cỏc Proxy cú thể dựa vào sự quy định trước của chỳng để kết hợp bất kỳ trường tiờu đề SIP nào nờn khụng cú sự đảm bảo rằng cỏc yờu cầu dó mó húa cú cỏc trường tiờu đề "ẩn" (hi de) sẽ cựng đến đớch như cỏc yờu cầu khụng mó húa được định danh khỏc nhau.
20. Tiờu đề thực thể ( Expires)
Trường tiờu đề thực thể expire đa ra thời gian và ngày mà nội dung bản tin sẽ hết hiệu lực. Trường này chỉ được định nghĩa trong chỉ thị Register và INVITE.
Đối với Register: NÃ là trường tiờu đề đỏp ứng và yờu cầu trong bản tin Register, Client chỉ ra đăng ký giỏ trị trong bao lõu. Trong đỏp ứng Server chỉ ra thời gian hết hiệu lực sớm nhất của cỏc đăng ký. Server cú thể lựa chọn khoảng thời gian ngắn hơn trong yờu cầu từ Client nhưng khụng nờn lõu hơn.
Đối với INVLTE: Nó là trường tiờu đề đỏp ứng và yờu cầu. Trong một yờu cầu, chủ gọi cú thể hạn chế giỏ tớt của yờu cầu, vớ dụ Client cú thể hạn chế khoảng thời gian tỡm kiếm một yờu cầu hội nghị.
21. Tiờu đề xuất phỏt (Froln)
Cỏc đỏp ứng và yờu cầu phải cú trường tiờu đề chung From để chỉ ra bộ khởi đầu yờu cầu. Server sao chộp trường tiờu đề From từ yờu cầu vào đỏp ứng. Trường From cú thể cú tham số "Tag". Khi cần thiết nú cú thể trỡnh bày 2 trường đặc biệt của người sử dụng chia sẻ một địa chỉ SIP cú thể tạo cỏc yờu cầu gọi ứng với cựng một Call-ID. Giỏ trị "Tag" trong suất một cuộc gọi dó định danh bằng Call-ID.
22. Tiờu đề ẩn (Hide)
Client sử dụng trường tiờu đề yờu cầu "hide"để chỉ ra rằng nú muốn tuyến bao gồm tiờu đề Via được ẩn khi qua cỏc Proxy và Agent người sử dụng. Nó cú thể cú 2 dạng: Route Hide và Hop Hide.
Trường tiờu đề Hide cú thể được bổ sung bởi Agent sử dụng Client, cũng cú thể bởi Proxy dọc theo cỏc tuyến dờng. Nếu một yờu cầu chứa trường tiờu đề Route Hide thỡ tất cả cỏc Proxy phớa sau nờn ẩn cỏc chặng trước đú của chỳng. Nếu một yờu cầu chứa "Hide-hop" thỡ chỉ Proxy tiếp theo sẽ ẩn hop trước dú và sau đú loại