SIP 消息頭域的說明(轉(zhuǎn))1 general-header類：為描述消息基本屬性的通用頭域，可用于請求消息或響應(yīng)消息；通用頭域的域名只有在協(xié)議版本改變時才可有效地擴(kuò)展。不過，通信中的所有方均認(rèn)為是“

SIP 消息頭域的說明(轉(zhuǎn))

1 general-header類：

為描述消息基本屬性的通用頭域，可用于請求消息或響應(yīng)消息；通用頭域的域名只有在協(xié)議版本改變時才可有效地擴(kuò)展。不過，通信中的所有方均認(rèn)為是“通用頭域”的新的頭域也可認(rèn)為是通用頭域。不被認(rèn)可的頭域作為實體頭域。

1.1 Call-ID

Call-ID 通用頭域唯一標(biāo)識一個特定的請求或者一個特定客戶的所有登記。來自同一個客戶的所有的登記應(yīng)該使用同樣的Call-ID 頭值，至少是在同一個重新啟動的循環(huán)中。注意到單個的多媒體會議會產(chǎn)生不同Call-ID 的幾個呼叫，例如，用戶多次邀請一個單個的私人加入同一個會議。

對于一個INVITE 請求。主叫方用戶代理服務(wù)器不應(yīng)該警告用戶，如果用戶先前已經(jīng)對INVITE 請求中的Call-ID 作出了響應(yīng)。如果用戶已經(jīng)是會議的一個成員，同時包含在會話描述中的會議參數(shù)并未改變，那么主叫方用戶代理服務(wù)器可以接受此呼叫，而不管Call-ID 。對于一個已存在的Call-ID 或者會話的邀請可能改變會議的參數(shù)。一個客戶應(yīng)用可以決定向用戶簡單地指示會議參數(shù)已經(jīng)改變，可以自動接受邀請或者可能需要用戶的確認(rèn)。

使用幾個不同的Call-ID 可以邀請一個用戶加入同一個會議或者呼叫。如果需要的話，可以使用在會話描述中的標(biāo)識來檢測此副本。例如，SDP 的“o”域中包含了會話標(biāo)識和版本號。

REGISTER 和OPTIONS 方式使用Call-ID 值來精確匹配請求和響應(yīng)。一個單個的客戶發(fā)布的所有的REGISTER 請求應(yīng)該使用同一個Call-ID ，至少在同一個有效循環(huán)中。

Call-ID = (“Call-ID” | “i”)”:”local-id”@”host

Local-id = 1*uric

i 是Call-ID 的縮寫形式。

“host”應(yīng)該是一個真正的域名或者是一個全球性的IP 地址。如

此，”local-id”應(yīng)該是一個由URI 字符組成的標(biāo)識，此標(biāo)識在”host”中是唯

一的。建議使用經(jīng)過加密的隨機(jī)標(biāo)識。Call-ID 的值禁止被重用于另一個不同的呼叫。Call-ID 區(qū)分大小寫。

1.2 From

請求和響應(yīng)必須包含F(xiàn)rom 通用頭域，指示請求的初始者。From 域可以包含一個"tag" 參數(shù)。服務(wù)器將From 頭域從請求復(fù)制到響應(yīng)?？蛇x的"display-name" 意味著由用戶接口提出（執(zhí)行）。如果客戶身份被隱藏，那么系統(tǒng)必須使用顯示名"Anonymous" 。

此SIP-URL 禁止包含"transport-param" ，"maddr-param" ，"ttl-param" ，"headers" 。接收到含有以上元素的SIP-URL 的服務(wù)器在執(zhí)行下一步處理之前，應(yīng)將這些元素刪除。

即使"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" 可以出現(xiàn)在一個請求的From 頭域中，當(dāng)共享同一個SIP 地址的用戶的兩個實例使用同一個Call-ID 發(fā)出邀請時，必須使用此"tag" 。

