SIP消息頭域

爲描述消息基本屬性的通用頭域,可用於請求消息或響應消息;通用頭域的域名只有在協議版本改變時纔可有效地擴展。不過,通信中的所有方均認爲是“通用頭域”的新的頭域也可認爲是通用頭域。不被認可的頭域作爲實體頭域
 
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區分大小寫。
 
請求和響應必須包含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的區別在於多個響應對派生請求的呼叫。
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中的一個定位(尋址)。它也允許被叫方的多個實例發送可以區分的請求。
Via頭域指示請求迄今爲止所走的路徑。它防止了請求的循環,同時確保了響應(回答)沿同樣的路徑返回,這一點可以通過防火牆遍歷和其他的異常路徑情況提供幫助。
 
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頭域所表示的時間
 
對於每一個請求,客戶必須使用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請求之間將含糊不清。
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”的行,沒有版本標識。此加密部分默認爲二進制
 
Expires頭域給出了消息內容活動的日期和時間此頭域只用於INVITE、REGISTER方式。
對於REGISTER方式,它可以用於請求和響應頭域。在REGISTER請求中,它指示登記的有效期限。在響應中,服務器指示所有登記最早的期限時間。服務器可以選擇一個比客戶請求的時間短的時間間隔,但不能比客戶請求的時間長。
對於INVITE方式,他可以用於請求和響應頭域。在INVITE請求中,主叫方可以限制邀請的有效性,例如,客戶希望限制搜尋的期限或者會議邀請的期限。用戶界面可以將此作爲離開屏幕上的邀請窗口的一種暗示,即使用戶目前不在工作站上。這同樣限制了搜尋的期限。如果搜尋在此期限內未完成,代理將返回一個408(Request Timeout)響應。在302響應中,服務器可以建議客戶最大的重定向期限。
 
此域的值可以是一個SIP-date,或者是一個以秒爲單位的數字形式。
Expires = “Expires” “:” (SIP-date | delta-seconds)
 
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參數來包含它們的地址,以便保證隨後的請求能夠準確到達同一個服務器。
Timestamp通用頭域指示客戶何時向服務器發送請求。此頭域的值只對客戶有用。服務器必須回送完全一樣的數值,同時如果它有確切的消息,可以增加一個小數值指示從它接收到請求開始所過去的時間。客戶使用timestamp頭域來計算到達服務器的round-trip時間,以便調整重傳的timeout時間。
Timestamp = "Timestamp" ":" *(DIGIT)[ "." *(DIGIT) ][delay]
Delay     = (DIGIT) [ "." *(DIGIT)]
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頭域。
Accept域用於INVITE、OPTIONS和REGISTER請求方式中,指示在響應中能夠接收的媒體的類型(缺省值爲application/sdp)。
 
