SIP Header fields - 小蘿蔔工作室Little Robot Studio

SIP Header fields. SIP 信頭欄位[RFC3261 §20] 有些信頭欄位只在特定請求或回應有意義，不該出現的或不認識的都忽略。

一些常見的信頭欄位名稱也定義 ... 2018年11月25日星期日 SIPHeaderfields SIP信頭欄位[RFC3261§20] 有些信頭欄位只在特定請求或回應有意義，不該出現的或不認識的都忽略。

一些常見的信頭欄位名稱也定義了compact(abbreviated)形式，當整個訊息過長造成問題時使用，例如使用UDP時超過MTU。

compactform可以在任何時候使用，也可以混合使用。

完整信頭欄位見https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 信頭欄位相關於method和proxy處理的資訊如下表。

HeaderfieldwhereproxyACKBYECANINVOPTREGPRACK Accept請求-o-om*oo 2xx---om*o- 415-c-cccc Accept-Encoding請求-o-oooo 2xx---om*o- 415-c-cccc Accept-Language請求-o-oooo 2xx---om*o- 415-c-cccc Alert-Info請求ar---o--- 180ar---o--- Allow請求-o-oooo 2xx-o-mm*oo 回應-o-oooo 405-m-mmmm Authentication-Info2xx-o-oooo Authorization請求ooooooo Call-IDcopyrmmmmmmm Call-Info任何ar---ooo- Contact請求o--moo- 1xx---m--- 2xx---moo- 3xxd-o-oooo 485-o-oooo Content-Disposition任何oo-oooo Content-Encoding任何oo-oooo Content-Language任何oo-oooo Content-Length任何arttttttt Content-Type任何**-**** CSeq複製rmmmmmmm Date任何aooooooo Error-Info300-699a-oooooo Expires任何---o-o- From複製rmmmmmmm In-Reply-To請求---o--- Max-Forwards請求ammmmmmmm Min-Expires423-----m- MIME-Version任何oo-oooo Organization任何ar---ooo- Priority請求ar---o--- Proxy-Authenticate407ar-m-mmmm 401ar-oooooo Proxy-Authorization請求droo-oooo Proxy-Require請求ar-o-oooo Record-Route請求arooooo-o 2xx,18xmr-oooo-o Reply-To任何---o--- Require任何ar-c-cccc Retry-After404,413,480,486 500,503 600,603 -oooooo Route請求adrccccccc Server回應-oooooo Subject請求---o--- Supported請求-oom*ooo 2xx-oom*m*oo Timestamp任何ooooooo To複製(1)rmmmmmmm Unsupported420-m-mmmm User-Agent任何ooooooo Via請求amrmmmmmmm 回應,複製drmmmmmmm Warning回應-oooooo WWW-Authenticate401ar-m-mmmm 407ar-o-oooo where欄表示用在請求、回應、特定回應、或是任何請求和回應。

複製是指由請求複製到回應，(1)含可能的tag一起複製。

proxy欄表示在proxy可進行的動作： a(add)：如沒有可新增或concatenate m(modify)：可修改。

d(delete)：可移除。

r(read)：必須可讀，所以不能加密。

各個method欄說明是否要有： c(conditional)：視訊息內容需要。

m(mandatory)：必要，且接收端必須了解。

m*：應該要有，但接收端沒收到時要能處理。

o(optional)：選擇性的。

可有可無，接收端可忽略，例外是RFC3261§20.32的Require。

t：應該要有，但接收端沒收到時要能處理。

如果transport用stream-based協定(例如TCP)，則是必要的。

*：有訊息body時必要。

見RFC3261§20.14、§20.15和§7.4。

-：不能有，接收端遇到的話忽略。

UA忽略不認識的extensionheaderparameters。

如果Contact、From、和To包含的URI有「,」、「?」、或「;」，必須 用包起來。

沒包在內的「;」是分割出header參數，不是URI參數。

Accept 指定回應內容可接受的媒體類型，預設是「application/sdp」，空的Accept欄位值表示不接受任何格式，其它語法和語意依循HTTPAccept。

譬喻： Accept:application/sdp;level=1,application/x-private,text/html Accept-Encoding 類似Accept，但限制回應內容可接受的編碼，一般是指壓縮方式。

語意跟HTTPAccept-Encoding相同。

空的Accept-Encoding相當於「Accept-Encoding:identity」，也就是沒有編碼。

沒有Accept-Encoding欄位預設identity。

註：在HTTP，沒有Accept-Encoding欄位表示任何編碼都可以，但偏好identity。