"tag" 必須是全球唯一的，并且是一個經(jīng)過加密的至少32比特的隨機(jī)數(shù)。一個單個的用戶應(yīng)該在一個Call-ID 所標(biāo)識的整個呼叫中保持同一個tag 。

Call-ID 、To 和From 用于標(biāo)識一個Call leg 。呼叫和Call-leg 的區(qū)別在于多個響應(yīng)對派生請求的呼叫。

1.3 To

To 通用頭域說明了請求的接收者。

To =（"To" | "t"）" ：" （name-addr | addr-spec）

*（" ；"addr-params ）

請求和響應(yīng)必須包含To 頭域，指示請求的預(yù)定接收者?？蛇x的"display-name" 意味著由用戶接口提出（執(zhí)行）。UAS 或者重定向服務(wù)器將To 頭域的內(nèi)容復(fù)制到它的響應(yīng)中，同時如果請求包含了不止一個Via 頭域，則必須增加"tag" 參數(shù)。 如果Via 頭域不止一個，那么表明請求至少經(jīng)過一個代理服務(wù)器的處理。因為接收者不知道此請求是哪一個代理服務(wù)器派生的請求，所以從安全方面考慮，可認(rèn)為它們都派生了請求。

此SIP-URL 禁止包含"transport-param" ，"maddr-param" ，"ttl-param" ，"headers" 。接收到含有以上元素的SIP-URL 的服務(wù)器在執(zhí)行下一步處理之前，應(yīng)將這些元素刪除。

"tag" 參數(shù)作為一種通用機(jī)制，用于區(qū)分由一個SIP-URL 標(biāo)識的用戶的多個實例。因為代理可以派生請求，所以同一個請求可以到達(dá)用戶的多個實例（例如：移動和住宅電話）；又由于每一個都可以響應(yīng)，所以必須有一種方法來區(qū)分來自被叫方每一個實例的響應(yīng)。這種情況也可由于多點傳送（組播）請求而產(chǎn)生。"tag" 參數(shù)用于區(qū)分UAC 的響應(yīng)。當(dāng)請求有可能被一中間件代理派生時，每一個實例都必須在它的響應(yīng)中包含"tag" 參數(shù)。"tag" 參數(shù)必須可以被UAS 、登記器和重定向服務(wù)器增加，但禁止被加入到上傳的響應(yīng)中。"tag" 參數(shù)可以增加到所有方式的所有已經(jīng)定義的響應(yīng)中，也可以加入到來自UAS 或者重定向服務(wù)器的報告性（1xx ）響應(yīng)。兩個實體間隨后所有的事務(wù)都必須包含"tag" 參數(shù)。

當(dāng)響應(yīng)與請求相匹配時，如果請求的To 域中未包含"tag" 參數(shù)，那么響應(yīng)To 域中的"tag" 參數(shù)將忽略。"tag" 允許代理派生同一個呼叫的未來的請求，而只對幾個可能的響應(yīng)UAS 中的一個定位（尋址）。它也允許被叫方的多個實例發(fā)送可以區(qū)分的請求。

當(dāng)SIP 服務(wù)器接收到一個請求，此請求的To 域中含有它不能識別的URI 時，它應(yīng)該返回一個400（Bad Request）響應(yīng)。

即使"display-name" 是空的，如果"addr-spec" 包含了" ，" 、" ？" 、" ；" ，"name-addr" 形式也必須使用。

Call-ID 、To 和From 用于標(biāo)識一個Call leg 。呼叫和Call-leg 的區(qū)別在于多個響應(yīng)對派生請求的呼叫。"tag" 允許代理派生同一個呼叫的未來的請求，而只對

幾個可能的響應(yīng)UAS 中的一個定位（尋址）。它也允許被叫方的多個實例發(fā)送可以區(qū)分的請求。

1.4 Via

Via 頭域指示請求迄今為止所走的路徑。它防止了請求的循環(huán)，同時確保了響應(yīng)（回答）沿同樣的路徑返回，這一點可以通過防火墻遍歷和其他的異常路徑情況提供幫助。