Accept-Encoding請求頭域與Accept頭域相似,但它限制在響應中可接受的content-codings。
客戶用Accept-Language請求頭域向服務器指示它接收原因短語、通話描述符或者消息體中所承載的狀態響應時所使用的語言。Proxy可以用此域來幫助選擇呼叫的目的地。
 
 
用於描述消息體內容的長度、格式和編碼類型等屬性,可用於請求消息或響應消息。
實體頭域定義了消息體信息之後的內容(如:Content-Length、Content-Type、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頭域中所列出的編碼。
 
 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連接。
 
Content-Type實體頭域指示發送給接收者的消息體的媒體類型。
Content-Type=(“Content-Type”| “c”)“:”media-type
 
爲請求頭域,只可用於請求消息,它用來傳遞有關請求或客戶機本身的一些附加信息,對請求進行補充說明。客戶將關於請求和關於客戶自己的其他信息傳送給服務器。這些域類似於請求的變量,語義上相當於可編程語言方式調用的參數。請求頭域的擴展與通用頭域相同。
 
 
   Subject請求頭域提供了一個摘要,或者指示了呼叫的實際情況,使得不必分析通話描述便可過濾呼叫。(當然,通話描述不必使用與邀請同樣的標題)
Subject = ("subject" | "s")":"*TEXT-UTF8
User-Agent通用頭域包含了關於發送初始請求的客戶用戶代理的消息。
此頭域用於統計目的,跟蹤違反協議的情況、用戶代理的自動認可的情況,以便在編制響應時避免特定用戶代理的限制。用戶代理應在請求中包含此頭域。
    User-Agent     = "User-Agent" ":" 1*( product | comment )
 
    例如: User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Organization通用頭域表明了發送請求或者響應的實體所屬的組織。它可以由位於某組織邊界的代理來加入。
客戶軟件可以使用此頭域來過濾呼叫。
Organization ="Organization" ":"*TEXT-UTF8
    Contact通用頭域可出現在INVITE、ACK和REGISTER請求中,1XX、2XX、3XX和485響應中。通常,它提供了一個URL,用戶可以通過此URL來進行進一步的通信。INVITE和ACK請求:Contact域表明請求從哪個位置發起;
    這允許主叫方直接向被叫方發送未來的請求,如BYE,而不是通過一系列的代理。由於所想要的地址可能是代理的地址,所以只Via頭域並不夠。
客戶通過一個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域,因爲他們可能是被路由器或者代理故意增加的。
Proxy-Authorization請求頭域允許客戶向要求驗證的代理來鑑別自己。
Proxy-Authorization頭域的值由信任組成,此信任包含了用戶代理向代理提供的驗證信息和/或被申請的資源領域(realm of the resource requested)。
Proxy-Authorization = "Proxy-Authorization" ":" credentials
與Authorization不同,
Proxy-Authorization頭域只應用於使用Proxy-Authenticate域要求驗證的下一個輸出的代理。
當有多個代理時,Proxy-Authorization頭域被接受信任的第一個輸出代理所使用。
一個代理可以將信任從客戶請求通過中繼傳到下一個代理,這種方式可以作爲一種代理之間合作驗證一個給定請求的機制。
Proxy-Require頭域用來指示代理必須支持的一種特徵,即是否需要代理。如果不支持,對於客戶,任何Proxy-Require頭域特徵必須被代理所否定。代理服務器將此域與Require域等同看待。
 
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”解得的)。
 
客戶使用Require請求頭域,通知UAS客戶希望服務器所支持的選項,以便合適地處理請求。如果服務器不能識別此選項,它必須返回420(Bad Extension)響應,在Unsupported頭中列出它不能識別的選項。
Require = “Require” “:” 1#option-tag
代理和重定向服務器必須忽略不可識別的特徵。如果一個特定的擴展名需要中介設備支持,那麼此擴展名必須在Proxy-Require域中標記。
 
 
Priority請求頭域指示了客戶所認爲的請求的緊急程度。
Priority ="Priority" ":" priority-value
priority-valur="emergency"|"urgent"|"normal"
                |"non-urgent"
推薦:值"emergency"僅用於生命,肢體,財產處於即將來臨的危險之中時使用(此頭域通常與Subject頭域聯合使用)
 
客戶使用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")
 Route請求頭域決定了請求的路由。每一個主機將刪除第一個入口,然後將此請求代理到那個入口所列的主機處,將它作爲Request-URI。
 
Route =” Route” “:” 1#name-addr
 
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
 
爲響應頭域,只可用於響應消息,它用來傳遞有關響應的附加信息,對響應進行補充說明,如有關服務器的信息和需要作出的下一步動作的提示等;允許服務器發送關於響應的無法放在Status-Line中的其他信息。這些頭域給出了關於服務器和關於進一步訪問由Request-URL指示的資源的信息。響應頭域的擴展與通用頭域相同。
Proxy-Authorization請求頭域允許客戶向要求驗證的代理來鑑別自己。
Proxy-Authorization頭域的值由信任組成,此信任包含了用戶代理向代理提供的驗證信息和/或被申請的資源領域(realm of the resource requested)。
 
Proxy-Authorization = "Proxy-Authorization" ":" credentials
 
與Authorization不同,Proxy-Authorization頭域只應用於使用Proxy-Authenticate域要求驗證的下一個輸出的代理。當有多個代理時,Proxy-Authorization頭域被接受信任的第一個輸出代理所使用。一個代理可以將信任從客戶請求通過中繼傳到下一個代理,這種方式可以作爲一種代理之間合作驗證一個給定請求的機制。
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的記錄。
 
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]
 
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頭域。
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(混雜的警告)
Allow實體頭域列出了Request-URI指示的資源所支持的方式集。此域的目的是通知接收者與資源相聯繫的有效方式。在405(Method Not Allowed)響應中必須有Allow頭域;在OPTIONS響應中應該有Allow頭域。
Allow = “Allow”“:” 1#Method
 
Unsupported響應頭域列出了服務器不支持的特徵。(只用於420響應)
 Unsupported = “Unsupported” “:”1#option-tag
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章