Ch18 - Ch19
------------------------------------------
對於Request與path MTU 之間留有200bytes的buffer，是爲了處理response比request大的問題。比如添加record-route
200bytes，UDP +IP頭需要30bytes，因此，流出170bytes
如果transaction層請求使用UDP，但由於大小限制，必須使用TCP ,但發生了錯誤，ICMP Protocol Not Supported，or導致了TCP reset，那麼因該使用UDP重試。
如果request是發送到多播地址的，那麼在Via中必須包含maddr參數，包含多播目的地址。如果使用IP v4，還需要設置參數ttl=1，IP v6的使用在這裏沒有定義。
ttl=1，導致了對SIP 多播請求的限制，主要功能是提供“single-hop-discover-like”服務。也就是發送請求給一組server，然後處理其中一個響應。由於響應具有相同的Via branch，因此其它的響應會被認爲是重傳。這對註冊特別有用？尋找最近的單點 ？
發送請求前，傳輸層在Via header中添加sent-by字段，包含IP+port,或者Host+port。默認port是5060 for UDP, TCP, SCTP, 5061 for TLS
對於reliable傳輸，response會在收到request的connection上面發送。所以，UAC應該準備好在發送requst的connection上面接收response。
在出錯的請看下，UAS在請求與UAC建立新的connection，發送response。而UAC的IP和port都要和發送request的相同。
總體來說，先利用已經存在的，有問題的情況下再建立新的或使用其它的。
多播需提供ttl，單播則不需要。
ch18.1.2 Receiving Response
收到response後檢查Via header的sent-by參數，如果與其在request參數中插入的不匹配，則丟棄
接下來，按照17。1。3匹配transaction,匹配到就傳遞到相應的transaction，否則傳給core模塊
18.2 Servers
18.2.1 Receiving Request
Server監聽任何UDP port和interface，那麼一定也要監聽TCP，因爲可能在UDP發送失敗的情況下會使用TCP發送，但反過來卻不用。
Server收到請求後，檢查Via header的sent-by參數，如果和其source ip不一致，則Server添加received參數，表明其source ip和port，用於輔助server的transport層發送response。
匹配transaction，匹配到就傳遞到transaction，否則就傳遞到core。
注意，server在發送2xx響應invite後，其transaction已經destroy了，所以收到ack會創建一個新的transaction。
18.2.2 Send Response
TCP，SCTP，TLS over them，如果收到request的connection還在，就使用其發送response，這就要求server維護transaction和transport connection的關係。
maddr情況，sent-by，ttl
UDP，received參數。如果失敗，ICMP port unreachable
18。3 Framing
UDP，content-length，多餘的discard，超高一個packets的也discard
TCP，必須使用content-length
19 Common Message Components
19。1 SIP and SIPs URI
標識了通信的資源 。sip:, sips:是scheme
sip:user:password@host:port;uri-parameters?headers
user標識了host上面的resource
host一般指domain
userinfo = user:password，即@前面的部分。userinfo是可選的，因爲有些host沒有user的概念，host本身就是被標識的資源。如果沒有userinfo，那麼一定不能有@
URI parameters：
name=value，各個參數之間使用分號隔開，同名的只能有一個
參數有：transport，ttl，maddr，user，method，lr
transport：UDP,TCP， SCTP，那麼SIPs URI 必須使用reliable transport
ttl：在使用UDP和maddr時必須使用
user：telephone-subscriber string是user string的子集，user參數就是爲了區分電話號碼和看起來像電話號碼的user string。如果user string包含的是telephone-subscriber格式的電話號碼，那麼user=phone
lr：表明負責本resource的host，支持loose route
19。1。6 tel URL and SIP URI之間的關係
Ch20 Headers
---------------------------------------------------------
Accept:
默認applicatioin/sdp
Accept: application/sdp;level=1, application/x-private, text/html
Accept-Encoding:
默認identity
Accept-Encoding: gzip
Accept-Language：
默認client所有支持的language。q 參數是什麼意思 ？
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Alert-Info:
在Invite或者180消息中，爲UAS或者UAC提供ring tone或者ringback tone的一個alternative
存在risk，參考call-info
Alert-Info:
Allow:
支持的method，沒有該header，只是表明沒有提供額外信息，並不是表明不支持任何方法。
Authentication-Info
在UAS使用authorization鑑權成功後，UAS在2xx消息中包含
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
Authorization
包含UA的authentication credentials 。這個不同於其它字段，多行不能合併到一行。
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
Call-ID
Call-Info
爲主被叫提供額外信息，token包括：purpose, icon, info, card
可能會產生錯誤的信息，那麼收到的UA應該只顯示其能夠驗證或者信任的call-info
Call-Info: ;purpose=icon,
;purpose=info
Contact
可以包含display name，URI parameters，header parameters
該規範只定義了參數q和expires，他們用於register的請求或者響應，以及3xx響應中；
多個contact之間使用逗號，參數之間使用分號。
縮寫爲 m
Contact: "Mr. Watson"
;q=0.7; expires=3600,
"Mr. Watson" ;q=0.1
Content-Disposition
描述UAS和UAC如何解釋message body，擴展了MIME Content-Type（RFC2183）
session：表明body描述了一個call或者early media的session
render：表明body應該被display或者rendered to user
默認：如果Content-Type：application/sdp，dispostion:session, 其它的content-type，則render
icon：表明body包含一個合適的image，用於表示caller或者callee
alert：表明body包含信息，比如應該展示給用戶的audio clip
handling-param 描述瞭如果UAS不理解收到消息的content-type或者disposition，應該如何處理
optional
required：默認，參考RFC3204
Content-Encoding
擴展了media-type，表明爲了獲取Content-Type表明的media，還需要decode，一般用於壓縮
可以同時使用多個encoding ？
在IANA有註冊
Server只能使用Accept-Encoding中列出的encodings
縮寫是 e
Content-Encoding: gzip
e: tar
Content-Language
Content-Length
以字節計數，表明message body的大小，可以使0，或者正數。如果message body爲空時，必須爲0；
特別，使用TCP傳輸的話，必須使用該字段
不包含分隔headers和message body之間的CRLF。
縮寫爲 l
Content-Type
如果包含message body，必須包含該字段。
如果message body爲空，但有該字段，表明包含一個空的Content-Type
縮寫爲 c
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
CSeq
包含一個32-bits整數 + request method。method區分大小寫
CSeq: 4711 INVITE
Date
表明request或者response第一次發送的時間。區分大小寫
Error-Info
SIP/2.0 404 The number you have dialed is not in service
Error-Info:
Expires
From
表明request的發起者，注意：不一定是dialog的發起者，因爲callee發送請求時，From是callee's address
縮寫是 f
In-Reply-To
不太理解。
該字段返回該call參考或者返回的call-id，以便自動分發系統或者被叫過濾回撥的電話。
該字段不能替代鑑權
In-Reply-To: [email protected], [email protected]
Max-Forwards
Min-Expires
取值在0 - 2**32-1之間。在response 423（Interval too Brief）中使用 ？
MIME-Version
Organization
傳遞發送請求或者響應的網元所屬組織的名字。
Organization: Boxes by Bob
Priority
表明請求的緊急程度，未出現的話，默認是normal。
其取值：non-urgent, normal, urgent, emergency。
emergency只在生命財產受到立即損害時使用。
Proxy-Authenticate
包含authentication challenge
Proxy-Authenticate: Digest realm="atlanta.com",domain="sip:ss1.carrier.com", qop="auth",nonce="f84f1cec41e6cbe5aea9c8e88d359",opaque="", stale=FALSE, algorithm=MD5
realm：表明保護範圍，包含一個主機或者域名，不一定和SIP domain一致；
qop：Quanlity Of Protection, 取值：auth,auth-int，後者是完整性保護；
Proxy-Authorization
允許Client向Proxy表明自己是誰。
Proxy-Authorization: Digest username="Alice",realm="atlanta.com",nonce="c60f3082ee1212b402a21831ae",response="245f23415f11432b3434341c022"
Proxy-Require
表明要求Proxy必須支持的feature
Record-Route
Proxy插入到請求中，要求該dialog中的後續請求，通過該Proxy
Reply-To
未理解
Require
UAC要求UAS支持的feature，比如100rel
一旦出現，不能被忽略。
Retry-After
表明多長時間後available或者reachable。
可以攜帶一個註釋，提供更多信息。
duration參數表明available或者reachable的時間長度。
Retry-After: 18000;duration=3600
Retry-After: 120 (I’m in a meeting)
Route
強制request通過某個proxy
Server
包含UAS的software信息。如果包含軟件版本的話，可能更易受到攻擊。
Subject
縮寫是s，提供call的描述信息。
Supported
縮寫是k，表明支持的feature
Timestamp
描述UAC發送請求給UAS的時間，Section 8.2.6 ?
To
定義請求的邏輯recipient
Unsupported
User-Agent
發起請求的UAC的信息
Via
表明response回覆到哪裏
Warning
攜帶額外的response信息。由3部分組成：warning code， host name， warning text
Warning: 307 isi.edu "Session parameter ’foo’ not understood"
Warning: 301 isi.edu "Incompatible network address type ’E.164’"
WWW-Authenticate
包含authentication challenge
WWW-Authenticate: Digest realm="atlanta.com",domain="sip:boxesbybob.com", qop="auth",nonce="f84f1cec41e6cbe5aea9c8e88d359",opaque="", stale=FALSE, algorithm=MD5
21 Response
--------------------------------------------------------------
SIP response與HTTP/1.1一致，並進行了擴展。其中部分response沒有使用，擴展了6xx。
21.1 Provisional 1xx
Provisional response = informational response。如果server需要超過200ms才能產生final response，那麼就先發送1xx。
在本文檔中的1xx的發送，是非可靠的，client不發送ack
100 Tring
表明request已經被接收，一些特定的action正在進行。
UAC收到後，停止重傳request，比如INVITE；
100和其它provisional response不同的是，it is never forwarded upstream by a stateful proxy.
180 Ring
收到request的UA，正在嘗試alert the user，觸發local ringback
181 Call Is Being Forward
182 Queued
Called party暫時unavailable，server決定排隊該call而不是reject。當Callee變爲available時，server就會返回適當的final response。
reason字段可能會給出進一步的信息，比如“5 calls queued; expected waiting time is 15 minutes”
Server可能發送多個182更新/通知該call的狀態；
183 Session Progress
提供call的信息，未被明確分類到其它response裏面的信息；
Reason-Phrase和message body可能會提供進一步的信息
21.2 Successful 2xx
200 OK
21.3 Redirection 3xx
3xx response提供user的最新位置信息，或者可能滿足該call的alternative services
300 Multiple Choices
地址解析得到多個選項，每個都有自己特定的location，user可以選擇一個preferred communication end point，重定向request到那個location。
如果request中的Accept字段允許，那麼message body中可能包含一個資源特性和位置的列表，以便user可以從中選擇一個最合適的。
Choices在Contact字段列出；HTTP只允許一個，但SIP允許多個。
301 Moved Permanently
User不再使用Request-URI中的地址了，UAC應該嘗試Contact字段給出的新地址。
UAC應該更新本地的目錄、地址簿、緩存等。
302 Moved Temporarily
UAC應該重試Contact字段給出的地址，即用作Request-URI。
其時效可以通過Expires字段或者Contact的expires參數給出。UA和proxy都可能會緩存該URI。
如果沒有Expires字段或者expires參數，那麼這個address只針對這次request，UA和proxy不能緩存。
如果緩存的URI失敗了，那麼此前的那個URI可能會被再試一次。
這個臨時的URI可能提前失效，那麼一個新的臨時URI會可用。
305 Use Proxy
請求的resource必須通過Contact字段給出的proxy才能訪問。UAC應該通過給出的proxy重複此前的請求。
305 response只能由UAS產生。
380 Alternative Service
該call失敗了，但有alternative service可用。
Alternative Service在message body中定義，格式沒有在該文檔中定義。
21.4 Request Failure 4xx
4xx是從particular server返回的definite failure。UAC不應該不做任何修改（比如收到401後，添加適當的authorization）就再次重試。
但是，相同的請求，在不同server那裏，可能會成功。
400 Bad Request
Request不能被理解，Reason-Phrase提供進一步的細節。
401 Unauthorized
這個請求需要user authentication。該response由UAS或者registrars發出。Proxy發出407（Proxy Authentication Required）。
402 Payment Required
403 Forbidden
Server理解請求，但拒絕執行。Authorization也沒用，UAC不應該在重複該請求。
404 Not Found
Server確認：在Request-URI中給出的domain中不存在這個user。
如果Request-URI和收到該request的任何domain都不匹配，那麼這個response也會被返回。
405 Method Not Allowed
Request-Line定義的method能夠被理解，但是不允許用於Request-URI給出的address。
該Response必須包含一個Allow字段，給出允許的method
406 Not Acceptable
The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request.
407 Proxy Authentication Required
408 Request Timeout
Server無法在合適的時間內產生response，比如無法決定Callee的Location。
UAC可以稍後重試。
410 Gone
請求的資源不再可用，且forwarding address未知。這種情況是permanent的。如果server不知道或者無法判斷是否permanent，那麼404應該被使用。
413 Request Entity Too Large
因爲請求中的entity-body（message-body ？）太大，Server不願意呢或者不能處理。
Server可能關閉connection，阻止UAC繼續。
如果是臨時的，那麼Server在response中攜帶Retry-After。
414 Request-URI Too Long
415 Unsupported Media Type
Server不支持Message body的格式。Server可能通過Accept，Accept-Encoding，Accept-Language字段返回其支持的format
416 Unsupported URI Scheme
Server不知道Request-URI的scheme
420 Bad Extension
Server不知道Proxy-Require或者Require字段定義的協議擴展。
Server必須在response的Unsupported字段中列出不支持的extensions。
421 Extension Required
Server需要特定的extenstion處理該請求，但沒有列在Supported字段中。響應的Require字段必須列出需要的extension。
除非UAS確實無法提供有用的服務，否則不應該使用該response。 如果需要的extension不在Supported字段中，那麼server應該使用baseline SIP capability和UAC支持的擴展處理該請求。
423 Interval Too Brief
Resource的refresh interval太短。response中的Min-Expires字段應該被使用。
480 Temporarily Unavailable
被叫的end system被聯繫到了，但是callee當前unavailable，比如：
- not logged in
- logged in but in a state that precludes communication with the callee
- has activated the "do not disturb" feature
Response中可能攜帶Retry-After，而該callee也可能在其它location available，但server不知道。
Reason-Phrase可能提供更精確的cause，其值應該是可以設置的。而486可能被用來指示更準確的失敗原因。
當redirect/proxy server認識Request-URI標識的user，但不知道其forwarding location時，該response也可能被redirect/proxy server使用。
481 Call/Transaction Does Not Exist
482 Loop Detected
483 Too Many Hops
484 Address Incomplete
指Request-URI不完整。Reason-Phrase提供額外信息。
485 Ambiguous
Request-URI模糊。響應中的Contact可能會列出可能的清晰地址。但這可能會泄露用戶的隱私。
因此，是使用404還是列出可能的選項，應該是在server端可配置的。
一些郵件系統提供這個功能，比如outlook。
486 Busy Here
被叫的end system能夠被聯繫到，但callee當前不希望，或者不能在這個end system上面接受額外的call。
Retry-After有可能在響應中；被叫有可能在其它location是available的。
如果Server知道沒有任何end system能夠接受這個call，那麼就使用600（Busy Everywhere）
487 Request Terminated
請求已經被BYE或者Cancel請求終止。這個響應不會用於Cancel。
488 Not Acceptable Here
與606同義，但只用於request-uri的特定resource。該請求在其它地方可能成功。
491 Request Pending
在同一個dialog內，UAS有一個pending request。 ch14.2描述瞭如何解決這個情況 ？
493 Undecipherable - 不可讀的
UAS收到的請求，包含一個加密的MIME body，但UAS卻沒有合適的界面key。
響應中可能提供一個用於加密MIME body的public key。
21.5 Server Failure 5xx
500 Server Internal Error
Server遇到了未預期的條件使其無法繼續處理請求。UAC可以顯示error，並在幾秒後retry
如果是臨時的，那麼可以使用Retry-After字段通知UAC。
501 Not Implemented
Server不支持處理請求的功能。當UAS不認識請求的method並且對任何user來說都是如此時，這個response是合適的。注意：
- Proxy轉發所有請求，不管method
- 405在server認識請求的method，但該method不允許或者不支持時使用。
502 Bad Gateway
Gateway或者Proxy從其下游server收到了一個invalid response，那麼就向UAC回502.
503 Service Unavailable
Server由於過載或者維護等原因，暫時無法處理請求。可以使用Retry-After通知UAC什麼時候可以重試。
UAC按照500處理。
收到503的A client(proxy or UAC)，應該forward請求到一個alternate server。在Retry-After指示的duration內，不應該向server發送任何其它請求。
----- 》 意思是說，503響應是針對UAC的，而不僅僅是針對這個call ？
Server也有可能拒絕連接，或者丟棄request，來代替503 response。
504 Server Time-out
Server在處理request時，可能需要訪問external server，但沒有得到及時響應。
如果在Expires字段定義的duration內，沒有從upstream server收到響應，那麼應該使用408（Request Timeout）。
505 Version Not Supported
Server不能或者不願意呢使用請求中的SIP version處理這個請求
513 Message Too Large
21.6 Global Failures 6xx
Server有關於特定user的足夠信息，比僅僅是Request-URI中給出的。此時可以使用6xx響應。
600 Busy Everywhere
被叫end system能夠聯繫到，但是被叫忙且不願意接聽。這個response有可能提供一個Retry-After。如果callee不想泄露reject reason，那麼可以使用603（Decline）。
這個response只用於server知道沒有其它的end point（比如語音信箱）會answer the request。否則應該使用486（Busy Here）
603 Decline
Callee's machine被聯繫到了，但user不想或者不能接聽。Retry-After。
使用該response，表明server知道沒有任何其它end point會answer the request。
604 Does Not Exist Anywhere
Server有足夠信息作出判斷，Request-URI指出的user在任何地方都不存在。
606 Not Acceptable
成功聯繫到了user's agent，但SDP的某些方面，比如request media，bandwidth，addressing style不能被接受。
該response表明，user希望接聽call，但不足以支持session discribed。
response可能會在Warning header字段列出一系列原因。
使用該響應時，server知道沒有其它的end point會處理該請求
UAS使用401（Unauthorized），而Proxy使用407（Proxy Authentication Required）。
22.1 Framework
由於SIP沒有canonical root URL，因此protection spaces在SIP中有不同的解釋。
realm用於定義protection domain，而RFC2543中則使用Request-URI和realm定義protection domain。
- realm必須全球唯一，推薦包含hostname或者domain name
- realm應該是能夠顯示給user的字符串
通常，SIP authentication只對特定的realm有意義，因此對於Digest authentication來說，每一個這樣的protection domain都有自己的usernames/passwords集合。
如果Server不要求對特定的request鑑權，那麼它可能使用默認的username “anonymous”，其沒有密碼（“”）。
類似的，代表許多user的UACs，比如PSTN gateways，可能有自己的username/password，而不是代表特定user。
有兩個請求的authentication需要特殊處理：Ack，Cancel。
Authentication Scheme包括：basic，digest，他們都依賴於response攜帶參數。
因此，對於沒有response的request的鑑權成了問題，包括Ack -》 如果Server接受了INVITE中的credentials，那麼Server也要接受對應Ack中的相同的credentials。UAC在構造Ack時，會原封不動拷貝INVITE消息中的Authorization和Proxy-Authorization header，而Server不能challenge the Ack
雖然Cancel有response，但Cancel request不能被重發，因此Server也不能challenge the Cancel request。
通常來講，Server應該接受來自其所cancel，如果該cancel來自與其所cancel請求相同的hop。
如果已有的credentials不再有效，Server可能會重複其challenge，或者響應403（Forbidden）。而UAC不能使用剛剛被reject的credentials。
22.2 User-to-User Authentication
UAS從UAC收到request後，可能會在處理前對originator進行鑑權。如果請求中沒有包含Authorization header，UAS可以通過401（Unauthorized）拒絕該請求。
WWW-Authenticate必須包含在401裏面，該challenge至少指出：
- Authentication scheme
- parameters applicable to the realm
例子：
WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
UAC收到401後，如果可能的話，應該重新發起該request，包含正確的credentials。UAC可能會請求user的輸入。
該credentials應該被cache起來，針對realm和To header的組合，以備後面的請求使用。
UAS則可以使用任意方式cache credentials。
如果UAC找不到任何credentials，它可能會使用username(anonymous)和password（""）重試。
例子：
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:[email protected]",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
當UAC收到401/407後重新發送reuquest時，應該增加CSeq header value，以表明是新的request。
22.3 Proxy-to-User Authentication
在forking的情況下，可能有多個proxy對UAC進行challenge，這時，執行forking的proxy負責把多個challenge組合到一個response中。而UAC在重新發送request時，會針對每個challenge提供Authorization。
當然，這些credentials中的realm參數不一樣。但challege中的realm參數卻可能一樣。
22.4 The Digest Authentication Scheme
SIP不使用 Basic Authentication Scheme
RFC2617要求server檢查Request-URI和Authorization中的參數uri，要求二者一致。但SIP中，二者有可能不一致。
如果challenge中攜帶qop參數，則credentials中必須攜帶。
credentials中攜帶cnonce的時候，必須攜帶qop參數。
23 S/MIME
----------------------------------------------------
SIP message可以攜帶MIME bodies，MIME標準包含了對MIME contents進行加密和完整性保護的機制。
但這會阻止某些server發生作用，比如firewall。
23.1 S/MIME Certificates
發送者使用接收者的public key進行加密，接收者使用自己的private key進行解密。
23.2 S/MIME Key Exchange
SIP本身可以用來分發public keys。當CMS SignedData message用於S/MIME，它必須包含certificate，包含驗證該簽名必需的public key。
23.3 Securing MIME bodies
The following is an example of an encrypted S/MIME SDP body
within a SIP message:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Contact:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Disposition: attachment; filename=smime.p7m
handling=required
*******************************************************
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=- *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
*******************************************************
23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP
作爲提供一定程度端到端鑑權、完整性保護、加密的手段之一，S/MIME可以封裝整個SIP消息到MIME bodies中，"message/sip"。
如果UAS收到的request中包含tunneled "message/sip" S/MIME body，那麼在response中也應該如此。
23.4.1 Integrity and Confidentiality Properties of SIP Headers
24 Flow
----------------------------------------------------
24.1 Registration
例子如下，request-uri指明registar，From和To相同，但To字段的tag沒有。
Via指出response的接收處，Expires指明2小時後過期。
--------------------------------------------------------
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob
From: Bob ;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact:
Expires: 7200
Content-Length: 0
response如下。Via的received參數指明在哪個IP上面收到的response。
To字段添加了tag
--------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob ;tag=2493k59kd
From: Bob ;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact:
Expires: 7200
Content-Length: 0
24.2 Session Setup