1.5 Contact

Contact 通用頭域可出現(xiàn)在INVITE 、ACK 和REGISTER 請求中，1xx 、2xx 、3xx 和485響應(yīng)中。通常，它提供了一個URL ，用戶可以通過此URL 來進(jìn)行進(jìn)一步的通信。

INVITE 和ACK 請求：Contact 域表明請求從哪個位置發(fā)起；

這允許主叫方直接向被叫方發(fā)送未來的請求，如BYE ，而不是通過一系列的代理。由于所想要的地址可能是代理的地址，所以只Via 頭域并不夠。

INVITE 2xx響應(yīng)：一個用戶代理服務(wù)器在發(fā)送一個限定的、肯定的響應(yīng)（2xx ）時，可以加入一個Contact 響應(yīng)頭域，表明對于未來的請求它可以直接到達(dá)的SIP 地址，如ACK 請求。Contact 頭域包含了服務(wù)器自己或者代理的地址，例如主機(jī)在一個防火墻之后。如果響應(yīng)未包含Record-Route 頭域，此Contact 的值將復(fù)制到此呼叫的后來的請求的Request-URI 中；如果響應(yīng)包含了Record-Route 頭域，Contact 域的值將作為最后一項增加到Record-Route 域中。Contact 的值不應(yīng)該通過呼叫被緩沖，因為它可能不能表示一個特殊目的地地址的最想要的位置。

INVITE 1xx響應(yīng)：一個UAS 發(fā)送一個臨時的響應(yīng)（1XX ）可以插入一個Contact 響應(yīng)域。語義同2XX INVITE響應(yīng)。注意到CANCEL 請求禁止被發(fā)送到那個地址（Contact 所指示的），但仍跟隨初始請求的路徑。

REGISTER request：REGISTER 請求中的Contact 域表明用戶的位置。REGISTER 請求定義了一個通配的Contact 域?！?”，只能用于：0刪除一個用戶所有的登記。一個可選的“expires”參數(shù)指示登記所想要的期限。如果Contact 未使用此參數(shù)，則Contact 域的值將使用默認(rèn)值。如果這些機(jī)制都未采用，SIP URL的期限為一個小時。其他的URL 沒有期限時間。

REGISTER 2xx響應(yīng)：一個REGISTER 響應(yīng)可以返回可以達(dá)到的用戶的所有地址。 3xx 和485響應(yīng)：Contact 頭域指示一個或多個可選的地址。可以出現(xiàn)在對于INVITE 、BYE 和OPTIONS 方式的響應(yīng)中。Contact 頭域包含的URI 給出了新的位置和用戶名，或者簡單地說明其他的傳輸參數(shù)。300（Multiple Choise）、301(Moved Permanently)、302(Movec Temporarily)或者485(Ambiguous)響應(yīng)應(yīng)該包含一個含有可嘗試的新地址的URL 的Contact 域。301和302響應(yīng)可以給出正在嘗試的同樣的位置和用戶名，但指定了其他的傳輸參數(shù)，如一個不同的服務(wù)器或者多點地址，或者一個從TCP 到UDP ，UDP 到TCP 的SIP 事務(wù)的改變?？蛻魧ontact URL中的“user”、“password”、“host”、“port”、

“user-param”復(fù)制到重定位請求的Request-URL 中，同時使用tranport 參數(shù)中的傳輸協(xié)議，將此請求傳到“maddr”和“port”參數(shù)所說明的地址處。如果“maddr” 是一個多點地址，“ttl”值表明time-to-live 值Contact 頭域可能指示一個不同于原始呼叫實體的實體。例如，與GSTN 網(wǎng)關(guān)相連的SIP 呼叫可能需要發(fā)送一個特殊的消息通知。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]

q ：表明所給的位置的相對重要性，“qvalue”從0到1，值高參考性大。 action ：只用于使用REGISTER 登記時。表明是否客戶希望服務(wù)器代理或者 重定向用戶想要的未來的請求。