譬喻： Accept-Encoding:gzip Accept-Language 用在請求表示回應訊息內容的reasonphrases、sessiondescriptions、或statusresponses的偏好語言，如果沒有則假設接受任何語言。

依循HTTPAccept-Language語法，包括"q"參數(quality)的偏好順序。

譬喻： Accept-Language:da,en-gb;q=0.8,en;q=0.7 Alert-Info 在INVITE請求，提供不同的鈴聲給UAS。

在180(Ringing)，提供不同的回鈴音給UAC。

典型用途是proxy用來提供不同聲音識別用。

跟Call-Info一樣存在安全風險，被放入惡意音訊。

應該提供使用者可關閉此功能。

譬喻： Alert-Info: Allow 告知對方所有支援的Method列表。

沒有Allow代表沒講支援哪些Method，不是不支援任何Method。

在methodOPTIONS以外的回應提供Allow欄位，減少需要的訊息數目(???)。

例如： Allow:INVITE,ACK,OPTIONS,CANCEL,BYE Authentication-Info 提供跟HTTPDigest的相互認證，UAS可以在成功認證請求的2xx回應放這個header，使用基於Authorization的digest。

語法和語意遵循RFC2617。

譬喻： Authentication-Info:nextnonce="47364c23432d2e131a5fb210812c" Authorization UA的認證憑證。

RFC3261Section22.2概述Authorization的使用，Section22.4說明和HTTP認證一起使用時的語法和語意。

Authorization(和Proxy-Authorization)多個信頭欄位值不能合併成逗號分隔的列表，要分成多個信頭欄位行。

下面列子，Digest參數沒用引號刮起來。

Authorization:Digestusername="Alice",realm="atlanta.com",  nonce="84a4cc6f3082121f32b42a2187831a9e",  response="7587245234b3434cc3412213e5f113a5" Call-ID(i)Call的唯一識別碼，所有SIP訊息都需要，關聯的SIP訊息都會有相同的值。

一個UA註冊應該都使用相同的Call-ID。

dialog內所有SIP訊息的Call-ID都相同。

Call-ID加上Fromtag及Totag形成一個peer-to-peer的SIP關係，稱為一個dialog。

一個Call可能有多個dialog。

其它可能的特殊Method行為。

Call-ID用字串比對是否符合，需減少無意的碰撞可能性。

  建議產生方式：由隨機字串加上UAC的主機名或IP位址組合而成。

使用加密的亂數識別碼(RFC1750)https://tools.ietf.org/html/rfc1750https://tools.ietf.org/html/rfc4086實作可使用"localid@host"的form. 使用加密亂數提供一些保護againstsessionhijacking(為什麼？？？)。

一個多媒體會議可能需要多個不同Call-ID的呼叫。

譬喻： Call-ID:[email protected] i:[email protected] Call-Info 提供發話者(請求)或受話者(回應)額外資訊的URI，在其"purpose"參數說明目的： "icon"表示適合顯示為icon的影像。

"info"是用戶一般描述，例如經由網頁。

"card"提供vCard或LDIF等格式的名片。

使用Call-Info存在安全風險，而被放入惡意訊息，可能是peerUA，也可能是中間的proxy。

建議只有在放Call-ID的設備可以驗證真偽，並且是可信任的，才顯示資訊。

譬喻： Call-Info:;purpose=icon,   ;purpose=info Contact(m) 後續請求的接洽窗口URI，其意義依據所在的請求或回應。

可以包含顯示名稱、URI參數、header參數。

如果有顯示名稱、或URI參數、或者URI含有「,」「;」「?」時，URI和URI參數要用「」包起來。

沒包起來的參數都視為header參數。

顯示名稱可以是token，要較大的字元集的話用一個quotedstring。

這些規則也應用在To和From。

URI通常有username，位於某個FQDN或者沒註冊的domainnames則用IP位址。

Contact和HTTP的Location有類似的角色，然而HTTP只允許一個unquoted位址。

Contact參數"q"和"expires"只用在REGISTER請求和回應，或者3xx回應。

格式 STAR/(contact-param*(COMMAcontact-param)) contact-param=(name-addr/addr-spec)*(SEMIcontact-params) contact-params="q"EQUALqvalue/"expires"EQUAL1*DIGIT/generic-param qvalue=("0"["."0*3DIGIT])/("1"["."0*3("0")]) 譬喻： Contact:"Mr.Watson"   ;q=0.7;expires=3600,   "Mr.Watson";q=0.1 m:;expires=60 UAC建立dialog的請求(在RFC3261只有INVITE)，必須提供只有一個URI的Contact，無論後續請求在不在dialog內都可以作為接受請求使用。

