1 general-header類： 為描述消息基本屬性的通用頭域，可用于請求消息或響應消息；通用頭域的域名隻有在協定版本改變時才可有效地擴充。不過，通信中的所有方均認為是“通用頭域”的新的頭域也可認為是通用頭域。不被認可的頭域作為 實體頭域。 1.1 Call-ID Call-ID通用頭域唯一辨別一個特定的請求或者一個特定客戶的所有登記。 來自同一個客戶的所有的登記應該使用同樣的 Call-ID 頭值，至少是在同一個重新啟動的循環中。注意到單個的多媒體會議會産生不同Call-ID的幾個呼叫，例如，使用者多次邀請一個單個的私人加入同一個會議。 對于一個INVITE請求。主叫方使用者代理伺服器不應該警告使用者，如果使用者先前已經對INVITE請求中的Call-ID 作出了響應。如果使用者已經是會議的一個成員，同時包含在會話描述中的會議參數并未改變，那麼主叫方使用者代理伺服器可以接受此呼叫，而不管Call-ID。對于一個已存在的Call-ID或者會話的邀請可能改變會議的參數。一個客戶應用可以決定向使用者簡單地訓示會議參數已經改變，可以自動接受邀請或者可能需要使用者的确認。 使用幾個不同的Call-ID可以邀請一個使用者加入同一個會議或者呼叫。如果需要的話，可以使用在會話描述中的辨別來檢測此副本。例如，SDP的“o”域中包含了會話辨別和版本号。 REGISTER和OPTIONS方式使用Call-ID值來精确比對請求和響應。一個單個的客戶釋出的所有的REGISTER請求應該使用同一個Call-ID，至少在同一個有效循環中。 Call-ID = (“Call-ID” | “i”)”:”local-id”@”host Local-id = 1*uric i 是Call-ID 的縮寫形式。 “host”應該是一個真正的域名或者是一個全球性的IP位址。如此，”local-id”應該是一個由URI字元組成的辨別，此辨別在”host”中是唯一的。 建議使用經過加密的随機辨別。Call-ID的值禁止被重用于另一個不同的呼叫。Call-ID區分大小寫。 1.2 From 請求和響應必須包含 From通用頭域，訓示請求的初始者。From域可以包含一個"tag"參數。伺服器将From頭域從請求複制到響應。可選的"display-name"意味着由使用者接口提出（執行）。如果客戶身份被隐藏，那麼系統必須使用顯示名"Anonymous"。 此SIP-URL禁止包含"transport-param"，"maddr-param"，"ttl-param"，"headers"。接收到含有以上元素的SIP-URL的伺服器在執行下一步處理之前，應将這些元素删除。 即使"display-name"是空的，如果"addr-spec"包含了"，"、"？"、"；"，"name-addr"形式也必須使用。 From = （"From" | "f" ）" ：" （name-addr | addr-spec ） * （" ；"addr-params ） addr-params=tag-param tag-param="tag="UUID UUID=1* （hex | "-" ） "tag"可以出現在一個請求的From頭域中， 當共享同一個 SIP 位址的使用者的兩個執行個體使用同一個Call-ID 發出邀請時，必須使用此"tag" 。 "tag"必須是全球唯一的，并且是一個經過加密的至少32比特的随機數。一個單個的使用者應該在一個Call-ID所辨別的整個呼叫中保持同一個tag。 Call-ID、To和From用于辨別一個Call leg。呼叫和Call-leg的差別在于多個響應對派生請求的呼叫。 1.3 To To通用頭域說明了請求的接收者。 To = （"To" | "t" ）" ：" （name-addr | addr-spec ） * （" ；"addr-params ） 請求和響應必須包含To頭域，訓示請求的預定接收者。可選的"display-name"意味着由使用者接口提出（執行）。UAS或者重定向伺服器将To頭域的内容複制到它的響應中，同時 如果請求包含了不止一個 Via 頭域，則必須增加"tag" 參數。 如果Via頭域不止一個，那麼表明請求至少經過一個代理伺服器的處理。因為接收者不知道此請求是哪一個代理伺服器派生的請求，是以從安全方面考慮， 可認為它們都派生了請求。 此SIP-URL禁止包含"transport-param"，"maddr-param"，"ttl-param"，"headers"。接收到含有以上元素的SIP-URL的伺服器在執行下一步處理之前，應将這些元素删除。 "tag"參數作為一種通用機制，用于區分由一個SIP-URL辨別的使用者的多個執行個體。因為代理可以派生請求，是以同一個請求可以到達使用者的多個執行個體（例如：移動和住宅電話）；又由于每一個都可以響應，是以必須有一種方法來區分來自被叫方每一個執行個體的響應。這種情況也可由于多點傳送（多點傳播）請求而産生。"tag"參數用于區分UAC的響應。當請求有可能被一中間件代理派生時，每一個執行個體都必須在它的響應中包含"tag"參數。"tag"參數必須可以被UAS、登記器和重定向伺服器增加，但禁止被加入到上傳的響應中。"tag"參數可以增加到所有方式的所有已經定義的響應中，也可以加入到來自UAS或者重定向伺服器的報告性（1xx）響應。兩個實體間随後所有的事務都必須包含"tag"參數。 當響應與請求相比對時，如果請求的To域中未包含"tag"參數，那麼響應To域中的"tag"參數将忽略。"tag"允許代理派生同一個呼叫的未來的請求，而隻對幾個可能的響應UAS中的一個定位（尋址）。它也允許被叫方的多個執行個體發送可以區分的請求。 當SIP伺服器接收到一個請求，此請求的To域中含有它不能識别的URI時，它應該傳回一個400（Bad Request）響應。 即使"display-name"是空的，如果"addr-spec"包含了"，"、"？"、"；"，"name-addr"形式也必須使用。 Call-ID、To和From用于辨別一個Call leg。呼叫和Call-leg的差別在于多個響應對派生請求的呼叫。"tag"允許代理派生同一個呼叫的未來的請求，而隻對幾個可能的響應UAS中的一個定位（尋址）。它也允許被叫方的多個執行個體發送可以區分的請求。 1.4 Via Via頭域訓示請求迄今為止所走的路徑。它防止了請求的循環，同時確定了響應（回答）沿同樣的路徑傳回，這一點可以通過防火牆周遊和其他的異常路徑情況提供幫助。 1.5 Contact Contact通用頭域可出現在INVITE、ACK和REGISTER請求中，1xx、2xx、3xx和 485響應中。通常，它提供了一個URL，使用者可以通過此URL來進行進一步的通信。 INVITE和ACK請求：Contact域表明請求從哪個位置發起； 這允許主叫方直接向被叫方發送未來的請求，如BYE，而不是通過一系列的代理。由于所想要的位址可能是代理的位址，是以隻 Via頭域并不夠。 l INVITE 2xx響應：一個使用者代理伺服器在發送一個限定的、肯定的響應（2xx）時，可以加入一個Contact響應頭域，表明對于未來的請求它可 以直接到達的SIP位址，如ACK請求。Contact頭域包含了伺服器自己或者代理的位址，例如主機在一個防火牆之後。 如果響應未包含 Record-Route頭域 ，此 Contact 的值将複制到此呼叫的後來的請求的Request-URI 中；如果響應包含了Record-Route頭域 ， Contact 域的值将作為最後一項增加到Record-Route 域中。Contact的值不應該通過呼叫被緩沖，因為它可能不能表示一個特殊目的地位址的最想要的位置。 l INVITE 1xx響應：一個UAS發送一個臨時的響應（1XX）可以插入一個Contact響應域。語義同2XX INVITE響應。注意到CANCEL請求禁止被發送到那個位址（Contact所訓示的），但仍跟随初始請求的路徑。 l REGISTER request：REGISTER請求中的Contact域表明使用者的位置。REGISTER請求定義了一個通配的Contact域。“*”，隻能用于：0删除一個使用者所有的登記。一個可選的“expires”參數訓示登記所想要的期限。如果Contact未使用此參數，則Contact域的值将使用預設值。 如果這些機制都未采用，SIP URL的期限為一個小時。其他的URL沒有期限時間。 l REGISTER 2xx響應：一個REGISTER響應可以傳回可以達到的使用者的所有位址。 l 3xx和485響應：Contact頭域訓示一個或多個可選的位址。可以出現在對于INVITE、BYE和OPTIONS方式的響應中。Contact頭域包含的URI給出了新的位置和使用者名，或者簡單地說明其他的傳輸參數。 300 （Multiple Choise ）、301(Moved Permanently) 、302(Movec Temporarily)或者 485(Ambiguous)響應應該包含一個含有可嘗試的新位址的URL的Contact域。301和302響應可以給出正在嘗試的同樣的位置和使用者名， 但指定了其他的傳輸參數，如一個不同的伺服器或者多點位址，或者一個從TCP到UDP，UDP到TCP的SIP事務的改變。客戶将Contact URL中的“user”、“password”、“host”、“port”、“user-param”複制到重定位請求的Request-URL中，同時使用tranport參數中的傳輸協定，将此請求傳到“maddr”和“port”參數所說明的位址處。如果“maddr” 是一個多點位址，“ttl”值表明time-to-live值Contact頭域可能訓示一個不同于原始呼叫實體的實體。例如，與GSTN網關相連的SIP呼叫可能需要發送一個特殊的消息通知。Contact頭域可以包含任何合适的URL來訓示被叫方的位置，而不隻限于SIP URL。 Contact=(“Contact” | “m”)”:” (“*” | (1#((name-addr | addr-spec)[*(“;”contact-params)][comment]))) name-addr=[display-name]”<”addr-spec”>” addr-spec=SIP-URL | URI display-name=*token | quoted-string contact-param= “q” “=”qvalue | “action” ”=””proxy”
| ”expires” “=”delta-seconds | <”>SIP-date<”> | extension-attribute extension-attribute = extension-name [“=”extension-value] l q：表明所給的位置的相對重要性，“qvalue”從0到1，值高參考性大。 l action：隻用于使用REGISTER登記時。表明是否客戶希望伺服器代理或者 重定向使用者想要的未來的請求。 l expires：表明URI的活動時間。 注意與 Expire 頭域的聯系：如果Contact 中存在expires 參數，則使用其表示的時間；若不存在，則使用Expire 頭域所表示的時間。 1.6 Cseq 對于每一個請求，客戶必須使用Cseq（Command sequence）通用頭域。此頭域包含了請求方式和一個提出請求的客戶所標明的十進制序列數，在同一個Call-ID中此Cseq值唯一。此序列數必須為一個32位的無符号整數，它的初始值是任意的，但必須小于等于2**31。連續的請求在請求方式、頭域和消息上是不同的，但有同樣的Call-ID，它們的Cseq也必須是嚴格單調增加的相鄰的序列數；序列數不能形成環。重傳請求有相同的Cseq，但消息體或者頭域不同的INVITE請求需要一個新的更高的Cseq。伺服器必須在它的響應中回送請求中的Cseq。如果在所接收的Cseq頭域中沒有method，伺服器應該正确的填充。 ACK和CANCEL請求必須包含與它們相聯系的INVITE請求同樣的Cseq。而當BYE請求釋放一個請求時必須含有以更高數值的Cseq。如果BYE請求中的Cseq值不高，那麼将産生一個400（Bad Request）響應。 使用者代理伺服器必須記住同一個Call-ID的INVITE請求的最高序列數。對于包含較低序列數的任何INVITE請求，伺服器必須作出響應，然後放棄。 所有在并行搜尋中産生的請求擁有和觸發此并行搜尋的請求一樣的Cseq值。 Cseq ="Cseq" " ：" 1*DIGIT Method 對于任何可以被BYE或CANCEL請求取消的SIP請求，或者對于客戶發送了連續的幾個同一個Call-ID的請求的情況，都需要使用Cseq頭域。如果沒有序列值，對于INVITE請求的響應将會和對于取消（BYE、CANCEL）的響應相混淆。同樣，如果網絡複制了消息包，或者一個ACK請求耽擱了直到伺服器發送了另一個響應，客戶應該将此舊的響應作為對于一個之後很快重傳的邀請的響應。使用Cseq頭域，也可以幫助伺服器區分邀請的不同版本，而不用比較消息體。 "Method"值使得客戶将對于INVITE請求的響應和對于一個CANCEL請求的響應（一般是200響應）區分開來。代理可以産生CANCEL請求；如果代理增大序列數，那麼有可能與同一呼叫中使用者代理以後發送的請求發生沖突。 派生的請求必須有同樣的Cseq值，否則在這些派生的請求和客戶使用者代理以後所發送的BYE請求之間将含糊不清。 1.7 Encryption Encryption= “Encryption” “:””pgp”pgp-eparams pgp-eparams=1#(pgp-version | pgp-encoding) pgp-encoding=”encoding””=””ascii” | token encoding：描述PGP所使用的encoding或者“armor”，“ascii”表示标準的 PGP ASCII包裹，沒有包含“BEGIN PGP MESSAGE”和“END PGP MESSAGE”的行，沒有版本辨別。 此加密部分預設為二進制。 1.8 Expires Expires 頭域給出了消息内容活動的日期和時間 。此頭域隻用于INVITE、REGISTER方式。 對于REGISTER方式，它可以用于請求和響應頭域。在REGISTER請求中，它訓示登記的有效期限。在響應中，伺服器訓示所有登記最早的期限時間。伺服器可以選擇一個比客戶請求的時間短的時間間隔，但不能比客戶請求的時間長。 對于INVITE方式，他可以用于請求和響應頭域。在INVITE請求中，主叫方可以限制邀請的有效性，例如，客戶希望限制搜尋的期限或者會議邀請的期限。使用者界面可以将此作為離開螢幕上的邀請視窗的一種暗示，即使使用者目前不在工作站上。這同樣限制了搜尋的期限。如果搜尋在此期限内未完成，代理将傳回一個 408 （Request Timeout ）響應。在 302 響應中，伺服器可以建議客戶最大的重定向期限。 此域的值可以是一個SIP-date，或者是一個以秒為機關的數字形式。 Expires = “Expires” “:” (SIP-date | delta-seconds) 1.9 Record-Route Record-Route請求和響應頭域可以被任何伺服器加到請求中，這些伺服器堅持以後的同一個Call leg的請求使用同樣的路徑。它包含了一個唯一可達的Request-URI來訓示代理伺服器。每一個代理伺服器将它的Request-URI加到序列的開始。 伺服器将Record-Route頭域不做改變地複制到響應中。（Record-Route隻和2xx響應有關）主叫方UAC将Record-Route頭複制到随後的同一個呼叫分支（Call leg）的請求的 Route頭域中，隻是颠倒了請求的順序，以使第一個入口離UAC最近。如果響應包含了一個 Contect頭域，主叫方的使用者代理将它（Contact）的内容作為最後一個 Route域的内容。除非這将引起環路，否則任何使用者必須将任何随後的同一個呼叫分支（Call leg）請求發送到Route頭域的第一個Request-URI中，同時删除此入口。 呼叫方使用者代理禁止在包含有Route 頭域的請求中使用Record-Route 頭域。 一些代理，例如那些控制防火牆或者在一個自動呼叫配置設定（ACD）系統中，需要保持呼叫狀态，這樣就需要接收任何一個此呼叫的BYE和ACK包。 Record-Route = “Record-Route” “:” 1#name-addr 代理伺服器應該使用“maddr”URL參數來包含它們的位址，以便保證随後的請求能夠準确到達同一個伺服器。 1.10 Timestamp Timestamp通用頭域訓示客戶何時向伺服器發送請求。此頭域的值隻對客戶有用。伺服器必須回送完全一樣的數值，同時如果它有确切的消息，可以增加一個小數值訓示從它接收到請求開始所過去的時間。客戶使用timestamp頭域來計算到達伺服器的round-trip時間，以便調整重傳的timeout時間。 Timestamp = "Timestamp" ":" *(DIGIT)[ "." *(DIGIT) ][delay] Delay = (DIGIT) [ "." *(DIGIT)] 1.11 Date Date是一個通用頭域，文法形式如下： Date = "Date" ":" HTTP-date 此處，HTTP-date隻能是rfc1123-date。 rfc1123-date = wkday "," SP date1 SP time SP "GMT" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" (GMT) ：Greenwich Mean Time 例如： Date： Tue, 15 Nov 1994 08:12:31 GMT 當請求或者響應被第一次發送時，Date頭域訓示發送日期和時間，是以，重傳将使用與相應的初始同樣的Date頭域。 1.12 Accept Accept域用于INVITE、OPTIONS和REGISTER請求方式中，訓示在響應中能夠接收的媒體的類型（預設值為 application/sdp）。 1.13 Accept-Encoding Accept-Encoding請求頭域與Accept頭域相似，但它限制在響應中可接受的content-codings。 1.14 Accept-Language 客戶用 Accept-Language請求頭域向伺服器訓示它接收原因短語、通話描述符或者消息體中所承載的狀态響應時所使用的語言。Proxy可以用此域來幫助選擇呼叫的目的地。 2 entity-header類： 用于描述消息體内容的長度、格式和編碼類型等屬性，可用于請求消息或響應消息。 實體頭域定義了消息體資訊之後的内容（如：Content-Length、Content-Type、Content-Encoding），或者如果沒有消息體，則定義請求所訓示的資源。 2.1 Content-Encoding Content-Encoding=(“Content-Encoding” | “e”)”:” 1#content-coding Content-Encoding實體頭域作為“media-type”的一個修飾語。它的值訓示适用于實體消息體的其他的内容編碼，訓示為了獲得 Content-Type頭域所給出的media-type，必須使用的編碼方案。Content-Encoding主要用于壓縮消息體，而不丢失它底層的媒體類型的辨別。 如果多個編碼适用于一個實體，那麼内容便必須按照他們被應用的順序列出。 所有的Content-Encoding值都區分大小寫。 客戶可以将内容編碼應用于請求消息體中。如果伺服器不能對消息體解碼，或者不能識别任何的Content-Encoding值，它必須發送一個 415 “Unsupported Media Type ”響應，在 Accept-Encoding頭域中列出可以接受的編碼。 伺服器可以将内容編碼應用于請求消息體中，但它隻能使用請求的 Accept-Encoding頭域中所列出的編碼。 2.2 Content-Length Content-Length實體頭域訓示消息體的長度。形式上以八個比特為一個位元組。 Content-Length = (“Content-Length” | “l”)”:” 1*DIGIT 應用程式應該使用此域來訓示所傳送的消息體的大小，而不管實體所用的媒體類Content-Length的值應為非負數，0表示沒有消息體。 l 伺服器如果收到一個不包含Content-Length域的UDP請求，那麼它便認為此請求壓縮了包的剩餘部分。 l 伺服器如果收到一個包含有Content-Length域的UDP請求。但它的值比消息體的實際長度大，客戶則應産生一個 400 類的響應。 l 在UDP包中，如果接收完消息體的最後一個比特後，還有其他的資料，伺服器必須将此資料視為另一個消息。也就是說，允許在一個UDP包中包含有多個消息。 l 如果一個響應中未包含Content-Length，客戶便認為此響應壓縮了UDP包或者資料的剩餘部分，直到關閉TCP連接配接。 2.3 Content-Type Content-Type實體頭域訓示發送給接收者的消息體的媒體類型。 Content-Type= （“Content-Type ”| “c ”）“：”media-type 3 request-header類： 為請求頭域，隻可用于請求消息，它用來傳遞有關請求或客戶機本身的一些附加資訊，對請求進行補充說明。客戶将關于請求和關于客戶自己的其他資訊傳送給伺服器。這些域類似于請求的變量，語義上相當于可程式設計語言方式調用的參數。請求頭域的擴充與通用頭域相同。 3.1 Subject Subject請求頭域提供了一個摘要，或者訓示了呼叫的實際情況，使得不必分析通話描述便可過濾呼叫。（當然，通話描述不必使用與邀請同樣的标題） Subject = （"subject" | "s" ）" ："*TEXT-UTF8 3.2 User-Agent User-Agent通用頭域包含了關于發送初始請求的客戶使用者代理的消息。 此頭域用于統計目的，跟蹤違反協定的情況、使用者代理的自動認可的情況，以便在編制響應時避免特定使用者代理的限制。使用者代理應在請求中包含此頭域。 User-Agent = "User-Agent" ":" 1*( product | comment ) 例如： User-Agent: CERN-LineMode/2.15 libwww/2.17b3 3.3 Organization Organization通用頭域表明了發送請求或者響應的實體所屬的組織。它可以由位于某組織邊界的代理來加入。 客戶軟體可以使用此頭域來過濾呼叫。 Organization ="Organization" " ："*TEXT-UTF8 3.4 Contact Contact通用頭域可出現在INVITE、ACK和REGISTER請求中，1XX、2XX、3XX和485響應中。通常，它提供了一個URL，使用者可以通過此URL來進行進一步的通信。INVITE和ACK請求：Contact域表明請求從哪個位置發起； 這允許主叫方直接向被叫方發送未來的請求，如BYE，而不是通過一系列的代理。由于所想要的位址可能是代理的位址，是以隻Via頭域并不夠。 3.5 authorization 客戶通過一個 Authorization 頭來重新測試請求。 Authorization = “Authotization ”“：”“pgp ” * （“；”pgp-response ） pgp-response = realm | pgp-version | pgp-signature | signed-by | nonce pgp-signature = “signature ”“= ”quoted-string signed-by = “signed-by ”“= ”<”>URI <”> 使用者必須在重新送出此請求之前增加 CSeq頭。此表示必須與請求的From頭相聯系，除非提供了signed-by參數。 pgp-signature：由ASCII碼包裹的PGP辨別，出現在“BEGIN PGP MESSAGE”和“END PGP MESSAGE”之間，沒有版本辨別。如果重新侵入并不擔心的話，伺服器可以不産生nonce。不産生nonce避免了增加其他形式的請求，401響應和可能的ACK消息，也減少了round-trip時間的耽擱。 使用ASCII碼包裹的版本，與包含二進制的信号相比，減少了25%的空間使用率，但對于接收者将它們組合到一起來說卻很容易。一般信号為200比特長。PGP信号機制允許客戶簡單地将請求傳給一個外部的PGP程式。此依賴于代理伺服器不允許改變頭域的順序或者頭域内容的這麼一種需要。 realm：複制于相關的WWW-Authenticate頭域的參數。 signed-by：當且僅當請求未被From域的實體所标記時，signed-by訓示所标 記的實體的名稱，表現為一個URI。 标記了的SIP消息地接收者應該丢棄任何在Authorization域之上的end-to-end域，因為他們可能是被路由器或者代理故意增加的。 3.6 Proxy-Authorization Proxy-Authorization請求頭域允許客戶向要求驗證的代理來鑒别自己。 Proxy-Authorization頭域的值由信任組成，此信任包含了使用者代理向代理提供的驗證資訊和/或被申請的資源領域（realm of the resource requested）。 Proxy-Authorization = "Proxy-Authorization" ":" credentials 與Authorization不同， Proxy-Authorization頭域隻應用于使用Proxy-Authenticate域要求驗證的下一個輸出的代理。 當有多個代理時，Proxy-Authorization頭域被接受信任的第一個輸出代理所使用。 一個代理可以将信任從客戶請求通過中繼傳到下一個代理，這種方式可以作為一種代理之間合作驗證一個給定請求的機制。 3.7 Proxy-Require Proxy-Require頭域用來訓示代理必須支援的一種特征，即是否需要代理。如果不支援，對于客戶，任何Proxy-Require頭域特征必須被代理所否定。代理伺服器将此域與 Require域等同看待。 3.8 Response-Key Reponse-Key =”Response-Key””:””pgp”pgp-eparams pgp-eparams = 1#(pgp-version | pgp-encoding | pgp-key) pgp-key = “key””=”quoted-string 如果ASCII編碼通過編碼參數來請求，key參數則包含了使用者的公共密鑰（從pgp key ring用“pgp –kxa user”解得的）。 3.9 Require 客戶使用 Require請求頭域，通知UAS客戶希望伺服器所支援的選項，以便合适地處理請求。如果伺服器不能識别此選項，它必須傳回 420 （Bad Extension ）響應，在 Unsupported頭中列出它不能識别的選項。 Require = “Require” “:” 1#option-tag 代理和重定向伺服器必須忽略不可識别的特征。如果一個特定的擴充名需要中介裝置支援，那麼此擴充名必須在 Proxy-Require域中标記。 3.10 Priority Priority請求頭域訓示了客戶所認為的請求的緊急程度。 Priority ="Priority" " ：" priority-value priority-valur="emergency"|"urgent"|"normal" |"non-urgent" 推薦：值"emergency"僅用于生命，肢體，财産處于即将來臨的危險之中時使用（此頭域通常與Subject頭域聯合使用） 3.11 Hide 客戶使用Hide請求頭域來訓示：它希望對随後的代理和使用者代理隐藏Via頭域訓示的路徑。此頭域的使用有兩種形式：Hide:route和Hide:hop。Hide頭域通常由客戶使用者代理來增加，但也可以由發送路徑上的任何代理增加。 如果一個請求包含了"Hide:route"頭域，所有緊跟的代理應該隐藏它們先前的hop。如果請求包含了"Hide:單腳跳"頭域，隻有下一個代理應該隐藏它先前的hop，然後删除此Hide選項，除非它也想要保持匿名。 伺服器通過使用它所選擇的算法，對最頂端的Via頭域的"host"和"port"部分加密，來隐藏先前的hop。伺服器應該在加密之前向"host"和"port"資訊中添加附加資訊"salt"，( //原譯有誤：伺服器應該将另外的"salt" 增加到已經經過加密的"host" 和"port"中)，以防止下傳路徑中可能有惡意的代理基于相同的已加密的Via頭域來猜測路徑的前面部分。被隐藏的Via域用"hidden"Via選項來标記。 能夠隐藏Via域的伺服器必須試圖（也能夠）将所有标記了"hidden"的Via域解密，以便執行回路檢測。不能隐藏Via域的伺服器可以在它們的回路檢測算法中忽略被隐藏的Via域。 需要注意的是：如果被隐藏的頭域未被辨別，代理需要将所有的頭域都解密，來檢測回路，以防止其中被加密的頭域，例如Hide:Hop，可能在發送的路徑上被删除了。 主機禁止增加諸如"Hide:hop"的頭域，除非它能確定将一個到此目的地的請求發送到相同的下一個hop。原因是請求可能會從一個下傳的代理通過相同的hop回傳回來。如果下一個hop的選擇已固定（調整），此回路應經過下一個hop的檢測，但（回路）也可以循環任意多次。 對于請求"Hide:route"的客戶來說，如果它将此請求發送到一個可信任的代理處，那麼它隻需要将請求路徑保密（私有）。如果資料包中的請求結果直接在主叫/被叫二者的使用者代理之間交換，那麼隐藏請求路徑也是有限的。 除非确實需要将路徑保密，否則最好不要使用Hide頭域；Hide域的使用給代理增加了額外的處理開銷和限制，同時可能産生482(Loop Detected)響應，這種情況在未使用Hide 頭域時可以避免。 Hider 頭域有如下文法定義： Hide = "Hide" ":" ("route" | "hop") 3.12 Route Route 請求頭域決定了請求的路由。每一個主機将删除第一個入口，然後将此請求代理到那個入口所列的主機處，将它作為Request-URI。 Route =” Route” “:” 1#name-addr 3.13 Max-Forwards Max-Forwards請求頭域适用于任何請求方式，用來限制前轉請求的代理或者網關的數目。當客戶跟蹤一個出現了錯誤或者循環的請求鍊時，也可以使用此頭域。 Max-Forwards="Max-Forwards"" ：" 1*DIGIT Max-Forwards值表明了此請求消息允許被前轉的剩餘次數。 對于接收到包含有Max-Forwards頭域的請求的代理或者網關來說，它必須檢測并且修改此頭域先前的值，以便前轉此請求。如果域值是0，那麼接收者禁止前轉此請求。相反，對于OPTIONS和REGISTER方式的請求來說，它（接收者）必須将自己作為最終的接收者來作出響應。對于其他的方式，伺服器應傳回483（Too many hops）響應。 如果接收到的Max-Forwards域值大于0，那麼前轉的請求中的Max-Forwards域的值必須應減1 4 response-header類： 為響應頭域，隻可用于響應消息，它用來傳遞有關響應的附加資訊，對響應進行補充說明，如有關伺服器的資訊和需要作出的下一步動作的提示等；允許伺服器發送關于響應的無法放在Status-Line中的其他資訊。這些頭域給出了關于伺服器和關于進一步通路由Request-URL訓示的資源的資訊。響應頭域的擴充與通用頭域相同。 4.1 Proxy-Authenticate Proxy-Authorization請求頭域允許客戶向要求驗證的代理來鑒别自己。 Proxy-Authorization頭域的值由信任組成，此信任包含了使用者代理向代理提供的驗證資訊和/或被申請的資源領域（realm of the resource requested）。 Proxy-Authorization = "Proxy-Authorization" ":" credentials 與Authorization不同，Proxy-Authorization頭域隻應用于使用Proxy-Authenticate域要求驗證的下一個輸出的代理。當有多個代理時，Proxy-Authorization頭域被接受信任的第一個輸出代理所使用。一個代理可以将信任從客戶請求通過中繼傳到下一個代理，這種方式可以作為一種代理之間合作驗證一個給定請求的機制。 4.2 WWW-Authenticate WWW-Authenticate=”WWW-Authenticate””:””pgp”pgp-challenge pgp-challenge=*(“;”pgp-params) pgp-params=realm | pap-version | pgp-algotithm | nonce realm=”realm””=”realm-value realm-value=quoted-string pgp-version=”version””=” <”>digit*(“.”digit)*letter<”> pgp-algorithm=”algorithm””=”(“md5” | ”sha1” | token ) nonce=”nonce””=”nonce-value nonce-value=quoted-string realm：顯示給使用者的一個字元串，以使使用者知道使用哪一個身份。此字元串應該至少包含執行驗證的主機名，也可以另外表示可能接入的使用者的收集。一個例子是“Users with call-out privileges” pgp-algotithm：此參數的值表明了用于産生辨別（信号）的PGP消息完整性檢驗方法（MIC）。預設為“md5”。“md5”表示MD5檢驗碼，“sha1”表示SHA.1算法。 pgp-version：PGP的版本，客戶必須使用。通常的值時“2.6.2”和“5.0”，預設為5.0。 nonce：一個經過說明的伺服器資料串，每當産生一個 401響應時，此資料串便被唯一産生。建議使用base64或者十六進制的資料串。此nonce的内容是獨立實作的。其實作的品質依賴于一個好的機會。因為nonce隻用于阻止重新的侵入，是以對于伺服器就友善來說，單元中的一個時間标記就已足夠。由于在呼叫建立周期中的重新侵入隻有有限的作用，是以幾秒鐘的時間标記通常應該是足夠的，在此情況下，伺服器并不保留此nonce的記錄。 4.3 Retry-After Retry-After頭域用在 503 （Service Unavailable ）響應中，向提出申請的客戶訓示，此服務預計多長時間無效。用在 404 （Not Found ）,600(Busy) 和603 （Decline ）響應中，訓示被叫方多長時間内再次有效。此域的值可以是SIP-date和以秒為機關的整數值。 REGISTER請求用“Contact: *; expires:0”删除登記時可以使用Retry-After頭域。此時，Retry-After域值訓示使用者多長時間内可以再次可達。注冊伺服器器對未來的呼叫作出響應時可以包含此消息。可以使用一個commend選項來訓示關于重新呼叫的其他消息。“duration”選項參數訓示從有效的初始時間開始，多長時間内被叫方有效可達。 Retry-After = ” Retry-After” ”:” (SIP-date | delta-seconds) [comment] [“:” “duration””=”delta-seconds] 4.4 Server Server響應頭域包含了關于UAS用來處理請求的軟體的資訊。 Server = "Server" ":" 1*( product | comment ) product = token ["/" product-version] product-version = token 例如: Server: CERN/3.0 libwww/2.17 product：所使用的伺服器； comment：伺服器中的重要部分。 如果響應通過代理來前轉，那麼代理禁止修改此Server響應頭域，它應該包含一個Via頭域。 4.5 Warning Warning響應頭域中包含了關于響應狀态的其他資訊。 Warning = "Warning""：" 1#warning-value Warning-value = warn-code SP warn-agent SP warn-text Warn-code = 3DIGIT Warn-agent = （host["："port]） | pseudonym Warn-text = quoted-string 一個響應中可以有多個Warning頭域。 "warn-text"使用自然語言。 任何一個伺服器都可以在響應中加入Warning頭。代理伺服器必須将Warning頭域加在任何一個Authorization頭域之前，由于此限制，Warning頭域必須加在任何已存的未被signature覆寫的Warning域之後。代理伺服器禁止删除它所接收到的響應中的任何Warning頭域。 當響應中有多個Warning頭域時，使用者代理應該盡可能将它們按照在響應中出現的順序都顯示出來。如果不能全部顯示，使用者代理應顯示在響應中出現的較早的警告。 "warn-code"包含了三個數字，第一個數字"3"表示SIP的專用警告。 下面列出已定義的警告，需要注意的是：所有的警告都由通話描述引起。 300--329：通話描述中的關鍵字出現的問題； 330-339：通話中所申請的基本網絡業務相關的警告； 370-379：通話描述中所申請的定量的QoS相關的警告； 390-399：不屬于以上所述類型的警告的混雜。 300：不相容的網絡協定； 301：不相容的網絡位址格式； 302：不相容的傳輸協定； 303：不相容的帶寬單元； 304：無效的媒體類型； 305：不相容的媒體格式； 306：無法識别的屬性； 307：無法識别的通話描述參數； 330：無效的多點傳送；（使用者位置不支援多點傳送） 331：無效的單點傳送；（使用者位置不支援單點傳送，通常是由于防火牆的 存在） 370：無效的帶寬；（帶寬數超過允許範圍） 399：混雜的警告；（接收到此警告的系統禁止自動采取措施） 10 ：Response is stale（舊的響應）當響應是舊的時，必須包含。 11 ：Revalidation failed（重新生效失敗）由于重新發送響應失敗，隻 能傳回舊的響應時，必須包含。 12 ：Disconnected operation（非連接配接操作） 13 ：Heuristic expiration（探索逾時） 14 ：Transformation applied（已用過的事務） 99 ：Miscellaneous warning（混雜的警告） 4.6 Allow Allow實體頭域列出了Request-URI訓示的資源所支援的方式集。此域的目的是通知接收者與資源相聯系的有效方式。在 405 （Method Not Allowed ）響應中必須有Allow頭域；在OPTIONS響應中應該有Allow頭域。 Allow = “Allow ”“：” 1#Method 4.7 Unsupported Unsupported響應頭域列出了伺服器不支援的特征。（隻用于420響應） Unsupported = “Unsupported ” “：”1#option-tag
![網絡空間安全中高職業院校職技能大賽——Telnet弱密碼滲透測試[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)