expires ：表明URI 的活動時間。注意與Expire 頭域的聯(lián)系：如果Contact 中

存在expires 參數(shù)，則使用其表示的時間；若不存在，則使用Expire 頭域所表示的時間。

1.6 Cseq

對于每一個請求，客戶必須使用Cseq （Command sequence）通用頭域。此頭域包含了請求方式和一個提出請求的客戶所選定的十進(jìn)制序列數(shù)，在同一個

Call-ID 中此Cseq 值唯一。此序列數(shù)必須為一個32位的無符號整數(shù)，它的初始值是任意的，但必須小于等于2**31。連續(xù)的請求在請求方式、頭域和消息上是不同的，但有同樣的Call-ID ，它們的Cseq 也必須是嚴(yán)格單調(diào)增加的相鄰的序列數(shù)；序列數(shù)不能形成環(huán)。重傳請求有相同的Cseq ，但消息體或者頭域不同的INVITE 請求需要一個新的更高的Cseq 。服務(wù)器必須在它的響應(yīng)中回送請求中的Cseq 。如果在所接收的Cseq 頭域中沒有method ，服務(wù)器應(yīng)該正確的填充。 ACK 和CANCEL 請求必須包含與它們相聯(lián)系的INVITE 請求同樣的Cseq 。而當(dāng)BYE 請求釋放一個請求時必須含有以更高數(shù)值的Cseq 。如果BYE 請求中的Cseq 值不高，那么將產(chǎn)生一個400（Bad Request）響應(yīng)。

用戶代理服務(wù)器必須記住同一個Call-ID 的INVITE 請求的最高序列數(shù)。對于包含較低序列數(shù)的任何INVITE 請求，服務(wù)器必須作出響應(yīng)，然后放棄。

所有在并行搜尋中產(chǎn)生的請求擁有和觸發(fā)此并行搜尋的請求一樣的Cseq 值。 Cseq ="Cseq" "：" 1*DIGIT Method

對于任何可以被BYE 或CANCEL 請求取消的SIP 請求，或者對于客戶發(fā)送了連續(xù)的幾個同一個Call-ID 的請求的情況，都需要使用Cseq 頭域。如果沒有序列值，對于INVITE 請求的響應(yīng)將會和對于取消（BYE 、CANCEL ）的響應(yīng)相混淆。同樣，如果網(wǎng)絡(luò)復(fù)制了消息包，或者一個ACK 請求耽擱了直到服務(wù)器發(fā)送了另一個響應(yīng)，客戶應(yīng)該將此舊的響應(yīng)作為對于一個之后很快重傳的邀請的響應(yīng)。使用Cseq 頭域，也可以幫助服務(wù)器區(qū)分邀請的不同版本，而不用比較消息體。

"Method" 方式方法。值使得客戶將對于INVITE 請求的響應(yīng)和對于一個CANCEL 請求的響應(yīng)（一般是200響應(yīng)）區(qū)分開來。代理可以產(chǎn)生CANCEL 請求；如果代理增大序列數(shù)，那么有可能與同一呼叫中用戶代理以后發(fā)送的請求發(fā)生沖突。 派生的請求必須有同樣的Cseq 值，否則在這些派生的請求和客戶用戶代理以后所發(fā)送的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”表示標(biāo)準(zhǔn)的 PGP ASCII包裹，沒有包含“BEGIN PGP MESSAGE”和“END PGP

MESSAGE”的行，沒有版本標(biāo)識。此加密部分默認(rèn)為二進(jìn)制。

1.8 Expires

Expires 頭域給出了消息內(nèi)容活動的日期和時間。此頭域只用于INVITE 、REGISTER 方式。