如果Request-URI或topRoute含有一個SIPSURI，Contact也必須是SIPSURI。

REGISTER Contactalias 只有*允許comma-separatedlist 註：m意思moved。

比較：Via Content-Disposition 訊息體或其中multipart的部署，擴展RFC2183的MIMEContent-Type。

Content-Disposition在RFC3261新增，並在IANA註冊了4種新disposition-types： alert：alert使用者的客製化鈴聲。

icon：顯示給使用者的icon影像。

render：顯示給使用者。

session：作為通話媒體的session描述，如SDP。

為了向前相容，如果沒Content-Disposition，Content-Type是application/sdp時假設為"session"，其它為"render"。

如果收到不了解的Content-Type或Content-Disposition，參數handling說明UAS應 該如何反應。

有定義的值有"optional"和"required"，預設是"required"。

handling參數說明在RFC3204。

譬喻： Content-Disposition:session Content-Encoding(e) 訊息體的編碼，需要解壓縮或解碼才能得到Content-Type所參照的media-type時才需要，可依序列出多個施加的編碼。

Content-Encoding欄位值不分大小寫，登記在IANA。

見https://tools.ietf.org/html/rfc2616#section-3.5定義的語法。

Client可對請求的訊息體編碼。

Server可用列在請求Accept-Encoding的編碼，對回應的訊息體編碼。

譬喻： Content-Encoding:gzip e:tar Content-Language 訊息體的語言，見https://tools.ietf.org/html/rfc2616#section-14.12 譬喻： Content-Language:fr Content-Length(l) 訊息體的長度。

十進位數字表示位元組數目，不含分隔body的CRLF，0以上的 值都是valid。

如果使用stream-basedtransport協定(例如TCP)是必要的。

沒body時，Content-Length是0。

能夠省略Content-Length簡化建立動態產生回應的像cgiscripts。

譬喻： Content-Length:349 l:173 Content-Type(c) 訊息體的媒體類型，有message-body時是必要的。

譬喻： Content-Type:application/sdp c:text/html;charset=ISO-8859-4 CSeq CommandSequence，每個SIP訊息都要有，包含一個序號及一個Method名稱，譬喻： CSeq:314159INVITE序號是某個UAC在同一個Call-ID下Command的順序，大致來講就是Transaction的順序，一開始是比231小的亂數，後續每次發出仝款Call-ID的新請求時，序號就加1，讓UAS辨別是新的Transaction還是重傳。

例外是ACK和CANCEL，他們算是INVITE的延伸，沿用INVITE的序號。

PRACK序號會加1。

一個UA的REGISTER原則上開機後都使用仝款Call-ID，CSeq序號是註冊請求的順序。

Date 請求或回應首次送時的GMT日期和時間。

不同於HTTP/1.1，SIP只支援最新的RFC1123格式的日期，但如同HTTP/1.1，SIP限制時區為"GMT"。

RFC1123Date有分大小寫。

Date可讓沒battery-backedclock的簡易終端系統獲得目前時間。

譬喻：      Date:Sat,13Nov201023:29:00GMT Expires 訊息或內容從接收到請求開始的過期時間，值是0到(2**32)-1之間的秒數，精確的意思 視Method而定。

INVITE的過期不影響邀請成功後實際session可使用的時間。

session可使用的時間限制 可表達在Session描述協定裡。

Error-Info 提供關於錯誤狀態回應的額外資訊。

UAC用戶界面可能從有彈出式視窗和聲音的PCsoftclients，到透過gateway連接、只有聲音的「黑」話機或端點。

與其強迫server選擇在Reason-Phrase傳送細節還是播放錄音，Error-Info允許兩者都送，由UAC選擇用哪種呈現給發話者。

UAC可視Error-Info的SIP或SIPSURI如同redirect的Contact產生新INVITE得到錄音，非SIPURI可呈現給用戶。

譬喻：  SIP/2.0404Thenumberyouhavedialedisnotinservice  Error-Info: From(f) 請求的發出端。

可能跟請求建立dialog的發出端不同。

和Contact有相同規則的顯示名稱、URI、URI參數、和信頭參數。

 選擇性的顯示名稱用來顯示在人機界面，要隱藏的話用「Anonymous」。

格式是name-addr或addr-spec加上tag參數，和其它參數(name-addr/addr-spec)SEMI"tag"EQUALtoken*(SEMIgeneric-param) addr-spec是name-addr的簡化，不能有display-name、「,」、「?」、「;」。

兩個From相等：URI且參數match。

擴充參數一個沒有則忽略。

