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="47364c23432d2e131a5fb210
Authorization
包含UA的authentication credentials 。这个不同于其它字段，多行不能合并到一行。
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a21
response="7587245234b3434cc3412213
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
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: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
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="f84f1cec41e6cbe5aea9c8e8
realm：表明保护范围，包含一个主机或者域名，不一定和SIP domain一致；
qop：Quanlity Of Protection, 取值：auth,auth-int，后者是完整性保护；
Proxy-Authorization
允许Client向Proxy表明自己是谁。
Proxy-Authorization: Digest username="Alice",realm="atlanta.com",nonce="c60f3082ee1212b402a21831
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="f84f1cec41e6cbe5aea9c8e8
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。
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
UAC收到401后，如果可能的话，应该重新发起该request，包含正确的credentials。UAC可能会请求user的输入。
该credentials应该被cache起来，针对realm和To header的组合，以备后面的请求使用。
UAS则可以使用任意方式cache credentials。
如果UAC找不到任何credentials，它可能会使用username(anonymous)和password（""）重试。
例子：
Authorization: Digest username="bob",
当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
The following is an example of an encrypted S/MIME SDP body
within a SIP message:
INVITE sip:bob@biloxi.com 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
78
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
