SIP消息头域的说明
SIP协议主要消息 (3)
SIP协议主要消息协议名称：SIP协议主要消息一、引言本协议旨在详细描述SIP（Session Initiation Protocol，会话初始协议）的主要消息，包括其定义、结构和功能。
SIP是一种用于建立、修改和终止多媒体味话的应用层协议，广泛应用于VoIP（Voice over Internet Protocol，互联网语音通信）和实时通信系统中。
二、协议概述SIP协议主要通过请求和响应的方式进行通信，使用文本格式的消息进行交互。
SIP消息由起始行、头部字段和消息体组成，其中起始行包含请求或者响应的方法、URI（Uniform Resource Identifier，统一资源标识符）和SIP版本信息。
头部字段包含了关于消息的元数据，而消息体则携带了具体的数据内容。
三、主要消息类型1. INVITE：该消息用于建立会话，发起方向被叫方发送INVITE请求，包含了被叫方的SIP地址和媒体描述信息。
2. ACK：该消息用于确认INVITE请求的接收，发起方在收到200 OK响应后发送ACK请求，表示会话建立成功。
3. BYE：该消息用于终止会话，可以由任意一方发送，对方收到BYE请求后会发送200 OK响应，表示会话终止。
4. CANCEL：该消息用于取销未完成的请求，普通用于取销INVITE请求，以便重新发起新的请求。
5. REGISTER：该消息用于注册用户地址，用户向服务器发送REGISTER请求，以便在服务器上注册自己的SIP地址。
6. OPTIONS：该消息用于查询服务器的能力，普通用于检测对方是否在线或者支持特定功能。
7. INFO：该消息用于传输非实时信息，如传输DTMF（Dual-tone Multi-frequency）信号等。
四、消息格式和示例1. INVITE消息格式：```INVITE sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhdsMax-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 INVITEContact: <sip:bob@example>Content-Type: application/sdpContent-Length: 142v=0o=bob 2890844526 2890844526 IN IP4 192.0.2.1s=-c=IN IP4 192.0.2.1t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000```2. ACK消息格式：```ACK sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 ACKContact: <sip:bob@example>Content-Length: 0```3. BYE消息格式：```BYE sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314160 BYEContact: <sip:bob@example>Content-Length: 0```4. CANCEL消息格式：```CANCEL sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314159 CANCELContact: <sip:bob@example>Content-Length: 0```5. REGISTER消息格式：```REGISTER sip:example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:bob@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314161 REGISTERContact: <sip:bob@example>Expires: 3600Content-Length: 0```6. OPTIONS消息格式：```OPTIONS sip:example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314162 OPTIONSContact: <sip:bob@example>Content-Length: 0```7. INFO消息格式：```INFO sip:alice@example SIP/2.0Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK776asdhds Max-Forwards: 70To: <sip:alice@example>From: <sip:bob@example>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 314163 INFOContact: <sip:bob@example>Content-Type: application/dtmf-relayContent-Length: 18Signal=1Duration=100```五、总结SIP协议的主要消息包括INVITE、ACK、BYE、CANCEL、REGISTER、OPTIONS和INFO。
Sip消息标题头及选择项备忘
Sip消息标题头及选择项备忘Branch:利用branch ID参数的唯一性作为事务的ID（transaction ID）,根据本标准产生的branch ID必须用”z9h64bK”开头。
Rport:路由器的UDP端口。
Expires:有效期Tag:作为一个通用的机制的一部分来唯一标志一个对话，用于SIP信令中"To" "From"标签中。
当一个用户代理第一次发起会话的request,它只在From中包含一个tag,To中没有。
当返回一个response后才在To中也包含一个tag。
之所以要使用tag，是因为一个request可能会建立多个Dialog所以不能单用Call-ID去区分Dialog.同时,生成的tag必须是唯一的，可以用一些加密算法生成一个32位随机数。
Supported:列举了UAC/UAS所支持的扩展。
100rea l：100rel扩展即是对中间状态响应的确认（即1xx的响应码）。
原先在sip里，只有针对invite请求的200ok响应才会有ack，那么当中间状态响应携带重要的会话参数信息时，例如183响应，客户端是否收到响应就没有ack请求了，于是就定义了prack这一请求消息，即对中间状态响应的确认请求。
当sip发送者支持这一扩展时，及在support头域增加这个100rel 消息，当server端给与1xx响应时，可以在头域里的require字段要求这一100rel的能力。
此时，sip发送者，发送prack消息。
GRUU:GRUU主张在全球路由使用者代理的URI的。
往往有情况下，一个单一的公共用户身份是共同的很多私人用户身份。
在这种情况下，传入会议的要求，是'岔'到终端的。
这分岔，可连续或并行。
有时候，可能有必要为了避免这种分杈的请求到多个终端的实例，我们可能需要请求发送到特定的终端，对于这种情况，我们需要支持GRUU.Update:Sip的UPDATE（RFC3311）消息是SIP扩展的一种机制，用以在通话尚未建立的时候更新媒体流状态的一种机制。
SIP协议主要消息
SIP协议主要消息协议名称：会话发起协议（Session Initiation Protocol，简称SIP）1. 引言本协议旨在规范会话发起协议（SIP）的主要消息格式和内容。
SIP是一种应用层协议，用于在IP网络上建立、修改和终止多媒体会话，如语音通话、视频会议和即时消息。
本协议的目的是确保SIP消息在各个实现之间的互操作性和一致性。
2. 消息格式SIP协议定义了以下主要消息类型：2.1 请求消息请求消息由客户端发送给服务器，用于请求资源或执行操作。
请求消息的格式如下：请求行头部字段空行消息体请求行包括请求方法、请求URI和SIP协议版本。
常见的请求方法包括INVITE（邀请对方参与会话）、REGISTER（注册用户位置信息）、ACK（确认消息接收）等。
头部字段包括各种标准字段和扩展字段，用于传递请求的相关信息，如From （发送者身份）、To（接收者身份）、Call-ID（会话标识符）、CSeq（序列号）等。
消息体可选，用于传递请求的实体内容，如SDP（会话描述协议）等。
2.2 响应消息响应消息由服务器发送给客户端，用于回应请求或指示操作结果。
响应消息的格式如下：状态行头部字段空行消息体状态行包括SIP协议版本、状态码和原因短语。
常见的状态码包括1xx（信息性响应）、2xx（成功响应）、3xx（重定向响应）、4xx（客户端错误响应）、5xx （服务器错误响应）等。
头部字段包括各种标准字段和扩展字段，用于传递响应的相关信息，如From、To、Call-ID、CSeq等。
消息体可选，用于传递响应的实体内容，如SDP等。
3. SIP消息示例以下是一些常见的SIP消息示例：3.1 INVITE请求消息示例：INVITEsip:********************/2.0Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK123456789From:sip:***************;tag=12345To:sip:*****************Call-ID:***************.2.1CSeq: 1 INVITEContact:sip:***************Max-Forwards: 70Content-Type: application/sdpContent-Length: 142v=0o=bob 2890844526 2890844526 IN IP4 192.0.2.1s=-c=IN IP4 192.0.2.1t=0 0m=audio 49170 RTP/AVP 03.2 200 OK响应消息示例：SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK123456789 From:sip:***************;tag=12345To:sip:*****************;tag=54321Call-ID:***************.2.1CSeq: 1 INVITEContact:sip:*****************Content-Type: application/sdpContent-Length: 142v=0o=alice 2890844527 2890844527 IN IP4 192.0.2.2s=-c=IN IP4 192.0.2.2t=0 0m=audio 49172 RTP/AVP 04. 总结本协议详细描述了SIP协议的主要消息格式和内容要求。
sip协议详解
SIP协议详解1. 引言Session Initiation Protocol（SIP）是一种用于建立、修改和终止多媒体会话的通信协议。
它广泛应用于语音、视频和即时通讯等实时通信领域。
本文将对SIP协议进行详细解析，介绍其基本原理和主要特点。
2. SIP协议概述SIP协议是基于文本的应用层协议，使用可读的ASCII文本来进行消息交换。
它采用客户端/服务器（C/S）模型，其中用户代理作为客户端，SIP服务器作为服务器。
SIP消息的格式包括请求消息和响应消息两种类型。
3. SIP消息格式SIP消息由起始行、头部字段和消息体组成。
起始行包括请求行或状态行，用于表示消息的类型和状态。
头部字段包含了一系列的键值对，用于传递消息的各种参数和选项。
消息体用于传输实际的数据内容。
4. SIP会话的建立与终止SIP协议通过INVITE/200 OK消息实现会话的建立，通过BYE消息实现会话的终止。
当用户A希望与用户B建立一个通话时，用户A向SIP服务器发送INVITE 消息，SIP服务器将该消息转发给用户B。
用户B可以选择接受INVITE消息，然后发送200 OK消息给用户A，表示接受通话请求。
当通话结束时，任一用户可以发送BYE消息，通知对方终止通话。
5. SIP注册与鉴权SIP协议支持用户注册和鉴权机制，以实现用户身份验证和安全通信。
用户在注册时，将自己的身份信息发送给SIP服务器，服务器将该信息保存起来。
当用户发起通话请求时，服务器可以根据用户的身份进行鉴权，确定用户是否具有通话的权限。
6. SIP中继与路由SIP协议支持中继和路由机制，以实现跨网络的通信。
SIP中继允许SIP消息在不同的网络之间传输，保证了用户可以在不同的网络环境下进行通话。
SIP路由机制允许SIP消息根据特定的规则进行转发，以找到正确的接收者。
7. SIP扩展与应用SIP协议允许进行扩展，以满足不同应用场景的需求。
例如，SIP可以与其他协议结合使用，如SDP（Session Description Protocol）用于传输会话描述信息。
Sip协议消息解释
20 头域头域的语法描述在7.3节。
本节列出了头域的全部列表，包括了语法注释，含义，和用法。
通过本节，我们使用[HX.Y]指当前HTTP/1.1 的RFC2616[8]的规范的X.Y节。
每个头域都有示例给出。
关于与方法和proxy处理有关的头域字段在表2和表3中有处理。
“where”列描述了在头域中能够使用的请求和应答的类型。
这列的值是：R:头域只能在请求中出现；r:头域只能在应答中出现；2xx，4xx，等等：一个数字的值区间表示头域能够使用的应答代码。
c：头域是从请求拷贝到应答的。
如果”where”栏目是空白，表示头域可以在所有的请求和应答中出现。
“proxy”列描述了proxy在头域上的操作a：如果头域不存在，proxy可以增加或者连接头域m：proxy可以修改现存的头域值d：proxy可以删除头域值r：proxy必须能读取这个头域，因此这个头域不能加密。
接下来6个栏目与在某一个方法中出现的头域有关：c：条件；对头域的要求依赖于消息的内容m：头域是强制要有的。
m*：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
o：头域是可选的。
t：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
客户端/服务端都需要准备接收没有这个头域的消息。
如果通讯的协议是基于面向流的协议（比如TCP），那么头域值必须被发送。
*：如果消息体不为空，那么头域值就绪要的。
（细节请参见20.14,20.15和7.4节）-:这个头域是不适用的。
“Optional”意味着这个元素可以在请求或者应答中包含这个头域，并且UA可以忽略在请求或者应答中存在的这个头域（这条规则有一个例外，就是Require头域，在20.32节有描述）。
”mandatory”（强制）头域是必须在请求中存在的头域，并且也必须是UAS 接收到一个请求时能够理解的头域。
一个强制头域必须也在应答中出现，并且UAC也能处理这个头域。
SIP协议主要消息
SIP协议主要消息协议名称：SIP协议主要消息协议简介：SIP（Session Initiation Protocol，会话初始化协议）是一种用于建立、修改和终止多媒体会话的通信协议。
它被广泛应用于IP电话、实时视频会议、即时消息和在线游戏等通信领域。
SIP协议主要通过消息进行通信，本文将详细介绍SIP协议的主要消息格式和功能。
一、SIP请求消息格式：SIP请求消息由请求行、首部字段和消息正文组成。
以下是SIP请求消息的主要字段：1. 请求行：- 方法（Method）：用于指定请求的类型，如INVITE、REGISTER、OPTIONS等。
- 请求URI（Request-URI）：指定请求的目标资源。
2. 首部字段：- Call-ID：唯一标识会话的ID。
- CSeq：命令序列号，用于标识请求的顺序。
- From：发起请求的用户标识。
- To：请求的目标用户标识。
- Via：传输路径和协议版本。
- Max-Forwards：限制请求转发的次数。
- Content-Type：消息正文的类型。
3. 消息正文：- 消息正文可以包含任意类型的数据，如SDP（Session Description Protocol）描述会话信息等。
二、SIP响应消息格式：SIP响应消息由状态行、首部字段和消息正文组成。
以下是SIP响应消息的主要字段：1. 状态行：- 版本号：SIP协议的版本号。
- 状态码：用于指示请求的处理结果，如200 OK表示成功，404 Not Found 表示未找到资源等。
- 原因短语：对状态码的简要描述。
2. 首部字段：- Call-ID：与请求消息中的Call-ID字段相同，用于标识会话。
- CSeq：与请求消息中的CSeq字段相同，用于标识请求的顺序。
- From：与请求消息中的From字段相同，标识请求发起方。
- To：与请求消息中的To字段相同，标识请求目标方。
- Via：与请求消息中的Via字段相同，表示传输路径和协议版本。
sip协议中 认证域
SIP协议中的认证域是一个重要的概念，它用于标识SIP消息的来源和目的地。
认证域通常包括用户名、密码和域名等信息，用于验证SIP消息的合法性。
在SIP协议中，认证域通常与SIP消息的To和From头字段相关联。
To头字段表示消息的目的地，而From头字段表示消息的来源。
认证域中的用户名和密码是用于验证SIP消息的合法性的凭据。
当SIP消息被发送到SIP代理或SIP注册服务器时，这些服务器会检查SIP消息中的认证域信息，以验证消息的来源和目的地的合法性。
如果认证域信息不匹配或无效，SIP代理或注册服务器将拒绝接收该消息，并返回一个错误响应。
通过使用认证域，SIP协议可以确保只有合法的用户能够发送和接收SIP消息，从而保护了通信的安全性和可靠性。
SIP协议中的HEADER应用
SIP协议中的HEADER应用SIP（会话初始化协议）是一种用于控制、启动、修改和终止多媒体会话的协议。
在SIP中，会话参与者之间进行通信和交流的方式是通过消息交换。
在SIP消息中，头部（Header）扮演了非常重要的角色，包含了关键信息以及用于控制和路由会话的参数。
在下面的文章中，我们将探讨SIP协议中头部的应用。
1.请求方法头部：SIP中的请求方法用于指示消息的目的和目的地。
请求方法头部包含了SIP消息的类型，例如INVITE（邀请）、ACK（确认）、BYE（结束会话）等，用于控制和路由会话的不同阶段。
2. 响应状态头部：SIP中的响应状态头部包含了响应消息的状态码和原因短语。
状态码用于指示请求的执行结果，例如200 OK表示请求成功，404 Not Found表示请求资源不存在等。
响应状态头部用于在SIP会话中传递执行结果和错误信息。
3.路由头部：SIP中的路由头部用于指示消息的路由路径。
路由头部包含了一系列URI（统一资源标识符）地址，表示消息在会话过程中经过的路由器和代理服务器。
路由头部的作用是确保消息能够在网络中正确地传递和到达目的地。
5.会话描述头部：SIP中的会话描述头部用于指示会话的特性和参数。
会话描述头部包含了一系列SDP（会话描述协议）参数，用于描述会话的音频、视频和其他多媒体参数。
会话描述头部的作用是确保会话能够正确地被初始化和修改。
6.隐私和安全头部：SIP中的隐私和安全头部用于指示消息的隐私和安全要求。
隐私头部包含了一系列指示消息的隐私级别和策略的参数，安全头部包含了一系列指示消息的安全级别和策略的参数。
这两个头部用于确保消息的隐私和安全性。
7.事件通知头部：SIP中的事件通知头部用于指示事件的发生和通知的接收者。
事件通知头部包含了一系列指示事件类型和通知方式的参数。
事件通知头部的作用是确保事件能够正确地发生和被通知。
8.权限和控制头部：SIP中的权限和控制头部用于指示消息的权限和控制要求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SIP消息头域的说明(转)1 general-header类：为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。
不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。
不被认可的头域作为实体头域。
1.1 Call-IDCall-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。
来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。
注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。
对于一个INVITE请求。
主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。
如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。
对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。
一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确认。
使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。
如果需要的话，可以使用在会话描述中的标识来检测此副本。
例如，SDP的“o”域中包含了会话标识和版本号。
REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。
一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。
Call-ID = (“Call-ID” | “i”)”:”local-id”@”hostLocal-id = 1*urici是Call-ID的缩写形式。
“host”应该是一个真正的域名或者是一个全球性的IP地址。
如此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯一的。
建议使用经过加密的随机标识。
Call-ID的值禁止被重用于另一个不同的呼叫。
Call-ID区分大小写。
1.2 From请求和响应必须包含From通用头域，指示请求的初始者。
From域可以包含一个"tag"参数。
服务器将From头域从请求复制到响应。
可选的"display-name"意味着由用户接口提出（执行）。
如果客户身份被隐藏，那么系统必须使用显示名"Anonymous"。
此SIP-URL禁止包含"transport-param"，"maddr-param"，"ttl-param"，"headers"。
接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
即使"display-name"是空的，如果"addr-spec"包含了"，"、"？"、"；"，"name-addr"形式也必须使用。
From =（"From" | "f"）"："（name-addr | addr-spec）*（"；"addr-params）addr-params=tag-paramtag-param="tag="UUIDUUID=1*（hex | "-"）"tag"可以出现在一个请求的From头域中，当共享同一个SIP地址的用户的两个实例使用同一个Call-ID发出邀请时，必须使用此"tag"。
"tag"必须是全球唯一的，并且是一个经过加密的至少32比特的随机数。
一个单个的用户应该在一个Call-ID所标识的整个呼叫中保持同一个tag。
Call-ID、To和From用于标识一个Call leg。
呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。
1.3 ToTo通用头域说明了请求的接收者。
To =（"To" | "t"）"："（name-addr | addr-spec）*（"；"addr-params）请求和响应必须包含To头域，指示请求的预定接收者。
可选的"display-name"意味着由用户接口提出（执行）。
UAS或者重定向服务器将To头域的内容复制到它的响应中，同时如果请求包含了不止一个Via头域，则必须增加"tag"参数。
如果Via头域不止一个，那么表明请求至少经过一个代理服务器的处理。
因为接收者不知道此请求是哪一个代理服务器派生的请求，所以从安全方面考虑，可认为它们都派生了请求。
此SIP-URL禁止包含"transport-param"，"maddr-param"，"ttl-param"，"headers"。
接收到含有以上元素的SIP-URL的服务器在执行下一步处理之前，应将这些元素删除。
"tag"参数作为一种通用机制，用于区分由一个SIP-URL标识的用户的多个实例。
因为代理可以派生请求，所以同一个请求可以到达用户的多个实例（例如：移动和住宅电话）；又由于每一个都可以响应，所以必须有一种方法来区分来自被叫方每一个实例的响应。
这种情况也可由于多点传送（组播）请求而产生。
"tag"参数用于区分UAC的响应。
当请求有可能被一中间件代理派生时，每一个实例都必须在它的响应中包含"tag"参数。
"tag"参数必须可以被UAS、登记器和重定向服务器增加，但禁止被加入到上传的响应中。
"tag"参数可以增加到所有方式的所有已经定义的响应中，也可以加入到来自UAS或者重定向服务器的报告性（1xx）响应。
两个实体间随后所有的事务都必须包含"tag"参数。
当响应与请求相匹配时，如果请求的To域中未包含"tag"参数，那么响应To域中的"tag"参数将忽略。
"tag"允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。
它也允许被叫方的多个实例发送可以区分的请求。
当SIP服务器接收到一个请求，此请求的To域中含有它不能识别的URI时，它应该返回一个400（Bad Request）响应。
即使"display-name"是空的，如果"addr-spec"包含了"，"、"？"、"；"，"name-addr"形式也必须使用。
Call-ID、To和From用于标识一个Call leg。
呼叫和Call-leg的区别在于多个响应对派生请求的呼叫。
"tag"允许代理派生同一个呼叫的未来的请求，而只对几个可能的响应UAS中的一个定位（寻址）。
它也允许被叫方的多个实例发送可以区分的请求。
1.4 ViaVia头域指示请求迄今为止所走的路径。
它防止了请求的循环，同时确保了响应（回答）沿同样的路径返回，这一点可以通过防火墙遍历和其他的异常路径情况提供帮助。
1.5 ContactContact通用头域可出现在INVITE、ACK和REGISTER请求中，1xx、2xx、3xx和485响应中。
通常，它提供了一个URL，用户可以通过此URL来进行进一步的通信。
INVITE和ACK请求：Contact域表明请求从哪个位置发起；这允许主叫方直接向被叫方发送未来的请求，如BYE，而不是通过一系列的代理。
由于所想要的地址可能是代理的地址，所以只Via头域并不够。
INVITE 2xx响应：一个用户代理服务器在发送一个限定的、肯定的响应（2xx）时，可以加入一个Contact响应头域，表明对于未来的请求它可以直接到达的SIP地址，如ACK请求。
Contact头域包含了服务器自己或者代理的地址，例如主机在一个防火墙之后。
如果响应未包含Record-Route头域，此Contact的值将复制到此呼叫的后来的请求的Request-URI中；如果响应包含了Record-Route 头域，Contact域的值将作为最后一项增加到Record-Route域中。
Contact的值不应该通过呼叫被缓冲，因为它可能不能表示一个特殊目的地地址的最想要的位置。
INVITE 1xx响应：一个UAS发送一个临时的响应（1XX）可以插入一个Contact 响应域。
语义同2XX INVITE响应。
注意到CANCEL请求禁止被发送到那个地址（Contact所指示的），但仍跟随初始请求的路径。
REGISTER request：REGISTER请求中的Contact域表明用户的位置。
REGISTER 请求定义了一个通配的Contact域。
“*”，只能用于：0删除一个用户所有的登记。
一个可选的“expires”参数指示登记所想要的期限。
如果Contact未使用此参数，则Contact域的值将使用默认值。
如果这些机制都未采用，SIP URL 的期限为一个小时。
其他的URL没有期限时间。
REGISTER 2xx响应：一个REGISTER响应可以返回可以达到的用户的所有地址。
3xx和485响应：Contact头域指示一个或多个可选的地址。
可以出现在对于INVITE、BYE和OPTIONS方式的响应中。
Contact头域包含的URI给出了新的位置和用户名，或者简单地说明其他的传输参数。
300（Multiple Choise）、301(Moved Permanently)、302(Movec Temporarily)或者485(Ambiguous)响应应该包含一个含有可尝试的新地址的URL的Contact域。
301和302响应可以给出正在尝试的同样的位置和用户名，但指定了其他的传输参数，如一个不同的服务器或者多点地址，或者一个从TCP到UDP，UDP到TCP的SIP事务的改变。
客户将Contact URL中的“user”、“password”、“host”、“port”、“user-param”复制到重定位请求的Request-URL中，同时使用tranport参数中的传输协议，将此请求传到“maddr”和“port”参数所说明的地址处。