displayname和有無anglebracket不影響是否相等。

譬喻： From:"A.G.Bell";tag=a48s From:sip:[email protected];tag=887s f:Anonymous;tag=hyh8 Organization 送出請求或回應的SIP元件所屬組織名稱。

Client可用來過濾呼叫。

譬喻： Organization:BoxesbyBob Record-Route 格式 rec-route*(COMMArec-route) rec-route=name-addr*(SEMIgeneric-param) Reply-To 格式 (name-addr/addr-spec)*(SEMIgeneric-param) Route 格式 route-param*(COMMAroute-param) route-param=name-addr*(SEMIgeneric-param) To(t) 格式 (name-addr/addr-spec)*(SEMIto-param) to-param="tag"EQUALtoken/generic-param Via(v) 一開始的UAC和後續途經的每個proxy都會加一個Via放transport及位址，依序作為回應的路徑。

格式sent-protocolhost[:port];branch=branch[;參數...] sent-protocol格式是「SIP/2.0/transport」，transport可以是UDP、TCP、TLS、SCTP等。

host可以是主機名稱或網路位址，可以加上portnumber。

(沒用途？) 參數branch： 意思是分支。

在RFC3261以「z9hG4bK」開頭，是必要的。

值對某個UAC而言是時空上唯一，用來快速識別Transaction，但在CANCEL和INVITE失敗的ACK是沿用原始請求的branch。

在RFC2543，forkingproxy插入branch用來區分不同分支，同一個call在不同proxy可能用相同的branch值，沒有唯一的特性，不適合作為TransactionID。

某種程度上不會產生「z9hG4bK」開頭的值。

Proxy也用來偵測loop。

參數sent-by：ClientTransport紀錄送出的位址「host:port」，host建議FQDN。

port可省略，預設值依據傳輸協定，UDP/TCP/SCTP是5060、TLS是5061。

在用來送回應。

收到請求的Via中有sent-by且branch符合自己送的， 參數received：ServerTransport收到請求檢查頂頭Via的sent-by，如果是網域主機名稱，或不同於封包的來源IP位址時，紀錄封包的來源位址，助於之後servertransport送回應。

參數maddr：ClientTransport紀錄 參數ttl：ClientTransport紀錄 Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bK776asdhds 比較：Contact 張貼者： ijon 於 晚上8:30 以電子郵件傳送這篇文章BlogThis！分享至Twitter分享至Facebook分享到Pinterest 標籤： Protocol, SIP 沒有留言: 張貼留言 較新的文章 較舊的文章 首頁 訂閱： 張貼留言(Atom) 標籤 心法 手機 音 電 電腦 電話 圖 影 翻譯 Arduino asm Asterisk BBB blackfin C coLinux Desktop Device DSP Embedded Firefox git ISDN kamailio Kernel Lego Linux Linux-Kernel Linux-Kernel-Network Linux-Network Linux-System lua LXDE MIPS Network NXT NXT-G OpenWrt Programming Protocol ramips Raspberry-Pi Shell SIP SQLite ssh svn System TOC Tools Ubuntu USB vim VirtualBox Web Windows Wireless x86 網頁 首頁 主題 熱門文章 PrecisionTimeProtocol 精確時間協定(PrecisionTimeProtocol,PTP)透過網路封包同步絕對時間、頻率、和相位，達到毫秒級精確度。

版本IEEE1588-2002(PTPv1)：未廣泛採用。

IEEE1588-2008(PTPv2)：沒向前相容。

有p... IPMulticast 有些應用需要進行一對多或多對多的封包傳送，例如網路廣播電台、網路電視廣播。

如果封包使用unicast單點傳送的方式，傳送端需要先知道所有傳送的對象，一個一個傳送，對傳送端負擔較大，也需要很多倍的網路頻寬。

封包的broadcast廣播通常會侷限在本地區域網路內，如果開放到網... ARPandGratuitousARP Ethernet是靠MAC位址傳送封包，傳送IP封包給對方IP位址，還需要知道對方MAC位址才能傳送。

ARP(AddressResolutionProtocol)就是用來詢問對方MAC位址的協定，包括ARPrequest跟ARPrep... RFC5424SyslogMessageFormat 廣為使用的syslog來自BSD，訊息格式並沒有標準化，共通點只有都是以「」開始。

RFC3164只是說明觀察到的格式，認定送到syslogUDPport(514)的封包都是syslog訊息。

