8.3.1 功能概述
如前所述，SIP是一个客户／服务器协议。协议消息分为两类：请求和响应。其中，请求消息从客户机发往服务器，响应消息则从服务器发往客户机。协议消息的目的是建立或终结会话，该会话可以是Internet多媒体会议、Internet电话呼叫或多媒体信息流分配。
SIP是通过＂邀请＂的法方来建立会话的。由同一个源邀请的一个会议的所有参加者构成一个呼叫，SIP呼叫由一个全局唯一的呼叫标识(Call--ID)予以标识。点到点1P电话会话是一种最简单的会话，它映射为单一的SIP呼叫。在通常情况下，呼叫由主叫方创建，但是更一般说来，呼叫可由并不参与媒体通信的第三方创建，此时会话的主叫方和会话的邀请方并不相同。对于多播会议来说，一个用户可由不同的人邀请参加同一会议，则每一个邀请应视作不同的呼叫。对于基于MCU的会议，每个参会者使用一个呼叫邀请自己加入
MCU。
正因为＂邀请”是SIP协议的核心机制，因此SIP请求消息最重要的一个操作就是＂邀请"(Invite)。发出邀请请求后，终接用户或网络应回送响应。在SIP中，响应分为两类。一类是中间响应，报告呼叫进展情况，如用户空闲、正在“振铃＂（提示用户）等；另一类为最终响应，包括成功响应和异常失败响应。客户和服务器之间的操作从第1个请求至最终响应为止的所有消息构成一个SIP事务。一个正常呼叫一般包含三个事务。其中，呼叫启动包含两个操作请求：邀请(Invite)和证实(ACK)，前者需要服务器回送响应，后者只是证实已收到最终响应，不需要服务器回送响应。呼叫终结包含一个操作请求：再见(Bye)。每个事务的SIP消息格式均相同，只是其调用的方法
（操作）和头部参数有所不同而已。
SIP协议定义的只是呼叫（会话）建立、终结和修改的信息，并不涉及媒体控制。媒体类型、编码格式、收发地址等信息仍由SDP协议传送，并作为SIP消息的消息体(body)和其头部一起传送。因此，支持基于SIP的多媒体通信应用的网元和终端必须能支持SDP。SIP响应消息的消息体还包含指示呼叫进展和失败原因的文本信息。
为了能正确传送协议消息，SIP还需解决两个重要的问题。一是寻址，即采用什么样的地址形式标识终端用户；二是用户定位。SIP沿用WWW技术解决这两个问题。寻址采用SIPURL，按照RFC2396 规定的URI导则定义其语法，特别是用户名字段可以是电话号码，以支持1P电话网关寻址，实现1P电话和PSTN的互通。用户定位基于登记和DNS机制。SIP用户终端上电后即向登记服务器(registrar)登记，SIP专门为此定义了一个“登记”(REGISTER)请求消息，并规定了登记操作过程。登记服务器通常和代理服务器或重定向服 务器位于一起，登记信息进入1P网络公共的定位服务器，SIP服务器可通过适当的协议访问该服务器，确定用户的位置。登记服务器本 身也能提供一定的定位服务。
SIP是一个应用层控制协议，它可以采用不同的传送层协议。如果采用UDP传送，要求响应消息沿请求消息发送的同样路径回送，以支待中间服务器对呼叫的监视和状态控制。对于经多播UDP发送的请求，其响应消息应送往同一个多播地址和目的端口。如果采用TCP传送，则同一事务的请求和响应需在同－TCP 连接上传送。同一客户至同一服务器的若于事务请求可用同－TCP连接，也可用不同的TCP连接。SIP消息格式及操作过程和传送协议无关。
SIP的主要用途是发起会话，邀请成员加人由其它手段广播和建立的会话，这些其它手段可为SAP、E-mail、新闻组(newsgroup)、Web主页等。SIP的设计是作为整个IETF多媒体数据和控制结构的一部分，该结构包含如下协议：RSVP、RTP、R'ISP、SAP和SDP，但SIP的功能和操作不依赖于上述任何协议。SIP本身不提供会议控制服务（如发言控制、投票等），也不能预留资源，但是可用SIP引入会议控制协议和资源预留协议。
SIP支持与其它呼叫建立和信令协议的互通，它可以通过所用的地址确定合适的SIP端系统及其使用的协议。例如，可由SIP确定呼叫方能经H.323或PSTN抵达，并给出相应的网关地址，然后由H.225或ISUP建立至终接用户的呼叫。
根据上述分析可知，SIP主要支持以下5个方面的功能：
．用户定位：确定通信所用的端系统位置。
．用户能力交换：确定所用的媒体类型和媒体参数。
．用户可用性判定：确定被叫方是否空闲和是否愿意加入通信。
．呼叫建立：邀请和提示被叫，在主被叫之间传递呼叫参数。
．呼叫处理：包括呼叫终结和呼叫转交(transfer)等。
为了实现上述功能而定义的SIP消息的一般格式为：
SIP消息＝起始行
为了实现上述功能而定义的SIP消息的一般格式为：
SIP消息＝起始行
* 消息头部(1个或多个头部）
CRLF（空行）
［消息体］
其中，起始行给出SIP版本、调用的请求操作（方法）、被用邀户的当前地址、响应类型等信息。消息头部分为4类：通用头部、请求头部、响应头部和实体头部。其中，通用头部可用于请求和响应消息，实体头部指示消息体的类型、编码和长度信息，请求头部和响应头部分别用于请求消息和响应消息。SIP2.0版本共定义了36种头部字段。空行表示消息头部字段的结束。消息体主要是SDP会话描述，在响应消息中还可能是原因和进展指示文本。上面描述中的符号“*”表示该字段可有多个。
SIP消息的语法基本上和HTTP相同，头部字段也和HTTP基本相同。但它可在UDP上传送。包括头部字段在内的UDP数据包长度不应超过路径的最大允许传输单元(MTU)，如果MTU未知，则最大长度可取为1500字节（以太网MTU典型值）。
下面进一步说明SIPURL结构以及请求和响应消息格式和操作过程。
8.3.2 SIP URL结构
SIPURL的一般结构为：
SIP：用户名：口＠令主机：端口；传送参数；用户参数；方法参；数生存期参数；服务器地址参数？头部名＝头部值
为了便于理解，在此未采用严格的BNF形式化表示形式。该结构和一般的URI相同。其中，SIP表示需采用SIP协议和所指示的端系统通信。用户名可由任意字符组成，一般可取类似于E-mail用户名的形式。SIPURL的一个特定功能是允许主机类型为IP电话网关，此时，用户名可以为一般的电话号码。由于BNF语法表示无法区分电话号码和一般的用户名，因此，在域名后增加了“用户参数”字段。该字段有两个可选值：IP和电话，当其设定为“电话”时，表示用户名为电话号码，对应的端系统为1P电话网关。“主机”可为主机域名或IPv4 地址。“端口”指示请求消息送往的端口号，其缺省值为5060,即公开的(Well-known)SlP端口号。口令可以置于SIPURL中，但一般不建议这样做，因为其安全性是有问题的。
传送参数指示采用TCP还是UDP传送，缺省值为UDP。服务器地址参数指示和该用户通信的服务器地址，它覆盖”主机”字段中的地址，通常为多播地址。生存期参数指示UDP多播数据包的寿命，仅当传送参数为UDP、服务器地址参数为多播地址时才能使用。方法参数则指明所用的方法（操作）。这些参数均属于URL参数，只能在重定向地址，即后面所说的Contact字段中才能使用。URL的最后还可附加若干个头部字段值，指明和该用户通信的相关参数。也只 能在Contact字段中使用。
下面给出若干个SIPURL的示例：
Sip:j.doe@big.com
Sip:j.doe:seeret@big.com;transport=tcp?subject=project
Sip:+1-212-555-1212:1234@gateway.com;user=phone
Sip:+1-212-555-1212:1234@gateway.com;user=phone
Sip:alice@10.1.2.3
Sip:alice@registrar.com;method=REGISTER
在SIP消息中，URL可以用来指示请求的源、想要抵达的目的地，重定向地址以及请求的当前目的地，分别置于FROM、TO、Contact头部字段和起始行的Request-URI中。
8.3.3 请求消息格式和操作
1.诮求消息格式请求消息格式为：
请求消息＝请求起始行
＊（通用头部
I 请求头部
I实体头部）
空行
空行
［消息体］
其中，请求起始行＝方法-请求URI-SIP版本号↘。方法就是请求执行的操作。SIP共定义了6个方法：邀请(INVITE)、证实(ACK)、选择(OPTIONS)、再见(BYE)、取消(CANCEL)和登记(REGISTER)，所有方法名必须大写。请求－URI(Request-URI)是被邀用户的当前地址。SIP版本号现设定为SIP/2.0。
一个最简单的INVITE请求消息可为：
INVITESip:watson@boston.hell-tel.comSIP/2.0
Via:SIP/2.0/UDPkton.hell-tel.com
Via:SIP/2.0/UDPkton.hell-tel.com
From:A.Bell< Sip:a.g.hell@hell-tel.com>
To:T.Watson<Sip:Watson@hell-tel.com>
Call-ID:3298420296@kton.hell-tel.com
Cseq:1 INVITE
To:T.Watson<Sip:Watson@hell-tel.com>
Call-ID:3298420296@kton.hell-tel.com
Cseq:1 INVITE
在此，对各个字段作一简要说明。
From字段指示请求发起方的地址；To字段指示请求发送目的终端的地址，由发起方设定；起始行中的Request-URI为目的终端的当前地址，一般说来，它和To字段的地址值相同。两者的区别是，To字段指示的是终端用户的永久地址，由于移动性或其它原因该用户 的当前地址可能会和永久地址有所不同。在请求消息传送过程中， 代理服务器可能根据定位查询结果更改Request-URI，但To字段地址
值始终保持不变。另一地址字段是Contact，它在重定向服务器向请求发送方回送的响应消息中指示目的用户的更新地址，除此以外在登记消息及其它响应消息中还有其它的用途。该地址字段在上述消息中未予包含。上述宇段的地址值均用SIPURL形式表示。Via字段指示的是该请求消息历经的中间服务器，每经过一个服务器，应根据其地址构造一个新的Via字段，加入Via字段列表的顶端，其目的是保证响应消息沿原路返回请求发起方，同时也可在请求消息前传过程中供中间服务器校核，以防止路由环路的出现。
Call-ID字段为标识呼叫的全局唯一的标识符，据此识别若干请求消息是否属于同一呼叫。Cseq为命令序号字段，标识同一呼叫控制序列中的不同命令，如INVITE命令和BYE命令。
2.方法
(1)INVITE
该方法用来邀请用户或应用程序加入某会话，会话描述含于消息体中。对于两方呼叫来说，主叫方在会话描述中指示其能够接受的媒体类型及其参数，还可以指示其愿意发送的媒体类型。被叫方必需在成功响应消息的消息体中指明其希望接受哪些媒体，还可以指示其行将发送的媒体。
如果收到的是关于参加会议的邀请，服务器可以根据Call-ID或者会话描述中的标识确定用户已经加人该会议，此时服务器可自动返回成功响应消息。
如果用户代理收到关于已有呼叫的一个新的邀请(Cseq值大于以前收到的INVITE消息），则应检查该消息的头部或会话描述是否有变化，如有变化，则应调整相应的内部状态及信息或者媒体参数。
(2)ACK
ACK请求用于证实客户机已收到对于INVITE请求的最终响应，该方法仅和INVITE消息配套使用。成功响应由用户代理客户程序(UAC)予以证实，不成功响应由第一个收到此响应的代理服务器或UAC证实。ACK消息的Via字段总是初始化为发出该消息的主机地
址，网络根据其Request-URI和对应的INVITE消息一样予以前传。这一机制表明SIP会话建立采用的是邀请一响应一证实三次握手过程，对于证实消息不再回送响应。
ACK请求可以有消息体，其中给出被叫使用的最终会话描述。如果不含消息体，则被叫就使用INVITE请求中的会话描述。
代理服务器发出不成功响应后，应对收到的ACK进行判别，确定该ACK是发给该服务器的还是应由其前转。其判别方法是比较ACK的T（o 包括其中的标记子字段）、From、Cseq和Call-ID字段是否和响应消息相同。若相同，则ACK是对于该服务器的证实，否则应继续向下行方向前传。
(3)OPTONS
该方法用于询问服务器的能力。某服务器确信能与用户通信，如用户在某用户代理上登记并处在激活状态，该用户代理收到该请求后就可发回响应消息，告之其能力集。被叫用户代理还可回复其忙闲等状态信息，并应回复一个“允许"(Allow)头部字段，指示它支持的方法。代理服务器和重定向服务器仅前转消息，并不指示它们自己的能力.
(4)BYE
用户代理客户程序用此方法指示释放呼叫。BYE请求按INVITE请求同样方式前传，可由主叫方或被叫方发出。某一方收到BYE请求后就应停止向发起BYE请求的另一方发送媒体流。
(5)CANCEL
该方法用于取消一个尚未完成的请求，对于已完成的请求（即已收到最终响应的请求）则没有影响。
UAC和代理服务器可在任何时刻发出CANCEL请求。如果代理服务器曾向多个目的地发送过请求，其中1个或多个目的地已回送最终响应，服务器仍可向其余目的地发送CANCEL请求。同样，代理服务器收到CANCEL请求时，应向所有目的地并行转发此请求。
CANCEL请求和被取消的原有请求的Call-ID、From、To字段及Cseq字段的数字部分应完全相同。为了使客户程序能区分对CANCEL和原有请求的响应，Cseq的方法部分置成CANCEL。
(6)REGISTER
客户程序使用该方法在SIP服务器上登记列于To字段中的地址。
用户代理在启动时向地址“Sip.mcast.net"(224.0.1.75)发送REGISTER请求，以完成至本地服务器的登记。该地址是公开的”所有SIP服务器“多播地址，其范围应设定为不越出管理域边界。SIP用户代理也可以守听该地址以获知其它本地用户的位置，但是它们并不对此登记请求作出响应。用户代理也可配置一个指定的登记服务器地址，这样在启动时就向该服务器进行登记。
登记请求按接受顺序进行处理，客户程序必须在收到对前一登记请求的响应后才能发出下一个新的登记。
对于REGISTER请求消息来说，前述主要头部字段的意义有所不同。我们用“记录地址”表示登记服务器识别登记者的SIP地址（相当于用户的姓名），该地址形式一般为“用户＠域＂，而不是“用户＠主机”。在第三方登记时，发出请求的实体和登记实体是不同的。按照这样的理解，相关字段的意义为：
To：为其登记将被创建或更新的用户的记录地址。
From：为登记人的记录地址。对于第一方登记情况来说，它和To字段的值相同。
Request-URI：指示登记请求的目的地，即登记服务器的所在域。其用户名必须为空，域名一般和To字段相同，但是在作为”来访者”登记时，二者可能不同。例如，来访者Sip:alice@ acme.com(To)可能在Request-URISip:atlanta.hiayh.org下登记，前者是To字段值，后者是Request-URI值。一旦REGISTER请求到达某服务器，其授权域和Request-URI所列域相同，该请求就不再前传。
Call-ID：从同一客户发出的所有登记，其Call-ID头部值应相同。重启动后其值可以改变。
Cseq：同一Call-ID的不同登记，其Cseq值应逐次递增。但是服务器不会扑绝失序的请求，总是按接受顺序处理，用新的登记请求取代以前的请求。
Contact：请求可以包含该字段。未来至To字段中给定的URI的非REGISTER请求应转至Contact字段给定的地址。
如果在用户代理或代理服务器处理邀请请求时登记发生变化，则应使用该更新的信息。该服务称为“定向代答(directed pick-up),相当于电话网中的代答功能：用户在另一电话机旁听到自己电话机振铃，可以用当前话机摘机应答。
服务器可以自行选定登记生存期，超过该段时间未刷新，该登记就自动丢弃。登记请求的响应消息中应包含一个“失效”(Expires)头部字段，指明选定的生存期，如果未含此字段，就表示生存期为1 个小时。客户也可在登记请求中用Expires字段指明所要求的登记生存期。服务器选定的生存期只能低于此要求值，而不能高于此值。若干不同的客户可以登记为同一个地址，此地址应为与主机无关的地址。
客户可发送一个即：GISTER请求，置失效时间为0秒，表示删除已有的登记。该删除请求可带Contact字段。如果Contact字段值为通配符”*"，则表示所有登记均予删除。
服务器回送的成功响应消息中应包含Contact头部字段，列出当前登记地址列表。
对于REGISTER请求来说，至为重要的一点是必须进行鉴权，因为它决定了其后请求的转向目的地。
3.主要头部字段
(I)From
所有请求和响应必须包含此字段，以指示请求的发起者。服务楛将此字段从请求消息复制到响应消息。
该字段的一般格式为：
From：显示名(SIP-URL〉;tag=xxxx
其中，显不名为用户界面上显示的字符，如果系统不予显示，应置显示名为＂匿名“”(Anonymous)＂。显示名为任选子字段。tag称为标记，为16进制数字串，中间可带连字符”-"。当两个共享同－SIP地址的用户实例用相同的Call-ID发起呼叫邀请时，就需用此标记予以区分。标记值必须全局唯一。用户在整个呼叫期间应保持相同的Call-ID和标记值。
From字段的示例可为：
From:"A.G.Bell"<Sip:agb@bell- telephone.com>From:Sip:+12125551212@server.phone2net.com
From:Anonymous<Sip:c80qz84zk7z@privacy.org>
From:Anonymous<Sip:c80qz84zk7z@privacy.org>
(2)To
该字段指明请求的接收者，其格式和From相同，仅第一个关键词代之以To。所有请求和响应消息必须包含此字段。
字段中的标记参数可用于区分由同一SIPURL标识的不同的用户实例。由于代理服务器可以并行分发多个请求，同一请求可能到达用户的不同实例（如宅内电话、移动电话等）。由于每个实例都可能响应，因此需用标记来区分来自不同实例的响应。标记还能用于多播请求，藉此可在VAC区分来自不同用户的响应。需要注意的是，To字段中的标记是由每个实例置于响应消息中的。当接收者从Via字段判知请求消息经由代理服务牉转发时，它无从知道该代理是否执行了分发操作，因此为了保险起见，应假定代理已执行该操作，故应在响应的To字段中置入标记。标记应由UAS、登记服务器或重定向服务器置入，代理服务器不能在上行前转的响应中加人标记。
To字段的示例可为：
To:1heOperator<sip:operator@cs.co1umbia.edn>;tag=287447
To:sip:t12125551212@server.phone2net.com
To:sip:t12125551212@server.phone2net.com
(3)Call-ID
该字段用以唯一标识一个特定的邀请或标识某一客户的所有登记。需要注意的是，一个多媒体会议可能会有多个呼叫，每个呼叫有其自己的Call-ID。例如，某用户可数次邀请某人参加同一历时很长的会议。
收到INVITE请求后，如果确认用户己对该Call-ID作出响应，则被叫UAS不应再向用户发出提示信息。如果用户已是某会议的成员，且会话描述中的会议参数也没有变化，则被叫UAS接受此呼叫，不作提示，也不校核Call-ID。若收到的邀请的Call-ID已存在但会议参数发生变化，则用户应用程序可以通告用户，并自动接受此邀请，也可以等待用户的确认。
用户可能会收到数个参加同一会议或呼叫的邀请，其Call-ID各不相同。客户可以利用会话描述中的标识，例如SDP中o（源）字段的会话标识和版本号判定这些邀请的重复性。
REGISTER和OPTIONS方法利用Call-ID值无岐义地匹配响应和请求。
Call-ID的一般格式为：
Call-ID：本地标识＠主机
其中，主机应为全局定义域名或全局可选路1P地址，此时，本地标识由在“主机”范围内唯一的URI字符组成。否则，本地标识必须是全局唯一的值，以保证Call-ID的全局唯一性。Call-ID字符需区分大小写。
Call-ID的示例可为：
Cal.1-m:f8ld4fae-7dec- lld0-a765-00a0c91ebbfb@foo.bar.com
在SIP中，Call-ID、To和From三个字段标识一个呼叫分支(Callleg)。在代理服务器并行分发请求时，一个呼叫可能会有多个呼叫分支。
(4)Csdp
Cseq称之为命令序号。客户在每个请求中应加人此字段，它由请求方法和一个十进制序号组成，该序号由请求客户选定，在Call-ID范围内唯一确定。序号初值可为任意值，其后具相同Call-ID值，但不同请求方法、头部或消息体的请求，其Cseq序号应加1。重发请求的序号保持不变。服务器将请求中的Cseq值复制到响应消息中。
ACK和CANCEL请求的Cseq值和对应的INVITE请求相同，BYE请求的Cseq序号应大于INVITE请求。UAS必须记忆相同CalLID的INVITE请求的最高序号，收到序号低于此值的INVITE请求应在给出响应后予以丢弃。
由代理服务器并行分发的请求，其Cseq值相同。严格说来，Cseq对于任何可由BYE或CANCEL请求取消的请求以及客户可连续发送多个具相同Call-ID请求的情况都是需要的，其作用是判定响应和请求的对应关系。
Cseq的示例可为：Cseq:4711 INVTTE
(5)Via
Via字段用以指示请求历经的路径。它可以防止请求消息传送产生环路，并确保响应和请求消息选择同样的路径，以保证通过防火墙或满足其它特定的选路要求。
发起请求的客户必须将其自身的主机名或网络地址插入请求的Via字段，如果未采用缺省端口号，还需插入此端口号。在请求消息前传过程中，每个代理服务器必须将其自身地址作为一个新的Via字段加在已有的Via字段之前。如果代理服务器收到一个请求，发现其自身地址位于Via头部中，则必须回送响应＂检测到环路”。
当请求消息通过网络地址翻译点（如防火墙）时，请求的源地址和端口号可能被改变，此时Via字段就不能成为响应消息选路的依据了。为了防止这一点，代理服务器应校验顶端Via字段，如果发现其值和代理服务器检测到的前站地址不符，则应在该Via 字段中加入,'receiv叫＂参数，如此修改后的字段称为“接收方标记Via头部字段＂。例如：
Via:SIP/2. 0/UDP erlang.bell-telephone.com:5060
Via:SIP/2.0/UDP10.0.0.1:5060;received::::199.172.136.3表示由点10.0.0.l 发出的请求消息路径外部地址为border.ieee.org
Via:SIP/2.0/UDP10.0.0.1:5060;received::::199.172.136.3表示由点10.0.0.l 发出的请求消息路径外部地址为border.ieee.org
一(199.172.136.3)的网络地址翻译点后，到达代理服务器erlang.belltelephone.com。后者注意到前站发送地址和Via字段地址不符，就把实际发送地址作为接收方标记加在顶端Via字段的末尾，然后再将代理自己的地址作为新加的Via字段置于最上面。
若代理服务器向多播地址发送请求，则必须在其Via头部字段中加入“多播地址”(maddr)参数，此参数指明该多播地址。
代理服务器或UAC收到响应时对Via头部字段的处理规则是：
①第1个Via头部字段应该指示本代理服务器或UAC。如不是，则丢弃该消息；否则，删除该Via字段。
②如果没有第2个Via头部字段，则该响应已到达目的地。否则，继续作如下处理。
③如果第2个Via 字段包含,'maddr”参数，则按该参数指示的多播地址发送响应，端口号由“发送方”(sent-by) 参数指明，如未指明，就使用端口号5060。响应的生存期应置为“生存期”(ttl)参数指定的值，如未指明，则置为1。
如果第2个Via字段不包含,'maddr”参数，但有一个接收方标记字段，则应将响应发往"received”参数指示的地址。
如果既无“maddr”参数，又无标记，就“按Sentby”参数指示的地址发送响应。
Via字段的一般格式为：
Via：发送协议发送方；隐藏参数；生存期参；数多播地址参数；接收方标记；分支参数
其中，发送协议的格式为：协议名／协议版本／传送层，协议名和传送层的缺省值分别为SIP和UDP。发送方为通常的发送方主机和端口号。隐藏参数就是关键词hidden，如有此参数，表示该字段已由上游代理予以加密，以提供隐私服务。多播地址参数和接收方标记的意义已如前所述。生存期参数与多播地址参数配用。分支参数用于代理服务器并行分发请求时标记各个分支，当响应到达时，代理可判定是哪一分支的响应。
Via字段的示例可为：
Via:SIP/2.0/UDPfirst.example.com:4000;ttl=16;maddr=224.2.0.1;branch=a7c6a8伽(Example)此字段包含了除接收方标记以外的所有子字段。
(6)Contact
该字段用于INVITE、ACK和REGISTER请求以及成功响应、呼叫进展响应和重定向响应消息，其作用是给出其后和用户直接通信的地址。
INVITE和ACK请求中的Contact字段指示该请求发出的位置。它使被叫可以直接将请求（如BYE请求）发往该地址，而不必借助Via字段经由一系列代理服务器返回。
对INVITE请求的成功响应消息可包含Contact字段，它使其后SIP请求（如ACK请求）可直接发往该字段给定的地址。该地址一般是被叫主机的地址，如果该主机位于防火墙之后，则为代理服务器地址。
对应于INVITE请求的呼叫进展响应消息中包含的Contact字段的含义和成功响应消息相同。但是，CANCEL请求不能直接发往该地址，必须沿原请求发送的路径前传。
REGISTER请求中的Contact字段指明用户可达位置。该请求还定义了通配Contact字段”*"，它只能和值为0的“失效”字段配用，
表示去除某用户的所有登记。Contact字段也可设定“失效”参数（任选参数），给定登记的失效时间。如果没有设定该参数，则用“失效”字段值作为其缺省值。如果两者均无，则认为SIPURI的失效时间为1小时。
REGISTER请求的成功响应消息中的Contact字段返回该用户当前可达的所有位置。
重定向响应消息，如用户临时迁移、永久迁移、地址模糊等消息中的Contact字段给出供重试的其它可选地址，可用于对BYE、INVITE和OPTIONS方法的响应消息。
需要指出的是，Contact 字段也可包含非原被叫地址，例如，和GSTN网关相连的SIP呼叫可能需要向主叫发送录音通知，此时将转至另外一个地址。
SIP协议为Contact字段定义了如下参数：
． q：其取值范围为[O,1]，指示给定位置的相对优先级。数值越大，优先级越高。
．动作：该参数仅用于REGISTER请求。它表明希望服务器对其后至该客户的请求进行代理服务还是重定向服务。如果未含此参数，则执行动作取决于服务器的配置。服务器在响应消息中应指明使用的模式。
．失效：指明URI的有效时间。其意义前已述及。
Contact字段的一般格式为：
Contact：地址；q参数；动作参数；失效参数；扩展属性
其中，地址的表示形式和To.From字段相同，扩展属性就是扩展名。动作参数只有两个取值：代理或重定向。失效参数可用秒表示，也可用SIP日期表示。
Contact字段的示例为：
Contact:"Mr.Watson"<Sip:watson@worcester.bell-telephone.com
>;q=0.7;expires=3600,
"Mr.Watson"(mailto:watson@bell-telephone.com〉;
q=O.l
由此例可知，Contact字段给定的地址不限于SIPURJ，也可以是电话、传真等URJ或mailto:URL。