對于REGISTER 方式，它可以用于請求和響應(yīng)頭域。在REGISTER 請求中，它指示登記的有效期限。在響應(yīng)中，服務(wù)器指示所有登記最早的期限時間。服務(wù)器可以選擇一個比客戶請求的時間短的時間間隔，但不能比客戶請求的時間長。 對于INVITE 方式，他可以用于請求和響應(yīng)頭域。在INVITE 請求中，主叫方可以限制邀請的有效性，例如，客戶希望限制搜尋的期限或者會議邀請的期限。用戶界面可以將此作為離開屏幕上的邀請窗口的一種暗示，即使用戶目前不在工作站上。這同樣限制了搜尋的期限。如果搜尋在此期限內(nèi)未完成，代理將返回一個408（Request Timeout ）響應(yīng)。在302響應(yīng)中，服務(wù)器可以建議客戶最大的重定向期限。

此域的值可以是一個SIP-date ，或者是一個以秒為單位的數(shù)字形式。 Expires = “Expires” “:” (SIP-date | delta-seconds)

1.9 Record-Route

Record-Route 請求和響應(yīng)頭域可以被任何服務(wù)器加到請求中，這些服務(wù)器堅持以后的同一個Call leg的請求使用同樣的路徑。它包含了一個唯一可達(dá)的

Request-URI 來指示代理服務(wù)器。每一個代理服務(wù)器將它的Request-URI 加到序列的開始。

服務(wù)器將Record-Route 頭域不做改變地復(fù)制到響應(yīng)中。（Record-Route 只和2xx 響應(yīng)有關(guān)）主叫方UAC 將Record-Route 頭復(fù)制到隨后的同一個呼叫分支（Call leg ）的請求的Route 頭域中，只是顛倒了請求的順序，以使第一個入口離UAC 最近。如果響應(yīng)包含了一個Contect 頭域，主叫方的用戶代理將它（Contact ）的內(nèi)容作為最后一個Route 域的內(nèi)容。除非這將引起環(huán)路，否則任何用戶必須將任何隨后的同一個呼叫分支（Call leg）請求發(fā)送到Route 頭域的第一個Request-URI 中，同時刪除此入口。

呼叫方用戶代理禁止在包含有Route 頭域的請求中使用Record-Route 頭域。 一些代理，例如那些控制防火墻或者在一個自動呼叫分配（ACD ）系統(tǒng)中，需要保持呼叫狀態(tài)，這樣就需要接收任何一個此呼叫的BYE 和ACK 包。

Record-Route = “Record-Route” “:” 1#name-addr

代理服務(wù)器應(yīng)該使用“maddr”URL參數(shù)來包含它們的地址，以便保證隨后的請求能夠準(zhǔn)確到達(dá)同一個服務(wù)器。

1.10 Timestamp

Timestamp 通用頭域指示客戶何時向服務(wù)器發(fā)送請求。此頭域的值只對客戶有用。服務(wù)器必須回送完全一樣的數(shù)值，同時如果它有確切的消息，可以增加一個小數(shù)值指示從它接收到請求開始所過去的時間?？蛻羰褂胻imestamp 頭域來計算到達(dá)服務(wù)器的round-trip 時間，以便調(diào)整重傳的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

當(dāng)請求或者響應(yīng)被第一次發(fā)送時，Date 頭域指示發(fā)送日期和時間，所以，重傳將使用與相應(yīng)的初始同樣的Date 頭域。

1.12 Accept

Accept 域用于INVITE 、OPTIONS 和REGISTER 請求方式中，指示在響應(yīng)中能夠接收的媒體的類型（缺省值為application/sdp）。

1.13 Accept-Encoding

Accept-Encoding 請求頭域與Accept 頭域相似，但它限制在響應(yīng)中可接受的content-codings 。

1.14 Accept-Language

客戶用Accept-Language 請求頭域向服務(wù)器指示它接收原因短語、通話描述符或者消息體中所承載的狀態(tài)響應(yīng)時所使用的語言。Proxy 可以用此域來幫助選擇呼叫的目的地。

2 entity-header類：

用于描述消息體內(nèi)容的長度、格式和編碼類型等屬性，可用于請求消息或響應(yīng)消息。