RFC5424用ANBF... Ethernet封包格式與長度 ←84-1538octets→←72-1526octets→Preamble10101010Start-of-Frame-Delimiter10101011EthernetFrameInterframegap7octets1... FSKCIDFormat CallerID(calleridentification,CID)有多種翻譯或別名：來電顯示、來電號碼顯示、CLID(CallerLineIdentityDisplay),CLI(callinglineidentification)、callingn... OpenWrtprocd OpenWrt使用procd取代傳統Linux使用的init及udev。

procd原始碼除了套件procd外，還包括套件procd-ujail、procd-seccomp、procd-nand、procd-nand-firstboot。

procd... JTAG JTAG(JointTestActionGroup)是一個在1985年成立的電子工業協會，致力於發展產品製造後如何驗證設計及測試印刷電路板接線的方法。

在1990年結果寫成IEEEStandard1149.1-1990，標題是「StandardTestA... gitdescribe 用最近的tag及其間隔的送交數目來描述一個送交，格式是--g，後面可以選擇加是否dirty。

前面的g代表git，用來區別SCM。

指令格式... Linuxdevicenumber devicenumber由majornumber和minornumber組成[註1]。

major號碼識別使用的驅動程式，例如/dev/null和/dev/zero使用driver1、virtualconsoles和serialter... 網誌存檔 ►  2022 (22) ►  五月 (13) ►  三月 (5) ►  二月 (3) ►  一月 (1) ►  2021 (67) ►  十二月 (3) ►  十一月 (3) ►  十月 (5) ►  九月 (4) ►  八月 (4) ►  七月 (7) ►  六月 (4) ►  五月 (3) ►  四月 (1) ►  三月 (10) ►  二月 (1) ►  一月 (22) ►  2020 (66) ►  十二月 (8) ►  十一月 (15) ►  十月 (8) ►  九月 (2) ►  八月 (4) ►  七月 (4) ►  六月 (8) ►  五月 (3) ►  四月 (4) ►  三月 (9) ►  一月 (1) ►  2019 (53) ►  十二月 (3) ►  十一月 (10) ►  十月 (10) ►  九月 (7) ►  八月 (2) ►  七月 (2) ►  六月 (5) ►  五月 (1) ►  四月 (1) ►  三月 (3) ►  二月 (5) ►  一月 (4) ▼  2018 (35) ►  十二月 (4) ▼  十一月 (4) SIPHeaderfields lightning bash:SHELLGRAMMAR [C]VLA ►  十月 (2) ►  九月 (2) ►  八月 (8) ►  七月 (10) ►  六月 (1) ►  四月 (1) ►  三月 (2) ►  二月 (1) ►  2017 (14) ►  十一月 (3) ►  十月 (6) ►  九月 (2) ►  八月 (3) ►  2016 (14) ►  九月 (2) ►  八月 (2) ►  七月 (2) ►  二月 (5) ►  一月 (3) ►  2015 (38) ►  十二月 (4) ►  十一月 (3) ►  九月 (4) ►  八月 (8) ►  四月 (3) ►  二月 (12) ►  一月 (4) ►  2014 (71) ►  十二月 (5) ►  十一月 (6) ►  十月 (1) ►  九月 (16) ►  八月 (3) ►  七月 (7) ►  六月 (7) ►  五月 (11) ►  四月 (6) ►  三月 (1) ►  二月 (2) ►  一月 (6) ►  2013 (60) ►  十二月 (5) ►  十一月 (19) ►  十月 (3) ►  八月 (13) ►  七月 (6) ►  三月 (1) ►  二月 (12) ►  一月 (1) ►  2012 (31) ►  十二月 (1) ►  十一月 (14) ►  十月 (4) ►  九月 (3) ►  八月 (3) ►  四月 (2) ►  三月 (2) ►  一月 (2) ►  2011 (17) ►  十二月 (5) ►  十月 (1) ►  二月 (2) ►  一月 (9) ►  2010 (75) ►  十二月 (4) ►  十一月 (5) ►  十月 (13) ►  九月 (1) ►  八月 (4) ►  七月 (2) ►  六月 (11) ►  五月 (5) ►  四月 (12) ►  三月 (7) ►  二月 (10) ►  一月 (1) ►  2009 (23) ►  十二月 (5) ►  十一月 (3) ►  十月 (4) ►  九月 (1) ►  八月 (5) ►  七月 (5) ►  2008 (2) ►  七月 (1) ►  二月 (1) ►  2007 (19) ►  十月 (1) ►  九月 (1) ►  八月 (2) ►  七月 (1) ►  六月 (2) ►  五月 (1) ►  三月 (3) ►  二月 (7) ►  一月 (1) ►  2006 (1) ►  十二月 (1)