實體頭域定義了消息體信息之后的內(nèi)容（如：Content-Length 、Content-Type 、Content-Encoding ），或者如果沒有消息體，則定義請求所指示的資源。

2.1 Content-Encoding

Content-Encoding=(“Content-Encoding” | “e”)”:” 1#content-coding Content-Encoding 實體頭域作為“media-type”的一個修飾語。它的值指示適用于實體消息體的其他的內(nèi)容編碼，指示為了獲得Content-Type 頭域所給出的media-type ，必須使用的編碼方案。Content-Encoding 主要用于壓縮消息體，而不丟失它底層的媒體類型的標(biāo)識。

如果多個編碼適用于一個實體，那么內(nèi)容便必須按照他們被應(yīng)用的順序列出。 所有的Content-Encoding 值都區(qū)分大小寫。

客戶可以將內(nèi)容編碼應(yīng)用于請求消息體中。如果服務(wù)器不能對消息體解碼，或者不能識別任何的Content-Encoding 值，它必須發(fā)送一個415“Unsupported Media Type”響應(yīng)，在Accept-Encoding 頭域中列出可以接受的編碼。 服務(wù)器可以將內(nèi)容編碼應(yīng)用于請求消息體中，但它只能使用請求的

Accept-Encoding 頭域中所列出的編碼。

2.2 Content-Length

Content-Length 實體頭域指示消息體的長度。形式上以八個比特為一個字節(jié)。

Content-Length = (“Content-Length” | “l(fā)”)”:” 1*DIGIT

應(yīng)用程序應(yīng)該使用此域來指示所傳送的消息體的大小，而不管實體所用的媒體類Content-Length 的值應(yīng)為非負(fù)數(shù)，0表示沒有消息體。

服務(wù)器如果收到一個不包含Content-Length 域的UDP 請求，那么它便認(rèn)為此請求壓縮了包的剩余部分。

服務(wù)器如果收到一個包含有Content-Length 域的UDP 請求。但它的值比消息體的實際長度大，客戶則應(yīng)產(chǎn)生一個400類的響應(yīng)。

在UDP 包中，如果接收完消息體的最后一個比特后，還有其他的數(shù)據(jù)，服務(wù)器必須將此數(shù)據(jù)視為另一個消息。也就是說，允許在一個UDP 包中包含有多個消息。 如果一個響應(yīng)中未包含Content-Length ，客戶便認(rèn)為此響應(yīng)壓縮了UDP 包或者數(shù)據(jù)的剩余部分，直到關(guān)閉TCP 連接。

2.3 Content-Type

Content-Type 實體頭域指示發(fā)送給接收者的消息體的媒體類型。

Content-Type=（“Content-Type”| “c”）“：”media-type

3 request-header類：

為請求頭域，只可用于請求消息，它用來傳遞有關(guān)請求或客戶機(jī)本身的一些附加信息，對請求進(jìn)行補(bǔ)充說明。客戶將關(guān)于請求和關(guān)于客戶自己的其他信息傳送給服務(wù)器。這些域類似于請求的變量，語義上相當(dāng)于可編程語言方式調(diào)用的參數(shù)。請求頭域的擴(kuò)展與通用頭域相同。

3.1 Subject

Subject 請求頭域提供了一個摘要，或者指示了呼叫的實際情況，使得不必分析通話描述便可過濾呼叫。（當(dāng)然，通話描述不必使用與邀請同樣的標(biāo)題） Subject = （"subject" | "s"）" ："*TEXT-UTF8

3.2 User-Agent

User-Agent 通用頭域包含了關(guān)于發(fā)送初始請求的客戶用戶代理的消息。

此頭域用于統(tǒng)計目的，跟蹤違反協(xié)議的情況、用戶代理的自動認(rèn)可的情況，以便在編制響應(yīng)時避免特定用戶代理的限制。用戶代理應(yīng)在請求中包含此頭域。 User-Agent = "User-Agent" ":" 1*( product | comment )