CN1677978A - 会话启动协议路由标题的签署和确认 - Google Patents

会话启动协议路由标题的签署和确认 Download PDF

Info

Publication number
CN1677978A
CN1677978A CNA2005100637538A CN200510063753A CN1677978A CN 1677978 A CN1677978 A CN 1677978A CN A2005100637538 A CNA2005100637538 A CN A2005100637538A CN 200510063753 A CN200510063753 A CN 200510063753A CN 1677978 A CN1677978 A CN 1677978A
Authority
CN
China
Prior art keywords
title
signature
sip
route
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2005100637538A
Other languages
English (en)
Other versions
CN1677978B (zh
Inventor
J·T·布赫
苏锦彦
S·纳拉亚南
V·埃德尔曼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CN1677978A publication Critical patent/CN1677978A/zh
Application granted granted Critical
Publication of CN1677978B publication Critical patent/CN1677978B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61H—PHYSICAL THERAPY APPARATUS, e.g. DEVICES FOR LOCATING OR STIMULATING REFLEX POINTS IN THE BODY; ARTIFICIAL RESPIRATION; MASSAGE; BATHING DEVICES FOR SPECIAL THERAPEUTIC OR HYGIENIC PURPOSES OR SPECIFIC PARTS OF THE BODY
    • A61H39/00—Devices for locating or stimulating specific reflex points of the body for physical therapy, e.g. acupuncture
    • A61H39/04—Devices for pressing such points, e.g. Shiatsu or Acupressure
    • C—CHEMISTRY; METALLURGY
    • C04—CEMENTS; CONCRETE; ARTIFICIAL STONE; CERAMICS; REFRACTORIES
    • C04B—LIME, MAGNESIA; SLAG; CEMENTS; COMPOSITIONS THEREOF, e.g. MORTARS, CONCRETE OR LIKE BUILDING MATERIALS; ARTIFICIAL STONE; CERAMICS; REFRACTORIES; TREATMENT OF NATURAL STONE
    • C04B33/00—Clay-wares
    • C04B33/02—Preparing or treating the raw materials individually or as batches
    • C04B33/04—Clay; Kaolin
    • C—CHEMISTRY; METALLURGY
    • C04—CEMENTS; CONCRETE; ARTIFICIAL STONE; CERAMICS; REFRACTORIES
    • C04B—LIME, MAGNESIA; SLAG; CEMENTS; COMPOSITIONS THEREOF, e.g. MORTARS, CONCRETE OR LIKE BUILDING MATERIALS; ARTIFICIAL STONE; CERAMICS; REFRACTORIES; TREATMENT OF NATURAL STONE
    • C04B33/00—Clay-wares
    • C04B33/02—Preparing or treating the raw materials individually or as batches
    • C04B33/13—Compounding ingredients
    • C04B33/132—Waste materials; Refuse; Residues
    • C04B33/1324—Recycled material, e.g. tile dust, stone waste, spent refractory material
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Chemical & Material Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Ceramic Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Dispersion Chemistry (AREA)
  • Materials Engineering (AREA)
  • Structural Engineering (AREA)
  • Organic Chemistry (AREA)
  • Rehabilitation Therapy (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Veterinary Medicine (AREA)
  • Physical Education & Sports Medicine (AREA)
  • Pain & Pain Management (AREA)
  • Epidemiology (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

揭示了用于签署和确认会话启动协议(“SIP”)路由标题的方法、具有计算机可执行指令的计算机可读介质、以及具有存储在其中的数据结构的计算机可读出介质。SIP节点可以接收包括消息标题的SIP请求。可以基于至少一部分消息标题和SIP节点标题条目生成签名。然后可以把签名***到SIP节点标题条目中。

Description

会话启动协议路由标题的签署和确认
技术领域
本申请针对用于通过计算机网络在设备之间传递的方法和计算机可读介质，尤其涉及用于签署和确认会话启动协议(“SIP”)路由标题以认证包含在SIP消息中的路由命令的方法和计算机可读介质。
背景技术
会话启动协议(“SIP”)是用于建立、管理和终止通信会话的因特网信令协议，所述通信会话包括即时消息通信、因特网电话呼叫以及因特网视频会议。通过引用结合于此的因特网工程任务强制征求意见(Internet Engineering Task Force Request for Comments)2543和征求意见3261的每一个中都规定了SIP。SIP会话涉及一个或多个参与者或客户机(一般是呼叫者和被呼叫者)。通过SIP节点(一般为各种服务器)的网络，在每个端点SIP节点(例如，呼叫者和被呼叫者)之间路由SIP消息。
一般有两类SIP消息：从呼叫者(例如，端点SIP节点)发送给被呼叫者的请求，以及从被呼叫者发送给呼叫者以答复请求的响应。在某些情况中，在启动对话会话之后，被呼叫者也可以把请求发送给呼叫者。每个SIP消息，不管是响应还是请求，一般都包括三个部分：起始行、标题和正文。起始行传送消息类型(例如，请求或响应)以及协议版本，而消息正文包括消息内容，并且可以传送起始行中信令信息之外的会话描述信息。SIP标题字段传送消息的属性并修改消息的意义。存储在标题字段中的某些消息属性是如何路由消息以及用文件证明消息实际行进的路由的指令。例如，管理其路由上的请求的每个SIP节点将添加包含标识该SIP节点的信息的“VIA”标题，诸如一个完全合格的域名或因特网协议地址。如此，可以检测路由中的循环，并且响应使用来自请求的VIA标题来确定要行进的路由以返回给呼叫者。然而，消息的特定路径在时间上可能不是固定的，因此，诸如归属服务器(home server)之类的SIP节点可以接收诸如电话呼叫之类的对话的第一请求，但是可能不接收同一对话中的后续请求。为了保留在该对话的“循环”中，SIP节点可以***包含标识其自身的信息的RECORD-ROUTE标题，诸如统一资源指示符(“URI”)或允许其它服务器或端点到达SIP节点的其它地址。然后接收端客户机(对于请求为被呼叫者，对响应为呼叫者)把RECORD-ROUTE标题的完整列表中的一部分拷贝成一组ROUTE标题。ROUTE SET标题包含某些数据，这些数据向SIP节点提供关于在同一对话会话中如何路由任何未来请求的指令。
发明内容
虽然上述SIP标题字段有助于在诸如沿消息的路由的服务器等SIP节点间来回路由消息，但是当根据SIP标准(RFC3261)使用时，这些标题中的许多是不安全的。例如，在服务器处可以用在SIP标题中包括假冒路由信息的多个伪造的SIP消息来引导服务拒绝攻击。可以通过伪造的标题信息来屏蔽假冒消息的真实始发者，可能使之看来正在无知的服务器处始发服务拒绝攻击。此外，伪造的路由标题可以在两个服务器之间创建循环消息。如此，沿假冒消息的伪造“路由”的每个服务器可能浪费宝贵的资源来处理和转发假冒消息，因此，拒绝把这些资源给合法的用户。
本发明的实施例针对用于认证在SIP消息中找到的路由标题的方法和计算机可读出介质。具体地，SIP节点可以接收包括消息标题的SIP请求。基于至少一部分消息标题可以生成签名，并***到SIP节点标题条目。如这里所使用的，SIP节点是指运行在可以作为SIP客户机或服务器操作的计算设备上的SIP应用程序。
例如，可以基于在所接收请求标题中的至少一部分VIA标题生成第一签名，并且***到SIP节点的VIA标题中。当生成对SIP请求的响应时，根据SIP标准处理，在响应标题中返回SIP节点的VIA标题。当SIP节点接收响应时，SIP节点可以验证响应的SIP节点VIA标题中的第一签名，以认证响应行进的实际路径的完整性。
此外或另一方面，可以基于消息标题的至少一部分RECORD-ROUTE(记录-路由)标题和CONTACT(联系人)标题生成第二签名。可以把第二签名***到SIP节点的RECORD-ROUTE标题中。然后被呼叫者***可以保存附带有第二签名的这个RECORD-ROUTE标题的一部分作为ROUTE标题来使用，用于在启动会话之后路由和验证被呼叫者***对呼叫者***生成的请求。
此外或另一方面，可以基于消息标题的至少一部分RECORD-ROUTE标题生成第三签名。可以把第三签名***到SIP节点的RECORD-ROUTE标题中。当被呼叫者响应SIP请求时，在响应标题中返回SIP节点的RECORD-ROUTE标题。为了验证关于如何路由未来请求的指令的完整性，当SIP节点接收到响应时，可以由SIP节点来验证第三签名。例如，接收响应的SIP节点可以识别包含从请求标题返回的数据的RECORD-ROUTE标题，并且从返回的标题中提取签名。SIP节点可以使用与生成第三签名的过程相同的过程来生成验证签名，例如，基于响应标题中的至少一部分标题生成签名。然后SIP节点可以比较验证签名和所提取的签名。如果两个签名是匹配的，则可以正常地处理消息。
可以生成第四签名并***到SIP响应标题中。例如，接收响应的SIP节点可以基于响应标题的至少一部分RECORD-ROUTE标题以及响应标题的CONTACT标题生成第四签名。第四签名与上述第二签名相似，然而，由于第四签名是基于响应中的CONTACT标题生成的，所以正如请求的情况一样，CONTACT识别被呼叫者而不是呼叫者。然后可以把第四签名***到SIP节点的RECORD-ROUTE标题中。当呼叫者***接收到响应时，它就可以保存附带有签名的一部分RECORD-ROUTE标题作为ROUTE SET标题，用于在后续请求中路由指令的使用和验证。
在某些情况中，可以通过至少具有第一服务器和第二服务器(可以互换地使用它们来处理同一对话中的消息)的服务器池来提供处理SIP消息的SIP节点。然而，当交换消息时，对话中的请求可以包含由第一服务器生成，但是可以发送到第二服务器用于处理的签名。这要求第二服务器具有用于验证请求中的签名的会话密钥。为了安全地传送用于生成请求中的签名的会话密钥，生成签名的第一服务器可以把经加密的和经签署的会话密钥附到消息的标题中。例如，可以把会话密钥***到包括由该密钥生成的签名的同一标题中。为了保护来自其它SIP节点的会话密钥，第一服务器可以用服务器池可访问的公钥对会话密钥进行加密。然后第一服务器可以用服务器池可访问的私钥来签署经加密的密钥。接收请求的第二服务器可以验证经加密密钥上的签名，然后对会话密钥进行解密。然后第二服务器可以基于至少一部分消息标题使用经解密的会话密钥来验证签名。可以理解，可以使用任何合适的安全处理来保护会话密钥，包括例如，包括公钥/私钥对的非对称密钥技术。
附图说明
在参考下列详细描述的说明书和附图而较好地理解本发明时，可以更容易地理解本发明的上述各方面和伴随的许多优点。
图1是根据本发明的一个实施例，两个会话启动协议(“SIP”)客户机之间的INVITE(邀请)请求和响应路由的示意图；
图2是根据图1的示例INVITE请求；
图3是根据图1的示例VIA标题组；
图4是根据图1的示例RECORD-ROUTE标题组；
图5是对于图2的INVITE请求的示例响应；
图6是图1的被呼叫者SIP节点生成的示例请求；
图7是图1的被呼叫者SIP节点生成的示例请求；
图8是根据本发明一个实施例的示例SIP服务器的图示；
图9是根据本发明一个实施例，来自密钥信息数据库的示例表格的图示；
图10是根据本发明一个实施例的流程图，描述如何生成VIA签名；
图11是根据本发明一个实施例的流程图，描述如何验证VIA标题；
图12是根据本发明一个实施例的流程图，描述如何生成ROUTESET签名和RECORD-ROUTE签名；
图13是根据本发明一个实施例的流程图，描述如何验证RECORD-ROUTE签名；以及
图14是根据本发明一个实施例的流程图，描述如何把会话密钥导入服务器池中的一个服务器。
具体实施方式
服务拒绝攻击一般是攻击者启动的计算机化的袭击，以使诸如Web服务器或文件服务器之类的网络服务过载或停止。例如，攻击可以导致服务器变得忙于试图对假冒消息作出响应，以致于忽视合法的连接请求。另一方面，可能破坏合法消息的路由，导致SIP节点不正确地转发响应。在某些情况中，用于在计算机网络上发送消息的通信协议可能是一个重要的攻击点。例如，如上所述，可以用伪造的VIA标题、ROUTE标题和/或RECORD-ROUTE标题来发送假冒的SIP消息，因此把消息引导到受害的SIP节点和/或屏蔽攻击者的身份和来源。为了减少服务拒绝攻击，可以使确认包含在SIP标题中的路由指令和实际路由路径，以保证它们的完整性。
图1示出示例会话启动操作，其中SIP客户机102的用户100(例如，Alice)希望通过通信网络启动与另一个用户400(Bob)的通信会话，通信网络可包括因特网、内联网、广域网、局域网、虚拟专用网络等。为此，驻留在计算机***104中的SIP客户机102发送将Bob标识为预期接收者的INVITE请求消息500。在SIP标准下的通信的情况中，发送INVITE消息500以启动会话的SIP客户机102被称为“呼叫者”，而Bob的计算机***404上的SIP客户机402被称为“被呼叫者”。如在SIP中所定义的，SIP客户机102也被称为“用户代理客户机”(“UAC”)，因为它创建一个新请求，而SIP客户机402也被称为“用户代理服务器”，因为它生成对于SIP请求500的响应600。
如在图1中所示，把来自Alice的INVITE消息500发送到呼叫者SIP客户机的域中的出站(outbound)服务器200。此后，在INVITE消息到达Bob的域中的SIP代理服务器300之前，可以令其通过包含在信令操作中的多个SIP节点。为了简化起见，在图1中仅示出五个SIP节点，然而，应该理解，任何链路都可以包括其它服务器、网关、网桥等。SIP代理300把INVITE消息转发到Bob的计算机的SIP客户机402(被呼叫者)。Bob的计算机可以自动地，或根据Bob的授权，发送对INVITE的响应600，诸如表示成功发送的“200(OK)”消息。
如上所述，每个SIP消息一般包括起始行、包含关于消息的属性和路由的信息的标题、以及消息的正文。例如，图2示出Alice的SIP客户机102发送并由SIP节点200接收的INVITE请求500的表示。示例INVITE 500包括起始行502、多个标题504以及正文506。起始行502标识消息类型(这里是INVITE)、一般是被呼叫者的SIP地址的请求URI、以及SIP版本。标题504是SIP标准下可接受的字段。VIA标题508包含表示协议和前一中继段地址的信息。FROM标题510包含表示始发请求的用户(呼叫者)-这里是Alice-的信息。TO标题512包含表示由呼叫者指定的被呼叫者的信息。Call-ID(呼叫ID)标题514包含表示正在启动的会话的全局唯一标识符的信息。CSEq标题516包含表示一标识符的信息，该标识符在作为同一事务的一部分用相同的FROM、TO和Call-ID标题发送的多个消息之间进行区分。CONTACT标题518包含表示后续请求的目的地的信息，允许未来消息路由到不在RECORD-ROUTE标题中列出的旁路SIP节点(下面进一步讨论)。VIA标题、TO标题、FROM标题、CONTACT标题、RECORD-ROUTE标题以及ROUTE标题的每一个都包含表示网络中的路由位置的数据，诸如URI、因特网协议地址等。例如，包含表示路由位置的数据的RECORD-ROUTE标题可以包括由标题参数跟随着的、包括在“<>”括号中的URI部分。在“<>”括号中的URI部分可以包括URI和URI参数。一般而言，至少一个空白行标记标题504的结束和正文部分506的开始。像INVITE请求那样，图5中示出的示例响应600包括起始行602、标题部分604以及正文606。
在SIP标准下，当INVITE 500在网络上行进时，对它进行管理的每个SIP节点把VIA标题添加到INVITE标题504中。如此，在把对于请求的答复返回呼叫者时，被呼叫者可以使用经累加的VIA标题来引导响应的路由。如果SIP节点愿意继续管理呼叫者和被呼叫者之间该特定对话的消息，则SIP节点可以把RECORD-ROUTE标题***到INVITE标题504中。如此，为了引导可以由被呼叫者生成的未来请求的路由，接收被呼叫者可以保存对话启动请求的RECORD-ROUTE标题和CONTACT标题的经累加的URI部分，作为与所列出的次序相同的标题的ROUTE SET(路由组)。相似地，为了提供由呼叫者生成的未来请求的路由指令，呼叫者可以按与ROUTE SET标题相反的次序来保存在对话启动请求的响应中的RECORD-ROUTE标题和CONTACT标题的经累加的URI部分。
考虑到通过处理SIP节点的标题添加，图1示出了路由INVITE请求和响应的具体例子。为了简化起见，未包括无关系的标题和其它消息信息。要理解，所示的SIP节点的功能和数量是示例性的，对于特定目的和/或网络体系结构可以修改消息路由和验证。
如在图1中所示，SIP节点200可以是归属服务器，并可接收来自SIP客户机102的INVITE请求。接收消息的SIP节点200把VIA标题***INVITE请求的标题504中。作为归属服务器的SIP节点200可能希望管理来往于SIP客户机102的任何SIP消息。因此，SIP节点200可以在它把消息转发到下一SIP节点之前，把RECORD-ROUTE标题***到INVITE消息中。在图1示出的实施例中，下一SIP节点250是呼叫者SIP客户机102的边缘服务器。SIP节点250在把它自己的VIA标题和RECORD-ROUTE标题***到消息的标题504中之后转发INVITE消息。最后，INVITE消息被路由到SIP节点300，在图1所示的实施例中，该节点是被呼叫者SIP客户机402的边缘代理服务器。边缘代理服务器可以是被设计成在网络边缘处运行的一种代理服务器，例如，使本地网络与因特网分开。像边缘服务器250一样，边缘代理服务器300在把消息转发到SIP客户机402之前，把VIA标题和RECORD-ROUTE标题***到INVITE标题504中。在图3中示出***到INVITE请求500中的SIP节点200的VIA标题530、SIP节点250的VIA标题532以及SIP节点300的VIA标题534的例子。在图4中示出***到INVITE请求500中的SIP节点200的RECORD-ROUTE标题520、SIP节点250的RECORD-ROUTE标题522以及SIP节点300的RECORD-ROUTE标题524的例子。
Bob的SIP节点402可以接受INVITE，并且发送OK响应600作为对INVITE请求的答复。图5示出从SIP节点402到服务器300的示例响应600。在SIP标准下，从所接收的请求中拷贝或返回响应600的许多标题字段或至少一部分标题字段。这些返回的标题可以包括，例如在SIP标准下确定的，每个VIA标题、FROM标题、TO标题、每个RECORD-ROUTE标题、Call-ID标题、以及CSeq标题。如此，图5中示出的响应600说明返回的标题。特别地，响应600中的VIA标题608、630、632、634与被呼叫者SIP节点402接收的INVITE 500中的VIA标题508、530、532、534相同。相似地，RECORD-ROUTE标题620、622、624与SIP节点生成并由被呼叫者SIP节点402接收的INVITE 500中的RECORD-ROUTE标题520、522、524相同。然后如由VIA标题608、630、634引导的通过网络把响应消息路由到呼叫者SIP节点102。
处理响应的SIP节点，如SIP节点300、250、200，可以通过确认包含在VIA标题中的路由指令来确认响应采用的实际路由的完整性。在一个实施例中，SIP节点可以把诸如VIA标题508、530、532等路由信息存储在数据库中，供以后访问和使用，以验证响应VIA标题608、630、632。另一方面，为了减少SIP节点上的存储器和访问负载，SIP节点可以基于至少一个标题中的至少一部分来生成签名，所述至少一个标题包含表示消息的路由中的网络路由位置的数据。例如，签名可以基于包含网络路由位置的所有标题，或可以只基于该标题的一部分，诸如URI、URI参数、对等完全合格域名(“FQDN”)等。除了至少一个标题之外，签名还可以基于其它信息，包括将在下一个中继段上通过其发送消息的连接的连接标识符、返回标题、TO标题、FROM标题、CONTACT标题、CALL-ID标题、CSeq标题以及Branch-ID。然后可以把基于请求的至少一个标题中的至少一部分的签名传送给响应，并且当SIP节点处理响应时被确认。是否应该把标题部分包括在签名中取决于在SIP代理验证标题部分之前它是否会改变。例如，包含在为了签名验证而被访问之前可能被移除或改变的信息的标题部分不应包括在签名中。要理解，SIP消息的路由中的任何或所有的SIP节点可以按包括这里讨论的任何合适的方式来生成和存储验证签名。还可以理解，可以根据网络和SIP节点的安全性考虑和标准在适当时确认SIP消息的标题，包括维护可信链路的列表、符合签署的全局政策以及到/自特定域的签名/确认消息等。例如，为了实现可信链路列表，每个服务器可以维护它认为可信的链路的列表。因此，去往/来自可信列表的任何消息可能不被签署/确认。因此，服务器在生成/确认签名之前可以核查可信链路列表，以保证该链路是不可信的，例如，没有列在可信列表中。
在一个例子中，可以使用可访问的会话密钥基于请求消息中的至少一个VIA标题来生成签名。为了确认消息行进的路由，SIP节点可以基于所有VIA标题或至少SIP节点接收到的所有VIA标题来生成VIA签名。例如，对于图1和2中示出的INVITE消息500，SIP节点200可以通过使用SIP节点200可访问的会话密钥，基于包含指定SIP客户机102(Alice)的信息的VIA标题508来提供VIA签名。可以把所生成的VIA签名存储在消息中，传送给响应消息，然后在通过SIP节点200的消息返回行程上确认。相似地，SIP节点300可以基于所接收的VIA标题生成VIA签名，以在以后当在SIP节点300处接收到响应时确认它。为了签署VIA标题，SIP节点300可以使用可访问的会话密钥基于Alice的VIA标题508、SIP节点200的VIA标题530以及SIP节点250的VIA标题532生成VIA签名。
要理解，可以签署VIA标题和其它标题信息的任何合适的组合，以认证响应标题604中的路由指令。例如，除了一部分TO标题、FROM标题或可以从请求标题504返回到响应标题604的任何其它标题之外，VIA签名还可以基于一部分VIA标题。此外，***到请求标题504中的VIA签名550可以是表示所生成的数字签名的任何数据或信号。例如，所存储的签名550可以是所生成的签名二进制大对象(blob)的预定数量的有效位，或可以是整个数字签名。
为了保证在处理INVITE请求期间生成的VIA签名存在，用于SIP节点处响应中的验证，可以把所生成的VIA签名***到INVITE请求的返回标题中。例如，可以在标准路由位置信息之后***签名作为URI参数或标题参数。因此，当客户机SIP节点402基于SIP请求的返回标题生成响应标题604时，所生成的签名从请求自动传送到响应。因此，接收响应的SIP节点可以确认传送到响应标题的签名。要理解，基于现有协议由客户机SIP节点返回的任何返回标题或自定义标题都可适合于存储签名，用于由SIP节点确认。
如在图3中所示，可以把VIA签名***到生成签名的SIP节点的VIA标题中。例如，SIP节点300可以基于请求500中接收的VIA标题508、530、532生成VIA签名550。SIP节点300可以把VIA签名550***到SIP节点300的VIA标题534中。如上所述，在响应标题604中返回请求标题中的VIA标题。因此，当SIP节点402形成响应600时，它可以把包含在VIA标题534中的信息拷贝到SIP节点300的VIA标题634中(图1)。在标准的SIP处理下，当返回VIA标题时，拷贝标准的VIA信息，以及作为标题参数而附加的任何信息，诸如VIA签名550。
为了确认所接收的VIA签名650，SIP节点300(图1)可以剥去和保存图5中示出的所接收的VIA签名650。SIP节点300可以使用与用于生成***到请求中的VIA签名550的过程相同的过程来生成确认VIA签名。根据上述VIA签名550的生成，SIP节点300可以识别所接收响应600中的VIA标题，并且基于在SIP节点300的VIA标题534下列出的所有VIA标题生成确认VIA签名。如此，确认VIA签名可以基于当在请求消息500中生成VIA签名550时SIP节点300已知的那些VIA标题。因此，SIP节点300的确认VIA签名可以基于SIP节点250的VIA标题632、SIP节点200的VIA标题630以及呼叫者SIP节点102的VIA标题608。SIP节点300可以将确认VIA签名和所接收的VIA签名650进行比较。
如果签名是匹配的，则SIP节点300可以继续进行SIP标准下的正常处理，并且把响应转发到在响应标题604的VIA标题中指示的下一SIP节点。如果签名是不匹配的，则SIP节点300可以从它的处理栈中丢弃响应600，和/或把出错消息发送给SIP节点监视服务(未示出)或协议支持的任何合适的监视代理。为了测量签名兼容性和/或攻击检测的消息处理性能，对于每个被拒绝的消息，SIP节点300都递增一签名失败性能计数器。签名失败性能计数器可以是表示SIP节点验证标题签名失败的任何数据或信号。例如，签名失败性能计数器可以对一个时间段内的失败的签名确认的数量进行计数。然后，签名失败性能计数器可以与该时间段内的失败的签名确认的预定阈值(诸如在约1秒的消息处理时间中，大约6个失败的签名确认、大约10个失败的签名确认、或大约25个失败的签名确认)进行比较。当性能计数器超过阈值时，SIP节点可以通知或警告***管理人员(包括通过电子邮件和/或寻呼机)，和/或通知或警告可以基于性能计数器启动预定行动的基于计算机的***管理员，包括例如，包括撤消路由失败消息的网络连接、锁住网络和/或清洗消息队列。
在某些情况中，可以在路由上的每一步处，例如，在返回行程上处理请求和/或响应的每个SIP节点处，生成确认和/或签名。然而，为了减少SIP节点服务器上的计算负担，可以只在需要消息时才确认它。
例如，如果请求只包含一个VIA标题，例如，请求500中Alice的SIP节点102的VIA标题508，则在节点处的请求中不生成签名。更具体地，Alice的SIP节点102可能不需要验证响应600中的任何路由指令，因为该响应将由SIP节点102消耗，例如，它将不进一步转发。因此，当请求只包含一个VIA标题时，不生成VIA签名，并且因此，当接收到只包含一个VIA标题的请求时(例如，接收SIP节点的VIA标题时)不需要验证VIA签名。
在另一个例子中，如果通过不可信连接接收消息，则服务拒绝攻击更为可能。为了提高消息的安全性，当通过不可信连接接收时，可以确认消息。例如，不可信连接可以包括任何服务器类型的任何客户机连接，因为可以用其它方法来认证从其它服务器接收的消息。不可信连接还可以包括边缘代理服务器的外部服务器连接，尤其可以包括所有外部服务器连接。
如在图1中所示，SIP节点200和SIP节点250之间的连接210、212可以是可信连接，因为可以认为这些连接是归属服务器和边缘服务器之间的内部链路。由于服务器可以有认证服务器之间的消息话务的其它方法，所以SIP节点250和SIP节点300之间的链路260、262可以是可信连接；然而，在某些情况中可以认为这些连接是不可信连接，特别是如果认为服务器认证的其它方法不足够的时候。客户机节点402和SIP节点300之间的链路310、312可以是不可信连接，因为SIP消息被发送到客户机SIP节点/从客户机SIP节点发送。因此，可以在SIP节点处确认通过不可信连接(诸如链路312)接收的任何消息，以验证消息完整性和/或真实性。
如果不确认通过可信链路接收的响应，则当通过可信链路把请求转发到下一SIP节点时不需要生成VIA签名。例如，SIP节点200和250可以不通过不可信连接接收响应600，因此，在INVITE请求的标题504中，这些节点可以不生成或存储VIA签名，因为它们没有确认响应的路由的要求。因此，在生成VIA签名之前，SIP节点可以判定是否需要对应的响应的确认。如果不需要验证响应，例如下一个链路是可信连接，则不需要生成VIA签名，并且可以继续进行SIP请求的正常处理。然而，如果通过不可信连接在SIP节点处接收对应的响应，则可以如上所述地生成VIA签名。相似地，在接收响应之后，SIP节点可以首先判定是否从不可信连接接收到响应。如果是这样的，则确认VIA签名(如果存在的话)。例如，SIP节点300可以判定响应600是否通过可信连接接收的。如在图1中所示，链路312是不可信连接。结果，SIP节点300就可以识别响应的标题604中的SIP节点300的VIA标题634。SIP节点300可以判定在经识别的VIA标题634中是否存在签名。如果VIA签名不存在，则如果协议允许的话，SIP节点300可以发送出错消息，可以从它的处理栈中丢弃消息，可以递增签名失败性能计数器和/或采取任何其它适当的行动。如果存在VIA签名650，如在图5中所示，则SIP节点300可以如上所述地验证签名。
如上所述，签署VIA标题有助于响应标题604中的路由指令的确认。然而，SIP节点可以另外或可选地要求确认由被呼叫者生成的请求的路由指令。因此，SIP节点可以基于对话启动请求中的至少一个RECORD-ROUTE标题的至少一部分生成签名，然后在来自被呼叫者的后续请求中确认该签名，以保证对话内请求中的路由指令的完整性。
为了保证被呼叫者请求行进的路由的完整性，SIP节点可以基于包含在请求的接收标题字段中的RECORD-ROUTE标题和CONTACT标题的URI部分来生成被呼叫者ROUTE SET签名。如果存在一个以上CONTACT标题，则被呼叫者ROUTE SET签名可以基于RECORD-ROUTE标题中所选择的URI部分以及第一列出CONTACT标题的URI部分。更具体地，对于图1、2和4中示出的INVITE消息500，SIP节点300可以基于SIP节点250的RECORD-ROUTE标题522的URI部分、SIP节点200的RECORD-ROUTE标题520的URI部分、以及呼叫者Alice的CONTACT标题518的URI部分提供被呼叫者ROUTE SET签名。可以把所生成的被呼叫者ROUTE SET签名存储在消息中，并且传送到被呼叫者SIP节点402，以在由属于同一对话的被呼叫者SIP节点402生成的任何请求中进行存储和使用。要理解，可以签署RECORD-ROUTE标题和其它标题信息的任何合适的组合，以认证被呼叫者SIP节点402生成的任何后续请求的路由指令。***到请求标题504中的被呼叫者ROUTE SET签名可以是表示所生成的签名的任何数据或信号，所生成的签名包括签名二进制大对象的预定数量的有效位和整个数字签名。
为了保证存在请求处理期间生成的被呼叫者ROUTE SET签名以在呼叫者SIP节点402生成的后续请求中用于验证，可以把所生成的被呼叫者ROUTE SET签名***到请求的返回标题中。因此，当客户机SIP节点402基于SIP对话启动请求生成新请求时，自动传送所生成的签名。因此，接收请求的SIP节点可以确认传送给请求标题的签名。要理解，可以由客户机SIP节点基于现有协议返回的任何返回的标题部分或自定义标题都适合于存储被呼叫者ROUTE SET签名，用于由SIP节点确认。
如在图2和4中所示，可以把被呼叫者ROUTE SET签名作为URI参数***到生成签名的SIP节点的RECORD-ROUTE标题中。例如，SIP节点300可以基于请求500中的RECORD-ROUTE标题522、520和CONTACT标题518的URI部分来生成被呼叫者ROUTE SET签名560。SIP节点300可以把被呼叫者ROUTE SET签名560***到SIP节点300的RECORD-ROUTE标题524中作为URI参数。如上所述，由被呼叫者SIP节点在ROUTE标题中存储和返回来自呼叫者的对话启动请求的RECORD-ROUTE标题he CONTACT标题的URI部分，以提供在对话中由被呼叫者生成的任何未来请求的路由指令。因此，如在图6中所示，当SIP节点402形成一个请求时，它可以在标准SIP处理下把RECORD-ROUTE标题524的URI部分拷贝到SIP节点300的ROUTE标题724中。当返回RECORD-ROUTE标题的URI部分时，拷贝标准路由信息以及包括被呼叫者ROUTE SET签名560的任何URI参数。
为了确认图6中所接收的被呼叫者ROUTE SET签名760，SIP节点300可以剥去和保存所接收的被呼叫者ROUTE SET签名760。SIP节点300可以使用与生成***到对话启动请求(这里是INVITE)中的被呼叫者ROUTE SET签名560的过程相同的过程来生成确认ROUTE SET签名。根据上述被呼叫者ROUTE SET签名560的生成，SIP节点300可以识别在所接收的请求700中的RECORD-ROUTE标题，并且基于除了接收SIP节点的ROUTE标题之外的、存在于请求中的所有ROUTE标题来生成确认ROUTE SET签名。如此，确认ROUTE SET签名可以基于当在请求消息500中生成ROUTE SET签名560时SIP 300已知的那些RECORD-ROUTE标题和CONTACT标题。例如，在图1的设置中，SIP节点300的确认ROUTE SET签名可以基于SIP节点250的ROUTE标题722、SIP节点200的ROUTE标题720、以及基于识别呼叫者SIP节点102的CONTACT标题的ROUTE标题718。SIP节点300可以将确认ROUTE SET签名与所接收的被呼叫者ROUTE SET签名760进行比较。如果签名不匹配，则如果协议允许的话，SIP节点300可以发送出错消息，从它的处理栈中移除请求700，递增签名失败性能计数器，和/或采取任何其它适当的行动。如果签名是匹配的，则SIP节点300可以在SIP标准下继续进行正常的处理，并且把请求转发给在请求标题704的ROUTE标题中指示的下一SIP节点。
在某些情况中，可以在路由上的每一步处，例如，在处理请求的每个SIP节点处，生成和/或确认被呼叫者ROUTE SET签名。然而，为了减少SIP节点服务器上的计算负担，可以只在需要时才确认请求。
例如，如果请求不包含任何RECORD-ROUTE标题，例如，甚至连当前处理SIP节点也不添加RECORD-ROUTE标题，则可以不生成被呼叫者ROUTE SET签名。更特别地，如果处理请求的SIP节点没有请求保留“在循环中”以进一步在被呼叫者和呼叫者之间通信，则SIP节点可以不要求验证未来接收的消息中的路由指令。
在又一个例子中，如果请求包含RECORD-ROUTE标题但是一个CONTACT标题也没有，则SIP节点可能不要求确认返回这些RECORD-ROUTE标题的任何响应或请求。这会在包括某些类型的ACK(确认)和CANCEL SIP(清除SIP)消息的某些情况中发生。更特别地，如果所接收请求包括至少一个RECORD-ROUTE标题和零个CONTACT标题，则可能不生成被呼叫者ROUTE SET签名而可以继续进行正常处理。
在另外的例子中，由于来自不可信链路的请求更有可能是服务拒绝攻击的来源，因此当通过不可信连接接收时，可以确认消息。如果不确认经过不可信链路接收的被呼叫者的请求，则当把来自呼叫者的对话启动请求经过可信链路转发到下一个SIP节点时，不需要生成被呼叫者ROUTE SET签名560。例如，如在图1中所示，SIP节点200将经过可信连接接收请求700，或换言之，SIP节点将不经过不可信连接接收请求700。因此，这个节点不会生成被呼叫者ROUTE SET签名或把它***到INVITE请求的标题504中，因为它可能对于使来自被呼叫者的任何请求的确认没有要求。因此，在生成被呼叫者ROUTE SET签名之前，SIP节点可以判定是否需要确认任何被呼叫者请求。如果不要验证被呼叫者请求，例如，将通过可信连接接收当前请求，则不需要生成被呼叫者ROUTESET签名，并且可以继续进行SIP节点的正常处理。然而，如果将经过不可信连接在SIP节点处接收被呼叫者请求，则可以如上所述地生成被呼叫者ROUTE SET签名。相似地，在被呼叫者ROUTE SET签名的验证期间，处理SIP节点可以首先判定从被呼叫者接收到的请求是否经过不可信连接。如果是的，则可以确认被呼叫者ROUTE SET签名(如果存在的话)。例如，SIP节点300可以判定是否经过不可信连接接收请求700。如在图1中所示，链路312是不可信连接。结果，SIP节点300就可以识别图6中示出的请求700的标题704中的SIP节点300的ROUTE标题724。SIP节点300可以判定在所识别的ROUTE标题724中是否存在签名，如果存在，就验证该签名。
SIP节点另外或可选地还要求确认在对话启动请求之后由被呼叫者生成的对话内请求的路由指令。因此，SIP节点可以基于对于对话启动请求的响应的至少一个RECORD-ROUTE标题的至少一部分生成签名，并且然后在来自呼叫者的后一请求中确认该签名，以保证请求的路由指令的完整性。
为了保证呼叫者请求行进的路由的完整性，SIP节点可以基于包含在所接收响应的标题字段中的RECORD-ROUTE标题和CONTACT标题的URI部分生成呼叫者ROUTE SET签名。如果存在一个以上CONTACT标题，则呼叫者ROUTE SET签名可以基于RECORD-ROUTE标题的所选择的URI部分和第一列出CONTACT标题的URI部分。更特别地，对于图1和5中示出的响应消息600，SIP节点200可以基于SIP节点250的RECORD-ROUTE标题622的URI部分、SIP节点300的RECORD-ROUTE标题624的URI部分、以及被呼叫者Bob的CONTACT标题618的URI部分提供呼叫者ROUTE SET签名。可以把所生成的呼叫者ROUTE SET签名存储在消息中，并且传送到呼叫者SIP节点102，以在属于同一对话的呼叫者SIP节点102生成的任何请求中存储和使用。要理解，可以签署RECORD-ROUTE标题和其它标题信息的任何合适的组合，以认证呼叫者SIP节点102生成的任何后续请求的路由指令。***到响应标题604中的呼叫者ROUTE SET签名可以是表示所生成的数字签名的任何数据或信号，所生成的数字签名包括签名二进制大对象的预定数量的有效位和整个数字签名。
为了保证在响应处理期间生成的呼叫者ROUTE SET签名存在，以在呼叫者SIP节点102生成的后续响应中用于验证，可以把所生成的呼叫者ROUTE SET签名***到响应的返回标题中作为URI参数。因此，当客户机SIP节点102基于来自SIP响应的返回标题生成新请求时，自动传送所生成的签名。因此，接收请求的SIP节点可以确认传送给请求标题的签名。要理解，由客户机SIP节点基于现有协议返回的任何返回标题部分或自定义标题都适合于存储呼叫者ROUTE SET签名，用于由SIP节点确认。
如在图5中所示，可以把呼叫者ROUTE SET签名***到生成签名的SIP节点的RECORD-ROUTE标题中。例如，SIP节点200可以基于响应600中的RECORD-ROUTE标题622、624和CONTACT标题618的URI部分生成呼叫者ROUTE SET签名660。SIP节点200可以把呼叫者ROUTE SET签名660***到SIP节点200的RECORD-ROUTE标题620中。如上所述，由呼叫者SIP节点在ROUTE标题中存储和返回对于对话启动请求的响应的RECORD-ROUTE标题和CONTACT标题的URI部分，以提供在对话中的呼叫者生成的任何未来请求的路由指令。因此，如在图7的示例请求800中所示，当SIP节点102形成该对话中的后续请求时，它可以在标准的SIP处理下把RECORD-ROUTE标题620的URI部分拷贝到SIP节点200的RECORD-ROUTE标题820中。当返回RECORD-ROUTE标题的URI部分时，拷贝标准的路由信息以及包括呼叫者ROUTE SET签名660的任何URI参数。
为了确认图7的所接收的呼叫者ROUTE SET签名860，SIP节点200(图1)可以剥去和保存图7中示出的所接收的呼叫者ROUTE SET签名860。SIP节点200可以使用与生成***到对于对话创建请求的响应中的呼叫者ROUTE SET签名660的过程相同的过程来生成确认ROUTE SET签名。根据上述呼叫者ROUTE SET签名660的生成，SIP节点200可以识别在所接收请求800中的RECORD-ROUTE标题，并且基于除了接收SIP节点的ROUTE标题之外在请求中存在的所有ROUTE标题，来生成确认ROUTE SET签名。如此，确认ROUTE SET签名可以基于当在响应消息600中生成呼叫者ROUTE SET签名660时SIP节点200已知的那些RECORD-ROUTE标题和CONTACT标题。因此，SIP节点200的确认ROUTE SET签名可以基于SIP节点250的ROUTE标题822、SIP节点300的ROUTE标题824以及根据识别被呼叫者SIP节点402的CONTACT标题的ROUTE标题818。SIP节点200可以将确认ROUTESET签名和所接收的呼叫者ROUTE SET签名860进行比较。如果签名不匹配，则如果协议支持的话，SIP节点200可以发送出错消息，从它的处理栈中移除请求800，递增签名失败性能计数器，和/或采取任何其它适当的行动。如果签名是匹配的，则SIP节点200可以在SIP标准下继续进行正常的处理，并且把请求转发给在请求标题804的ROUTE标题中指示的下一SIP节点。
在某些情况中，可以在路由上的每一步处，例如，在处理响应和/或请求的每个SIP节点处，生成和/或确认呼叫者ROUTE SET签名。然而，如上相对于***请求中的VIA签名和呼叫者ROUTE SET签名所述，通过只在需要时才要求请求中的呼叫者ROUTE SET签名确认而减少SIP节点服务器上的计算负担。
例如，如果对于请求的响应不包含任何RECORD-ROUTE标题，例如，甚至连当前处理SIP节点也不添加RECORD-ROUTE标题，则可以不生成呼叫者ROUTE SET签名。更特别地，如果处理响应的SIP节点没有请求保留“在循环中”以进一步在呼叫者和被呼叫者之间通信，则该SIP节点可以不要求验证未来消息中的路由指令。
在又一个例子中，如果响应包含RECORD-ROUTE标题但是一个CONTACT标题也没有，则SIP节点可能不要求确认返回这些RECORD-ROUTE标题的任何响应或请求。更特别地，如果所接收的响应包括至少一个RECORD-ROUTE标题和零个CONTACT标题，则可能不生成呼叫者ROUTE SET签名而可以继续进行正常处理。
在另外的例子中，当只经过不可信连接接收呼叫者请求的ROUTESET标题时，可以确认呼叫者请求的ROUTE SET标题。如果不确认经过可信链路接收的请求，则当经过可信链路把响应转发到下一个SIP节点时，不需要生成呼叫者呼叫者ROUTE SET签名660。相似地，在接收来自呼叫者的请求之后，如果经过可信连接接收，则不需要确认ROUTESET签名。
如上所述，在对话启动请求和它的对应响应中包括RECORD-ROUTE标题，以生成用于路由后续请求的被呼叫者和呼叫者ROUTE SET标题。因此，在某些情况中，SIP节点可以响应于对话启动请求确认RECORD-ROUTE标题，以保证这些RECORD-ROUTE标题的完整性。例如，连接节点可以篡改请求中的RECORD-ROUTE标题，因此，后续SIP节点可能在欺骗性的RECORD-ROUTE标题上签署，从而导致ROUTE标题具有有效的ROUTE SET签名，但是基于欺骗性的路由信息。因此，SIP节点可以基于请求的至少一个RECORD-ROUTE标题的至少一部分来生成一个签名，然后在来自被呼叫者的响应中确认该签名，以保证消息的RECORD-ROUTE标题的完整性。
为了保证RECORD-ROUTE标题组的完整性，SIP节点可以基于包含在所接收请求的标题字段中的RECORD-ROUTE标题的URI部分生成RECORD-ROUTE签名。更具体地，对于图1、2和4中示出的INVITE消息500，SIP节点300可以基于SIP节点250的RECORD-ROUTE标题522的URI部分和SIP节点200的RECORD-ROUTE标题520的URI部分提供RECORD-ROUTE签名570。与上述被呼叫者ROUTE SET签名相反，RECORD-ROUTE签名570不包括CONTACT标题，因为在SIP标准下，被呼叫者不在响应中返回CONTACT标题。可以把所生成的RECORD-ROUTE签名570存储在消息中，并且传送到响应消息，并且当通过SIP节点处理响应时确认。要理解，可以签署RECORD-ROUTE标题和其它标题信息的任何合适的组合，以认证被呼叫者SIP节点402生成的响应中的路由指令。***到请求标题504中的RECORD-ROUTE签名570可以是表示所生成的数字签名的任何数据或信号，所生成的数字签名包括签名二进制大对象的预定数量的有效位和整个数字签名本身。
为了保证存在处理请求期间生成的RECORD-ROUTE签名，用于被呼叫者SIP节点402生成的响应中的验证，可以把所生成的RECORD-ROUTE签名570作为标题参数或URI参数***到请求的返回标题中。因此，当客户机SIP节点402基于SIP请求的返回标题生成响应时，将所生成的签名自动从请求传送到响应。因此，接收响应的SIP节点可以确认传送到响应标题的签名。要理解，基于现有协议由客户机SIP节点返回的任何返回标题或自定义标题都可适合于存储RECORD-ROUTE签名，用于由SIP节点确认。
如在图4中所示，可以把RECORD-ROUTE签名***到生成签名的SIP节点的RECORD-ROUTE标题中。例如，SIP节点300可以把RECORD-ROUTE签名570作为标题参数***到SIP节点300的RECORD-ROUTE标题524中。如上所述，在响应标题604中返回RECORD-ROUTE标题。因此，当SIP节点402形成响应时，诸如图5中示出的响应600，它可以在标准的SIP处理下把RECORD-ROUTE标题524拷贝到SIP节点200的RECORD-ROUTE标题624中。当返回RECORD-ROUTE标题时，拷贝标准的信息以及包括RECORD-ROUTE签名570的任何标题参数。
为了确认图5的所接收的RECORD-ROUTE签名670，SIP节点300可以剥去和保存所接收的RECORD-ROUTE签名670。SIP节点300可以使用与用于生成***到对应请求(这里是INVITE)中的RECORD-ROUTE签名570的过程相同的过程来生成确认RECORD-ROUTE签名。根据上述RECORD-ROUTE签名570的生成，SIP节点300可以基于SIP节点250的RECORD-ROUTE标题622的URI部分和SIP节点200的RECORD-ROUTE标题620的URI部分生成确认RECORD-ROUTE签名。SIP节点300可以将确认RECORD-ROUTE签名和所接收的RECORD-ROUTE签名670进行比较。如果签名不匹配，则如果协议支持的话，SIP节点300可以发送出错消息，从它的处理栈中移除响应600，和/或递增签名失败性能计数器。如果签名是匹配的，则SIP节点300可以在SIP标准下继续进行正常的处理，并且把响应转发给在响应标题604的VIA标题中指示的下一SIP节点。
在某些情况中，可以在路由上的每一步处，例如，在处理响应的每个SIP节点处，确认响应的RECORD-ROUTE标题。然而，与如上参考VIA签名650的描述相似，为了减少SIP节点的计算负担，只在需要时才确认响应。例如，如果请求不包含任何RECORD-ROUTE标题，则可以不生成RECORD-ROUTE签名。在另外的例子中，如果到下一SIP节点的连接是可信连接，则可以不生成RECORD-ROUTE签名。为了减少通信***的负担，在验证之后并在把响应转发到下一SIP节点之前，SIP节点可以从RECORD-ROUTE标题中移除RECORD-ROUTE签名。
为了基于SIP消息中的至少一部分标题来生成签名，需要确认和验证能力的SIP节点可以包括密码程序，该程序在中央处理单元上执行以执行某些秘码功能，包括加密、解密、签名和/或验证。作为一个例子，密码程序能够生成和消灭密钥，诸如用于计算签名时添加随机数，或用于加密/解密的目的的对称密钥。另一方面，密码程序可以访问非对称(公有/私有)密钥对。在典型的非对称密钥对中，可以使用公钥对信息进行加密，而可以使用对应的私钥对信息进行解密。可以使用私钥来生成数字签名，并且使用公钥来认证该签名。应该理解，任何单向散列机制都可适用于生成基于SIP标题的签名，包括基于许多因素(诸如对于攻击的恢复力，相对速度以及生成相关联签名的计算负担)的单独或组合的MD5、salt、HMAC、SHAI以及RSA。还要理解，可以***整个签名二进制大对象、一部分签名二进制大对象或使用任何编码方案的签名二进制大对象的编码版本，作为VIA、ROUTE SET、和/或RECORD-ROUTE签名。在一个例子中，签名可以是SIP消息标题的所选择部分和任何其它信息(包括随机数和/或会话密钥)的16字节单向MD5散列。可以用按任何特定次序的相关标题来生成基于SIP标题的签名，只要该次序在签名生成和确认之间保持一致。
同一SIP节点处理的VIA签名、ROUTE SET签名和RECORD-ROUTE签名的每一个可以通过相同的会话密钥生成。另一方面，对于每个签名或签名的任何组合，可以使用不同恢复力和速度的密钥。例如，由于一般十分快速地验证VIA签名和/或RECORD-ROUTE签名，例如，在对应的响应中，所以用于生成VIA签名的VIA密钥可以是计算负担十分小的十分轻量级的密钥/密码解决方案。然而，由于ROUTE SET标题可以通过整个对话继续验证，所以ROUTE SET密钥是重量级的密钥/密码解决方案，它比轻量级的密钥/密码解决方案较不易受攻击。
对于由特定的SIP节点在某个时间帧中处理的所有对话请求和/或响应，可以生成和使用用于生成签名的会话密钥本身。另一方面，可以向每个对话发出特定的会话密钥，该密钥可以与该SIP节点使用的其它对话会话密钥相同或不同，并且可以与其它SIP节点使用的对话会话密钥相同或不同。在预定时间段之后、在对话结束处和/或接收到密钥和/或标题损坏的指示时，密码程序可以消灭这些会话密钥。
每个SIP节点可以生成它自己的会话密钥，诸如用于生成VIA签名的VIA密钥、用于生成RECORD-ROUTE标题的ROUTE密钥以及用于生成RECORD-ROUTE签名的RECORD-ROUTE密钥。另一方面，SIP节点的每一个都可以访问会话密钥，诸如通过公钥/私钥对的证书来访问，以致使用相同密钥来签署每种类型的标题。
为了降低用于生成签名的会话密钥的易损坏性，可以不时地刷新密钥。例如，可以每4小时刷新会话密钥。然而，为了保证即使刷新了会话密钥也允许继续进行对话，SIP节点的密码程序可以存储和保持以前的会话密钥。可以把所存储的密钥存储预定的时间长度，诸如对于RECORD-ROUTE和ROUTE SET密钥在约5分钟到约24小时的范围内，而对于VIA密钥在约5分钟到约30分钟的范围内。另外或另一方面，可以保存会话密钥直到已经验证了使用该密钥签署的所有消息。为了保证访问正确的密钥以验证签名，密码程序可以把密钥标识符***到签名中和/或在返回的SIP标题中附上作为另外参数的密钥标识符。
在某些情况中，可以由服务器池来提供处理SIP消息的SIP节点。然而，不保证验证签名的服务器与生成签名的服务器是同一服务器。因此，服务器池中的服务器可能需要传送用于生成签名的密钥，以致如果用在池中的其它服务器处理消息，则这些服务器可以验证这些签名。在一个例子中，服务器可以彼此发送密钥或可以通过证书或其它合适的方法从密钥服务访问适当的密钥。然而，在服务器池中的服务器一般使它们之间的通信最小化来减少通信，并且访问密钥服务可能增加消息处理时间。因此，为了将会话密钥安全地从签名生成服务器传送到签名验证服务器，生成签名的服务器可以把经加密和经签署的会话密钥附在具有签名的消息的返回标题上。
例如，可以通过包括第一服务器300A和第二服务器300B的服务器池来提供SIP节点300，如在图1中的虚线所示。在某些情况中，可以通过SIP节点300A路由请求500，而通过SIP节点300B路由来自被呼叫者的后续的对话内请求700。因此，为了验证对话内请求中的ROUTESET签名760，SIP节点300B需要知道SIP节点300A使用的密钥，以生成ROUTE SET签名560。如在图4中的示例请求RECORD-ROUTE标题所示，RECORD-ROUTE标题，诸如RECORD-ROUTE标题534，可以包括标准SIP处理下的典型网络位置信息，SIP节点300A生成的ROUTE SET签名560以及表示SIP节点300A用来生成签名560的ROUTE SET密钥580的数据。
然而，为了保证其它SIP节点不能访问消息标题中的ROUTE SET密钥580，SIP节点300A可以用公钥对ROUTE SET密钥加密。因此，为了验证该加密的完整性，SIP节点可以用私钥来签署经加密的ROUTESET密钥。然后SIP节点300A可以把经加密和经签署的会话密钥***到返回的标题中，诸如RECORD-ROUTE标题的URI参数，以把安全的会话密钥分发给能够访问用于加密和签署会话密钥的公钥/私钥对的服务器。可以***经加密的会话密钥和经签署的会话密钥作为单个参数或作为多个参数。
在某些情况中，可能要求利用两对公钥/私钥对来保护消息标题中的会话密钥。例如，可以通过证书***来安装或访问第一公钥/私钥对和第二公钥/私钥对。在生成签名的SIP节点处，可以使用第一公钥/私钥对的第一公钥对会话密钥进行加密，并且可以使用第二公钥/私钥对的第二私钥签署会话密钥。如此，能够访问公钥/私钥对两者的接收SIP节点可以使用第二公钥/私钥对的第二公钥来验证签名的有效性，并且可以使用第一公钥/私钥对的第一私钥对会话密钥进行解密。
通过公钥/私钥对加密和签署会话密钥可能有较大计算强度。因此，为了减少SIP节点上的负担，可以把经签署的经加密的会话密钥存储在与经解密的密钥信息、密钥的创建的日期/时间标记、密钥的到期日/时间和或其它信息相关联的密钥数据库中。如此，不需要在每次发送前都计算加密/签名。
例如，如在图6中所示，当SIP节点300B接收具有包含ROUTE SET签名760的RECORD-ROUTE标题724的请求700时，SIP节点300B可以检查ROUTE SET签名以识别使用了哪个ROUTE SET密钥来生成签名560。在某些情况中，SIP节点300B可以访问存储密钥的数据库以验证是否有经识别的ROUTE SET密钥580存储其中。如果没有存储ROUTESET密钥，则SIP节点300B可以访问公钥/私钥对，以从ROUTE SET标题中确定ROUTE SET密钥。更特别地，SIP节点300B可以使用证书服务来访问公钥/私钥对，或可以从数据库或通过任何合适的方法或过程来检索公钥/私钥对。SIP节点300B可以使用公钥来认证会话密钥的签名。SIP节点300B还可以使用私钥对ROUTE SET密钥580解密，然后使用该经解密的会话密钥来生成确认ROUTE SET签名。按相似的方式，可以把用来生成VIA标题和RECORD-ROUTE标题的会话密钥***到返回标题中，尤其，可以***到包含通过该会话密钥生成的签名的返回标题中。
会话密钥可以单独进行加密，或可以在用公钥加密之前使其它信息和会话密钥包括在一起。相似地，可以单独对经加密的会话密钥进行签署，或另一方面，可以把经加密的会话密钥二进制大对象附在其它信息上，这些信息可以在全部用私钥签署之前进行加密或解密。如此，要求诸如密钥标识符、会话密钥到期日或任何其它信息之类的其它信息与经加密的/经签署的会话密钥一起发送。可以把另外的信息附到经加密的/经签署的会话密钥上，并且可以使用同一公钥/私钥对或其它合适的加密过程进行加密和/或签署。
在某些情况中，接收经签署的和经加密的会话密钥的SIP节点可以确认会话密钥的到期时间和/或日期。在这方面，SIP节点300A可以对会话密钥与会话密钥的创建的日期和/或时间标记一起进行加密和签署。当SIP节点300B接收对话内请求时，它可以如上所述地认证和解密会话密钥的签名和日期/时间标记。此外，SIP节点300B可以将会话密钥的日期/时间标记和密钥的预期生命周期或存储的到期日/时间进行比较。如果密钥到期，则如果支持的话，SIP节点300B可以发送出错消息，可以从它的处理栈中移除消息，和/或可以采取任何其它合适的行动。如果丢弃密钥是活动的，则SIP节点300B可以继续使用经解密的密钥来确认消息中对应的签名。
在图1示出的综合性例子中，SIP节点300可以生成VIA签名，并把该签名***到返回的标题中，诸如请求500的VIA标题的标题参数。然后当被呼叫者发送对于该请求的响应600时，可以在SIP节点300处确认VIA签名。相似地，如果请求是对话启动请求，则SIP节点300可以生成RECORD-ROUTE签名，并且把该签名***到返回的标题中，诸如请求500的RECORD-ROUTE标题的标题参数。然后当被呼叫者发送对于对话启动请求的响应600时，可以在SIP节点300处确认RECORD-ROUTE签名。此外，如果请求是对话启动请求，则SIP节点300还可以生成被呼叫者ROUTE SET签名，并且把该签名***到返回的标题中，诸如请求500的RECORD-ROUTE标题的URI参数。被呼叫者SIP节点可以把ROUTE SET签名保存在它处，用作由该对话中的被呼叫者生成的任何未来请求中的ROUTE标题组。因此，要到请求中的被呼叫者使用被呼叫者ROUTE SET签名时才确认它。相似地，在对于对话启动请求的响应中，SIP节点200可以生成呼叫者ROUTE SET签名，并且***该签名作为SIP节点200的RECORD-ROUTE标题的URI参数。可以由呼叫者SIP节点保存呼叫者ROUTE SET签名，用作由呼叫者SIP节点生成的任何请求中的ROUTE标题组。如此，要到呼叫者在请求中发送呼叫者ROUTE SET签名时才对它进行验证。
现在将参考图8-14描述SIP节点服务器的示例实现。
图1中示出的呼叫者SIP节点102、SIP节点200、SIP节点250、SIP节点300和/或被呼叫者SIP节点402的任何组合都可存在，并且可以在作为SIP节点处理器的一台或多台计算机或其它设备上操作。这些节点的每一个可以在多个计算机***或其它设备的全部或一部分上提供，和/或可以使用包括有线连接、无线连接等本技术领域中任何已知方法一起组成网络，以提供上述过程。
在所示的实施例中，SIP节点300由节点服务器1300提供，这将在下面参考图8-14来描述。可以通过相似的服务器/计算机***来提供SIP节点102、SIP节点250、SIP节点200和SIP节点402。
如在图8中所示，节点服务器1300可以包括一个或多个通信端口1302，通信端口1302可以包括一个或多个处理器1304、内部日期和时间时钟1306、以及存储1308，存储1308包括定义指令的一个或多个计算机程序1322，当执行这些指令时，指令计算机执行SIP节点300的操作。存储还可以包括联系图9更详细地描述的密钥数据库1310，而下面将相对于图10-14讨论程序1322。
图9示出密钥数据库1310的示例表格1350，它包括一个或多个记录1352。一般而言，每个记录将会话密钥1354关于该密钥的附加信息相关联。在该例子中，每个记录1352包括密钥标识符1353、会话密钥1354、用公钥加密的经加密的密钥1356、创建的日期/时间1358以及到期日/时间1360。SIP节点300可以生成会话密钥1354；然而，SIP节点可以从消息本身来识别会话密钥，从密钥服务或通过适合于生成用于签署数据的会话密钥的任何方法检索它。相似地，当SIP节点300、消息本身或其它***提供密钥信息时，可以初始化并更新其余的数据。
密钥数据库可以是任何类型的数据库，包括关系型数据库、面向对象数据库、非结构化数据库、存储器内数据库或其它数据库。可以使用诸如ACSII文本、二进制文件、通过通信网络发送的数据之类的平面文件***或任何其它文件***来构造数据库。尽管有上述数据库的这些可能实现，然而此处所使用的术语数据库指的是以计算机可访问的任何方式收集和储存的任何数据。
现在参考图10-14，将描述SIP节点300执行的各种操作。更具体地，参考图10描述VIA签名的生成，参考图11描述VIA签名的验证。参考图12描述RECORD-ROUTE和ROUTE SET签名的生成，参考图13描述这些签名的确认。图14示出在服务器池中将会话密钥从一个服务器导入另一个服务器的操作。
参考图10，生成VIA签名的操作包括，但是不限于，接收(900)SIP请求。虽然参考INVITE请求来讨论上述附图，但是可以根据***的安全性和处理要求对所有请求或选择的请求生成VIA签名。SIP节点可以判定(902)将通过其转发响应的链路是否为不可信链路。如果链路是可信的，则SIP节点可以在SIP标准过程下继续进行请求的标准处理。如果转发链路是不可信的，则操作可以包括顺序地构造(904)除了处理节点的VIA标题之外的所有接收的VIA标题的VIA标题组。特别地，可以检查请求，并可以把所接收消息中存在的VIA标题存储在服务器1300存储器中。如果VIA标题组是空的(906)，则可以继续进行消息的标准处理。如果存在一个以上VIA标题，则操作还包括识别(908)VIA密钥，如上所述，该密钥可以由服务器1300生成、从消息本身访问(下面参考图14进一步描述)、或通过诸如因特网之类的装置从密钥服务中检索。然后可以生成(910)VIA签名，并且可以包括调用密码程序以生成存储在存储器中的VIA标题组的散列。可以生成(912)用于处理SIP节点300的VIA标题，并且可以把VIA签名作为标题参数的***(914)到SIP节点300的VIA标题中。服务器1300可以把VIA会话密钥存储(916)在上面参考图9讨论的密钥数据库中，并且可以对诸如密钥标识符、密钥创建日期/时间、到期日/时间、经加密的密钥和/或其它信息之类的密钥参数进行初始化或更新。
参考图11，在生成请求中的VIA签名之后，SIP节点可以接收(918)答复以前处理的请求的响应。服务器可以检查响应的VIA标题，并且判定(920)是否存在一个以上VIA标题。如果只存在一个VIA标题，则可以继续进行消息的标准处理。如果存在一个以上VIA标题，则SIP节点可以判定(922)该响应是经过可信连接还是不可信连接接收的。如果链路是可信的，则可以继续进行消息的标准处理。如果链路是不可信的，则SIP节点300可以检查SIP节点300的VIA标题，并且判定(924)是否存在签名。如果不存在签名，则SIP节点300可以从它处理栈中丢弃该消息。如果存在签名，则SIP节点300可以从标题中剥去签名，并且把VIA签名保存(926)在存储器中，然后从消息中剥去(928)最上面的VIA标题(例如，SIP节点300的VIA标题)。SIP节点可以从密钥数据库、密钥服务或消息本身检索(930)适当的VIA会话密钥。可以基于出现在签名本身、消息的日期/时间、签名的类型(例如，VIA)或适用于识别适当的VIA会话密钥的任何其它参数中存在的标识符来选择适当的密钥。SIP节点可以生成(932)在响应中存在的其余VIA标题的VIA标题组。如果按消息中给出的次序用VIA标题生成VIA签名，则可以按相同次序生成验证VIA标题，以保证签名参数的正确次序。操作还包括基于VIA标题组和所检索的会话密钥生成(934)VIA确认签名，然后将该确认VIA签名和所存储的VIA签名进行比较(936)。如果VIA签名匹配，则可以继续消息的标准处理。如果VIA签名不匹配，则SIP节点可以从它的处理栈中丢弃消息或采取任何其它合适的行动。
参考图12，生成ROUTE SET和RECORD-ROUTE签名的操作包括在SIP节点处接收(938)消息，并且判定(940)消息是否包含至少一个RECORD-ROUTE标题。如果消息不包含任何RECORD-ROUTE标题，则可以继续进行消息的标准处理。否则，SIP服务器可以判定(944)是否将经过可信或不可信链路发送消息。更具体地，SIP服务器可以判定是否将经过可信或不可信链路接收要确认的消息。如果响应链路是可信的，则可以继续进行标准处理。如果链路是不可信的，则SIP服务器可以判定(946)所接收的消息是否为请求。如果消息不是请求，则SIP服务器可以基于响应中的RECORD-ROUTE标题构造(948)RECORD-ROUTE标题组。如果消息是请求，则SIP服务器可以构造(950)RECORD-ROUTE标题组，并且识别(951)RECORD-ROUTE会话密钥，如上所述，该会话密钥可以由服务器1300生成、从消息本身访问(下面参考图14进一步讨论)、或通过诸如因特网之类的装置从密钥服务检索。然后可以生成(952)RECORD-ROUTE签名，并且可以包括调用密码程序以生成存储在存储器中的RECORD-ROUTE标题组的URI部分的散列。可以把RECORD-ROUTE签名作为标题参数***(954)到SIP节点300的RECORD-ROUTE标题中。服务器1300可以在上面参考图9讨论的密钥数据库中存储(956)RECORD-ROUTE会话密钥，并且可以对诸如密钥标识符、密钥创建日期/时间、到期日/时间和/或经加密的密钥之类的密钥参数进行初始化和/或更新。不管消息是否为请求，SIP服务器可以判定(942)在所接收的消息中是否存在一个CONTACT标题。如果不存在，则可以继续进行标准处理；否则SIP节点可以从RECORD-ROUTE标题组和CONTACT标题构造(958)ROUTE标题组。然后SIP服务器可以识别(960)ROUTE SET组会话密钥，并且使用该密钥可以生成(962)ROUTE SET签名，然后可以把ROUTE SET签名作为URI参数***(962)到SIP节点300的RECORD-ROUTE标题中。SIP节点可以在上述密钥数据库中保存(966)ROUTE SET会话密钥和密钥参数。然后SIP服务器可以继续进行消息的标准处理。
参考图13，当SIP节点接收(968)响应时，可以发生RECORD-ROUTE签名的确认。SIP节点可以判定(970)在消息中是否存在任何RECORD-ROUTE标题。如果没有，则可以继续进行消息的标准处理；否则，SIP节点可以判定(972)是否经过不可信链路接收响应。如果链路是可信的，则可以继续进行消息的标准处理。如果链路是不可信的，则SIP节点可以判定(974)SIP节点的RECORD-ROUTE标题是否包含RECORD-ROUTE签名。如果没有，则可以从SIP节点300的处理栈中丢弃消息。如果存在RECORD-ROUTE签名，则SIP节点服务器可以剥去和保存(976)SIP节点300的RECORD-ROUTE标题中的所有签名。例如，SIP节点300的RECORD-ROUTE标题可以包含RECORD-ROUTE签名和ROUTE SET签名两者。只要它们的位置在整个对话中是一致的，和/或按合适的方式识别签名以区分多个签名，它们中的每一个都可以列出在RECORD-ROUTE URI参数的第一个上。例如，***到具有多个签名的标题中的每个签名可以包括指定标题类型的标识符，和/或每个签名都可以伴随有识别所***的签名的类型的附加参数。SIP节点可以构造(978)包含消息标题中的RECORD-ROUTE标题的URI部分的RECORD-ROUTE标题。SIP节点还可以根据相对于图11的操作930所讨论的过程来检索(980)适当的RECORD-ROUTE会话密钥。SIP节点可以基于RECORD-ROUTE标题组和会话密钥生成(982)确认RECORD-ROUTE签名，然后将确认RECORD-ROUTE签名和所存储的RECORD-ROUTE签名进行比较(984)。如果签名不匹配，SIP节点可以从它的处理栈中丢弃消息。如果签名匹配，则可以继续进行标准处理。如果存在作为RECORD-ROUTE标题的URI参数的ROUTE SET签名，则SIP节点服务器可以把这个签名从消息和/或存储器中删除(986)。更特别地，被呼叫者ROUTE SET签名已由被呼叫者SIP节点保存，因此，在定向到呼叫者的当前消息中不再需要。为了判定是否应该生成呼叫者的新ROUTE SET签名，并且发送给被呼叫者，SIP节点可以判定(987)下一个SIP节点是否通过不可信链路，并且存在至少一个CONTACT标题。如果不是，则可以继续进行消息的标准处理。如果下一个链路是不可信的，则SIP节点服务器可以通过检索(988)ROUTE SET会话密钥(它可以与RECORD-ROUTE密钥为相同的密钥)来生成呼叫者ROUTE SET签名。使用该密钥，SIP节点可以基于RECORD-ROUTE标题组和第一列出CONTACT标题的URI部分来生成(990)ROUTE SET签名。可以把ROUTE SET签名***(922)到要传送到呼叫者SIP节点102的SIP节点300的RECORD-ROUTE标题中。SIP节点可以把ROUTESET会话密钥和/或RECORD ROUTE会话密钥以及密钥参数保存(994)在上述密钥数据库中。然后SIP服务器可以进行消息的标准处理。在后续请求中的被呼叫者ROUTE SET签名和/或呼叫者ROUTE SET签名的确认可以遵循上述相似的过程。
图14示出在服务器池中的服务器之间传送会话密钥的一个示例实施中的操作。例如，如上所述，可以由服务器300A和服务器300B提供SIP节点300。如此，SIP节点300A可以生成具有会话密钥的签名，然后要求SIP节点300B确认该签名。虽然参考ROUTE SET标题描述下列例子，但是可以使用相似的过程对RECORD ROUTE会话密钥和/或VIA会话密钥进行加密、签署和访问。
如在图14中所示，可以生成(996)公钥/私钥对的公共证书，并且安装(998)在服务器池中的每个服务器上(300A、300B)。如上所述，可以使用公钥/私钥对来签署和加密该节点处理的所有会话密钥，或每个类型的会话密钥(VIA、RECORD-ROUTE和/或ROUTE SET)可以具有不同的公钥/私钥对。在操作中，SIP节点300A可以接收(1000)需要被签署的请求。如上所述，SIP节点服务器可以通过生成、访问或检索ROUTE SET会话密钥而识别(1002)它。SIP节点还可以验证(1004)该证书被配置成路由关于密钥交换的信息。SIP服务器可以判定ROUTESET会话密钥的创建日期/时间标记，并且把日期/时间标记附在会话密钥上。SIP服务器可以使用公钥对会话密钥和日期/时间标记进行加密(1008)，并且用私钥签署(1010)结果。可以把经加密和经签署的会话密钥的结果与诸如日期/时间标记、会话密钥、会话密钥标识符等密钥参数一起存储(1012)在上面参考图9描述的密钥数据库中。SIP节点可以使用ROUTE SET会话密钥如上参考图12所述地生成ROUTESET签名，并且生成(1014)SIP节点300的RECORD-ROUTE标题。SIP节点服务器可以把ROUTE SET签名***(1018)到SIP节点的RECORD-ROUTE标题中，并且还可以把经签署和经加密的ROUTE SET会话密钥作为URI参数***(1020)到SIP节点RECORD-ROUTE标题中。
在被呼叫者已经接收到请求之后，它将把RECORD-ROUTE标题和CONTACT标题的URI部分保存在ROUTE标题组中。当被呼叫者SIP节点生成后续的对话内请求时，被呼叫者SIP节点可以包括ROUTE SET标题，该ROUTE SET标题返回包含SIP节点300A生成的ROUTE SET签名和ROUTE SET会话密钥的RECORD-ROUTE和CONTACT标题。第二SIP节点300B可以接收(1022)具有至少一个ROUTE标题的对话内请求。鉴于检索(930)上面参考图12所述的适当的会话密钥，SIP节点可以从ROUTE标题中提取(1024)经签署和经加密的ROUTE SET会话密钥，并且将经签署和经加密的密钥和密钥数据库中的条目进行比较(1026)，以判定服务器节点300B是否能够访问经解密的会话密钥。如果是匹配的，则SIP节点300B可以使用来自密钥数据库的会话密钥确认ROUTE标题中的ROUTE SET签名。如果不匹配，则SIP节点可以提取(1028)密钥签名，并且用公钥验证(1030)密钥签名。如果没有验证签名，则SIP节点可以从它的处理栈中丢弃消息，或采取任何其它合适的行动。如果签名是匹配的，则可以提取(1032)经加密的会话密钥。如果密钥不再活动(例如，到期)，则可以独立于会话密钥对日期/时间标记进行解密(1034)，以使服务器资源最小化。更具体地，在解密以验证日期/时间标记在该类型会话密钥的配置生命周期内之后，SIP节点可以确认(1036)日期/时间标记。如果不能够验证日期/时间标记，则可以从处理栈中丢弃消息。如果验证日期/时间标记，则可以用私钥对会话密钥解密(1038)，然后使用它确认(1040)ROUTE SET签名。可以把经解密的会话密钥的结果与诸如日期/时间标记、经签署和经加密的会话密钥、会话密钥标识符等密钥参数一起存储(1042)在上面参考图9描述的密钥数据库中。在某一时刻，诸如当完成该对话时、不再期望使用该会话密钥的更多的标题时，在会话密钥的活动生命周期的结束处、和/或在它的到期日之后，会话密钥可以到期，可以从数据库中清除(1044)该会话密钥的数据库记录，包括会话密钥、经签署和经加密的会话密钥等。
可以用来独立地或组合地实现图1和/或图8的SIP节点的各个元件的计算机***一般包括连接到输出设备(向用户显示信息)和输入设备(从用户接收信息)两者的至少一个主单元。主单元可以包括经由互连机制连接到存储器***的处理器。还经由互连机制把输入设备和输出设备连接到处理器和存储器***。
图1和/或图8中示出的计算设备一般包括某些形式的计算机可读介质。计算机可读介质可以是SIP服务器中的其它计算设备可以访问的任何可用的介质。作为例子，而不是限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括按任何方法或技术实施的、用于诸如计算机可读出指令、数据结构、程序模块或其它数据之类的信息存储的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括，但是不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)和其它光存储器、盒式磁带、磁带、磁盘存储器或其它磁性存储设备、或可以用来存储所需要的信息并且SIP节点中的计算机***可以访问的任何其它介质。通信介质一般在已调制数据信号(诸如载波或其它传输机制)中包含算机可读指令、数据结构、程序模块或其它数据，，并且包括任何信息传送介质。作为例子，而不是限制，通信介质包括有线介质，诸如有线网或直接的有线连接，以及无线介质，诸如声音、RF、红外和其它无线介质。上述的任何组合也可以包括在计算机可读介质的范围内。
可以把一个或多个输出设备和一个或多个输入设备连接到计算机***。本发明不限于用于计算机***或对于这里所描述的为特定的输入或输出设备。
计算机***可以是可使用计算机编程语言(诸如SmallTalk、C++、Java、Ada或C#(C-sharp))或其它语言(诸如脚本语言，甚至汇编语言)编程的通用计算机***。可以在非编程环境(例如，以HTML、XML或其它格式创建的文件，当在浏览器程序的一个视窗中观看时，呈现图形用户界面的各方面或执行其它功能)中实现本发明的各个方面。本发明的各个方面可以被实现为编程的或非编程的元件或它们的任何组合。计算机***还可以是特别编程的、专用硬件或专用集成电路(ASIC)。阅读器***还可以包括寻呼器、电话、个人数字助理或其它电子数据通信设备。
在通用通信***中，处理器一般是市场上可买到的处理器，诸如可从Intel公司得到的众知的Pentium处理器。许多其它处理器也是可用的。这种处理器通常执行一个操作***，例如，操作***可以是可从Microsoft公司得到的Windows 95、Windows 98、Windows NT、Windows 2000或Windows XP、可从Apple计算机公司得到的MAC OS***X、可从Sun Microsystems得到的Solaris操作***、或从各种来源得到的UMIX。可以使用许多其它操作***。
处理器和操作***一起定义对其以高级编程语言书写应用程序的计算机平台。应该理解，本发明不限于特定的计算机***平台、处理器、操作***或网络。还有，本领域的技术人员应该明白，本发明不限于特定的编程语言或计算机***。此外，应该理解，也可以使用其它适当的编程语言和其它适当的计算机***。
可以在耦合到通信网络的一个或多个计算机***(未示出)上分布计算机***的一个或多个部分。这些计算机***也可以是通用计算机***。例如，可以把本发明的各个方面分布在一个或多个计算机***间，这些计算机***可以被配置成向一个或多个客户机计算机提供服务(例如，服务器)或作为分布式***的一部分执行总任务。例如，可以在客户机-服务器***上执行本发明的各个方面，所述客户机-服务器***包括根据本发明的各个实施例执行各种功能的一个或多个服务器***中分布的组件。这些组件可以是可执行的、中间(例如，IL)或解释(例如，Java)代码，这些代码可以使用通信协议(例如，SIP或TCP/IP)经过通信网络(例如，因特网)进行通信。应该理解，本发明不限于在任何特定***或***组上执行。
现在已经描述了本发明的一些说明性实施例，本领域的技术人员会明白，上述说明只是说明性的而不是限制，只是作为例子而提供。许多修改和其它说明性实施例都在本领域的技术人员的范围内，并且可以设想为落在本发明的范围内。特别地，虽然这里提供的许多例子涉及方法操作或***元件的特定组合，但是应该理解，可以按其它方式组合这些操作和这些元件来实现相同的目的。只联系一个实施例所讨论的操作、元件和特征并不意味着排除在其它实施例中相似作用之外。此外，在权利要求书中使用按顺序的术语(诸如“第一”和“第二”)来修改权利要求元素的本身并不意味着任何优先级、特权或一个权利要求元素对于另一个的次序或执行方法的操作的临时次序，而只是用于作为标号来区分具有某个名称的权利要求元素和具有相同名称的另一个元素(但是使用按顺序的术语)，来区分权利要求元素。

Claims (39)

1.一种处理会话启动协议(SIP)消息的方法，所述方法包括：
(a)在SIP节点处接收SIP请求，所述SIP请求包括消息标题；
(b)基于至少一部分消息标题生成签名；
(c)生成SIP节点标题条目；以及
(d)把签名***到SIP节点标题条目中。
2.如权利要求1所述的方法，其特征在于，所述SIP节点标题条目是返回的标题。
3.如权利要求2所述的方法，其特征在于，所述一部分消息标题包括表示网络路由位置的数据。
4.如权利要求1所述的方法，其特征在于，所述SIP节点标题条目是VIA标题。
5.如权利要求4所述的方法，其特征在于，还包括：
(e)作为对SIP请求的答复，在SIP节点处接收SIP响应，所述SIP响应包括SIP节点的VIA标题，所述VIA标题包括第一接收签名；以及
(f)验证第一接收签名。
6.如权利要求5所述的方法，其特征在于，所述验证包括基于SIP响应的至少一个VIA标题生成验证签名，以及将验证签名和第一接收签名进行比较。
7.如权利要求5所述的方法，其特征在于，还包括：
(g)确定到下一SIP节点的下一链路，以接收SIP请求；以及
(h)判定到下一SIP节点的下一链路是否为不可信链路，其中，生成第一签名包括如果下一链路是不可信链路，则只生成第一签名。
8.如权利要求1所述的方法，其特征在于，所述生成签名包括基于消息标题的至少一个VIA标题生成第一签名。
9.如权利要求8所述的方法，其特征在于，所述生成第一签名是基于消息标题的至少一个VIA标题以及对等FQDN、在下一中继段上将通过其发送消息的连接的连接标识符、消息标题的至少一部分FROM标题、消息标题的至少一部分TO标题、消息标题的至少一部分CALL-ID标题以及消息标题的至少一部分CSeq标题中的至少一个。
10.如权利要求8所述的方法，其特征在于，所述消息标题包括多个VIA标题，并且所述生成第一签名包括基于除了SIP节点的VIA标题之外的多个VIA标题生成第一签名。
11.如权利要求1所述的方法，其特征在于，所述生成签名包括基于消息标题的至少一部分RECORD-ROUTE标题和至少一部分CONTACT标题生成第二签名。
12.如权利要求11所述的方法，其特征在于，所述***签名包括把第二签名作为URI参数***到SIP节点的RECORD-ROUTE标题中。
13.如权利要求11所述的方法，其特征在于，所述生成第二签名包括基于消息标题中除了SIP节点的RECORD-ROUTE标题之外的每个RECORD-ROUTE标题的URI部分以及消息标题中的CONTACT标题的URI部分生成第二签名。
14.如权利要求1所述的方法，其特征在于，还包括：
(j)作为对SIP请求的答复，接收SIP响应，所述SIP响应包括响应标题；
(k)基于响应标题的RECORD-ROUTE标题和CONTACT标题生成第四签名；以及
(l)把第四签名***到响应的SIP节点的RECORD-ROUTE标题中。
15.如权利要求14所述的方法，其特征在于，还包括：在生成第四签名之前从SIP节点标题条目中移除现有的签名。
16.如权利要求14所述的方法，其特征在于，所述***第四签名包括把第四签名作为URI参数***到SIP节点的RECORD-ROUTE标题中。
17.如权利要求14所述的方法，其特征在于，所述生成第四签名包括基于响应中除了SIP节点的RECORD-ROUTE标题之外的每个RECORD-ROUTE标题的URI部分以及CONTACT标题的URI部分生成第四签名。
18.如权利要求14所述的方法，其特征在于，还包括：
(n)确定到下一SIP节点的下一链路，以接收SIP请求；以及
(o)判定到下一SIP节点的下一链路是否为不可信连链路，其中，生成第二签名包括如果下一链路是不可信链路，则只生成第二签名。
19.如权利要求18所述的方法，其特征在于，所述SIP节点在服务器池中，并且所述方法还包括把经加密的会话密钥***到SIP节点的RECORD-ROUTE标题中。
20.如权利要求1所述的方法，其特征在于，还包括；
(p)确定SIP请求的RECORD-ROUTE标题；并且其中，所述生成签名包括基于SIP请求的至少一部分RECORD-ROUTE标题生成第三签名。
21.如权利要求20所述的方法，其特征在于，所述***第三签名包括把第三签名***到SIP节点的RECORD-ROUTE标题中。
22.如权利要求21所述的方法，其特征在于，所述***第三签名包括***第三签名作为SIP节点的RECORD-ROUTE标题的标题参数。
23.如权利要求21所述的方法，其特征在于，还包括：
(s)作为对SIP请求的答复，在SIP节点处接收SIP响应，所述SIP响应包括包含第三接收签名的SIP节点的RECORD-ROUTE标题；以及
(t)验证所述第三签名。
24.如权利要求20所述的方法，其特征在于，还包括：
(q)确定到下一SIP节点的下一链路，以接收SIP请求；以及
(r)判定到下一SIP节点的下一链路是否为不可信链路，其中，所述生成第三签名包括如果下一链路是不可信链路，则只生成第三签名。
25.一种具有用于执行权利要求1所述的步骤的计算机可执行步骤的计算机可读介质。
26.一种计算机可读介质，具有用于执行处理服务器池中的消息的步骤的计算机可执行指令，所述服务器具有被构造和安排成可互换地使用来处理同一对话中的消息的第一服务器和第二服务器，所述步骤包括：
(a)在第一服务器处识别公钥和私钥；
(b)在第一服务器处接收包括第一标题的第一消息；
(c)生成会话密钥；
(d)用私钥对会话密钥加密；
(e)基于经加密的会话密钥，用公钥生成密钥签名；
(f)把密钥签名***到第一标题中。
27.如权利要求26所述的计算机可读介质，其特征在于，还包括：
(g)在第二服务器处识别公钥和私钥；
(h)在第二服务器处接收包括第二标题的第二消息，所述第二标题包括密钥签名；
(i)对密钥签名解密以确定会话密钥。
28.如权利要求27所述的计算机可读介质，其特征在于，还包括：
(j)用会话密钥验证至少一部分第二消息。
29.如权利要求26所述的计算机可读介质，其特征在于，所述第一消息是会话启动协议(SIP)消息。
30.如权利要求26所述的计算机可读介质，其特征在于，所述第一服务器是代理服务器。
31.如权利要求26所述的计算机可读介质，其特征在于，还包括识别包含表示会话密钥的创建日期和时间的数据的时间标记，以及把时间标记附到会话密钥上，其中，对会话密钥加密包括对会话密钥和时间标记加密。
32.一种在其上存储有数据结构的计算机可读介质，所述数据结构表示会话启动协义(SIP)请求，所述数据结构包括：
(a)包括返回标题的多个SIP标题，所述返回标题包括SIP请求的路由中的SIP节点的地址以及表示数字签名的数据，所述数字签名是通过用会话密钥对签署一部分SIP标题而生成的，其中，所述返回标题从包括下列的组中选出：VIA标题、FROM标题、TO标题、RECORD-ROUTE标题、CALL-ID标题和CSeq标题。
33.如权利要求32所述的计算机可读介质，其特征在于，所述多个SIP标题包括多个VIA标题，并且所述数字签名是基于SIP标题中除了列出在顶部的VIA标题的VIA标题之外的所有VIA标题生成的。
34.如权利要求32所述的计算机可读介质，其特征在于，所述多个SIP标题包括用于携带端点SIP节点的地址的CONTACT标题，以及用于携带SIP服务器的地址的RECORD-ROUTE标题，所述数字签名是基于至少一部分RECORD-ROUTE标题生成的。
35.如权利要求34所述的计算机可读介质，其特征在于，所述数字签名是基于RECORD-ROUTE标题的URI部分和CONTACT标题的URI部分生成的。
36.如权利要求32所述的计算机可读出介质，其特征在于，所述数字签名包括基于至少一部分RECORD-ROUTE标题生成的第一签名，以及基于SIP请求的至少一部分RECORD-ROUTE标题和至少一部分CONTACT标题生成的第二签名。
37.一种验证会话启动协议(SIP)的方法，所述方法包括：
(a)在SIP节点处接收SIP响应，所述SIP响应包括消息标题；
(b)识别消息标题中的返回的标题；
(c)从返回的标题中提取接收的签名；
(d)基于至少一部分消息标题生成验证签名；
(e)将验证签名与接收的签名进行比较。
38.如权利要求37所述的方法，其特征在于，所述返回的标题从包括下列的组中选出：VIA标题、FROM标题、TO标题、RECORD-ROUTE标题、CALL-ID标题以及CSeq标题。
39.如权利要求38所述的方法，其特征在于，所述生成验证签名包括基于VIA标题、CONTACT标题、RECORD-ROUTE标题、ROUTE标题、CALL-ID标题以及CSeq标题中之一个的至少一部分生成验证签名。
CN2005100637538A 2004-03-31 2005-03-31 会话启动协议路由标题的签署和确认 Active CN1677978B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/815,232 2004-03-31
US10/815,232 US7535905B2 (en) 2004-03-31 2004-03-31 Signing and validating session initiation protocol routing headers

Publications (2)

Publication Number Publication Date
CN1677978A true CN1677978A (zh) 2005-10-05
CN1677978B CN1677978B (zh) 2010-11-03

Family

ID=34887741

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2005100637538A Active CN1677978B (zh) 2004-03-31 2005-03-31 会话启动协议路由标题的签署和确认

Country Status (10)

Country Link
US (1) US7535905B2 (zh)
EP (1) EP1583318B1 (zh)
JP (1) JP4800651B2 (zh)
KR (1) KR100932834B1 (zh)
CN (1) CN1677978B (zh)
AU (1) AU2005201046B2 (zh)
BR (1) BRPI0501297A (zh)
CA (2) CA2811999C (zh)
MX (1) MXPA05003410A (zh)
RU (1) RU2378773C2 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008040213A1 (fr) * 2006-09-08 2008-04-10 Huawei Technologies Co., Ltd. Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication
CN101911645A (zh) * 2008-01-07 2010-12-08 西门子企业通讯有限责任两合公司 用于验证通信关系的端点之间的密钥信息的方法
CN103891329A (zh) * 2011-10-25 2014-06-25 诺基亚公司 用于保护主机配置消息的方法
CN107566328A (zh) * 2016-06-30 2018-01-09 瞻博网络公司 网络节点的签名的选择性验证
CN108141704A (zh) * 2015-10-30 2018-06-08 微软技术许可有限责任公司 先前网络消息处理器的位置标识

Families Citing this family (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7535905B2 (en) * 2004-03-31 2009-05-19 Microsoft Corporation Signing and validating session initiation protocol routing headers
US7552225B2 (en) * 2004-04-28 2009-06-23 International Business Machines Corporation Enhanced media resource protocol messages
US8024476B2 (en) 2004-05-21 2011-09-20 Microsoft Corporation Efficient message routing when using server pools
EP1825412A1 (en) 2004-10-25 2007-08-29 Rick L. Orsini Secure data parser method and system
US20060143477A1 (en) * 2004-12-27 2006-06-29 Stevens Harden E Iii User identification and data fingerprinting/authentication
US7890634B2 (en) * 2005-03-18 2011-02-15 Microsoft Corporation Scalable session management
JP4770227B2 (ja) * 2005-03-28 2011-09-14 株式会社日立製作所 Ｓｉｐメッセージの暗号化方法，および暗号化ｓｉｐ通信システム
US8059665B2 (en) * 2005-05-10 2011-11-15 Nextel Communications Inc. Systems and methods for providing location information
KR100704678B1 (ko) * 2005-06-10 2007-04-06 한국전자통신연구원 무선 휴대 인터넷 시스템에서의 그룹 트래픽 암호화 키갱신 방법
US8040875B2 (en) * 2005-07-30 2011-10-18 Alcatel Lucent Network support for caller ID verification
WO2007028329A1 (fr) * 2005-09-05 2007-03-15 Huawei Technologies Co., Ltd. Procede de realisation d'operation d'activation de service et terminal utilisateur realisant ledit procede
US20070118750A1 (en) * 2005-10-27 2007-05-24 The Go Daddy Group, Inc. Authenticating a caller initiating a communication session
US20070101144A1 (en) * 2005-10-27 2007-05-03 The Go Daddy Group, Inc. Authenticating a caller initiating a communication session
US8214640B2 (en) * 2005-12-05 2012-07-03 Alcatel Lucent Method of embedding information in implementation defined SIP header fields
US7912207B2 (en) * 2005-12-21 2011-03-22 Avaya Inc. Data messaging during telephony calls
US7630372B1 (en) * 2005-12-30 2009-12-08 At&T Corp. Method and apparatus for providing access and egress uniform resource identifiers for routing
DE102006004202B4 (de) * 2006-01-27 2008-02-14 Nec Europe Ltd. Verfahren zum Schutz von SIP basierten Anwendungen
US9219686B2 (en) * 2006-03-31 2015-12-22 Alcatel Lucent Network load balancing and overload control
US8014299B2 (en) * 2006-05-22 2011-09-06 Alcatel Lucent Method and apparatus for detecting forwarding loops
US9749296B1 (en) * 2006-06-30 2017-08-29 Avaya Inc. Method and apparatus for modifying address information in signaling messages to ensure in-path devices remain in signaling path between endpoints
US8249035B2 (en) * 2006-07-21 2012-08-21 Samsung Electronics Co., Ltd Method and system for enhanced parameter negotiation in EVDO communication systems
JP4541333B2 (ja) * 2006-08-11 2010-09-08 エヌ・ティ・ティ・コミュニケーションズ株式会社 端末装置、システム、方法、及びプログラム
US8644314B2 (en) * 2006-09-07 2014-02-04 Kyocera Corporation Protocol and method of VIA field compression in session initiation protocol signaling for 3G wireless networks
US7796990B2 (en) * 2006-09-14 2010-09-14 Nokia Corporation Method for the routing of multimedia communication related signaling in a communication system
US8547964B2 (en) * 2006-10-31 2013-10-01 Level 3 Communications, Llc Automatic termination path configuration
US8406221B2 (en) * 2006-10-31 2013-03-26 Level 3 Communications, Llc Automatic termination path configuration
KR101269828B1 (ko) * 2006-11-07 2013-06-04 주식회사 케이티 무선통신 서비스를 위한 보안 통화 방법
US9628490B2 (en) * 2006-11-27 2017-04-18 International Business Machines Corporation Trusted contact name validation
EP2482218A3 (en) * 2006-12-05 2012-10-31 Security First Corporation Improved storage backup method using a secure data parser
US8929360B2 (en) 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
CA2571891C (en) * 2006-12-21 2015-11-24 Bce Inc. Device authentication and secure channel management for peer-to-peer initiated communications
US7835723B2 (en) * 2007-02-04 2010-11-16 Bank Of America Corporation Mobile banking
JP4738363B2 (ja) * 2007-02-26 2011-08-03 富士通株式会社 Ｓｉｐサーバ
US8966252B2 (en) * 2007-03-13 2015-02-24 Board Of Trustees Of Michigan State University Private entity authentication for pervasive computing environments
JP2008227917A (ja) * 2007-03-13 2008-09-25 Hitachi Ltd 通信システム及びルータ
US20080309665A1 (en) * 2007-06-13 2008-12-18 3D Systems, Inc., A California Corporation Distributed rapid prototyping
US20090003582A1 (en) * 2007-06-27 2009-01-01 Microsoft Corporation Optimized Replacement of Calls Using A Grid Parameter
US20090003218A1 (en) * 2007-06-28 2009-01-01 Wen-Pin Lin Wireless communication system performance updates using automated database management
US7591013B2 (en) * 2007-07-31 2009-09-15 Cisco Technology, Inc. System and method for client initiated authentication in a session initiation protocol environment
DE102007043892A1 (de) * 2007-09-14 2009-03-19 Eads Deutschland Gmbh Verfahren zur Übermittlung einer elektronischen Nachricht in einem Transportnetzwerk
KR101412800B1 (ko) * 2007-09-17 2014-06-30 삼성전자주식회사 통신 시스템에서 암호 통신 방법 및 장치
US20090113077A1 (en) * 2007-10-26 2009-04-30 Torbjorn Dahlen Service discovery associated with real time composition of services
WO2009068115A1 (en) * 2007-11-30 2009-06-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods for secure sip signalling to a destination ip address being a cryptographi cally generated address (cga)
EP2232820B1 (en) * 2007-12-13 2018-04-04 Nokia Technologies Oy Location tagging method for packet based signalling
US20090187978A1 (en) * 2008-01-18 2009-07-23 Yahoo! Inc. Security and authentications in peer-to-peer networks
CN104283880A (zh) * 2008-02-22 2015-01-14 安全第一公司 安全工作组管理和通信的***和方法
PL2250784T3 (pl) * 2008-03-04 2014-02-28 Ericsson Telefon Ab L M Delegacja adresu IP
WO2010014997A2 (en) * 2008-08-01 2010-02-04 Tekelec Methods, systems, and computer readable media for session initiation protocol (sip) dialog identification
US20100049784A1 (en) * 2008-08-21 2010-02-25 Ashish Khandelwal System and method for web-based access relative to a document processing device
US8990569B2 (en) * 2008-12-03 2015-03-24 Verizon Patent And Licensing Inc. Secure communication session setup
CN102484580A (zh) * 2009-05-28 2012-05-30 Kovio股份有限公司 用于校验来自无线装置的代码的方法和***
US9843650B2 (en) * 2009-09-03 2017-12-12 Avaya Inc. Intelligent module sequencing
FR2949934B1 (fr) * 2009-09-09 2011-10-28 Qosmos Surveillance d'une session de communication comportant plusieurs flux sur un reseau de donnees
US8745372B2 (en) 2009-11-25 2014-06-03 Security First Corp. Systems and methods for securing data in motion
JP5159752B2 (ja) * 2009-12-03 2013-03-13 セイコープレシジョン株式会社 通信データの検証装置及びそのコンピュータプログラム
IT1397439B1 (it) * 2009-12-30 2013-01-10 St Microelectronics Srl Procedimento e dispositivi per la distribuzione di contenuti mediali e relativo prodotto informatico
WO2011123699A2 (en) 2010-03-31 2011-10-06 Orsini Rick L Systems and methods for securing data in motion
EP2577936A2 (en) 2010-05-28 2013-04-10 Lawrence A. Laurich Accelerator system for use with secure data storage
CN103609059B (zh) 2010-09-20 2016-08-17 安全第一公司 用于安全数据共享的***和方法
US8843915B2 (en) * 2011-07-28 2014-09-23 Hewlett-Packard Development Company, L.P. Signature-based update management
US9582656B2 (en) * 2011-09-12 2017-02-28 Microsoft Corporation Systems for validating hardware devices
CN102739673B (zh) * 2012-06-28 2018-06-22 中兴通讯股份有限公司 会话启动协议对话定位方法及装置
GB2512267B (en) * 2012-10-30 2015-09-16 Openwave Mobility Inc Determination of information relating to messages
US9154540B2 (en) * 2012-12-11 2015-10-06 Microsoft Technology Licensing, Llc Smart redirection and loop detection mechanism for live upgrade large-scale web clusters
US9961109B2 (en) 2013-03-14 2018-05-01 Comcast Cable Communications, Llc Communication policy frame
EP2974223A2 (en) 2013-03-15 2016-01-20 Assa Abloy AB Digital credential with embedded authentication instructions
US9467425B2 (en) * 2013-03-18 2016-10-11 Intel Corporation Key refresh between trusted units
US20150172324A1 (en) * 2013-12-13 2015-06-18 Alcatel-Lucent Usa Inc. Authorized SIP Redirection
US10489757B2 (en) * 2014-05-19 2019-11-26 OX Labs Inc. System and method for rendering virtual currency related services
US10715436B2 (en) 2014-05-28 2020-07-14 Comcast Cable Communications, Llc Dynamic loop detection and suppression
US9565147B2 (en) 2014-06-30 2017-02-07 Go Daddy Operating Company, LLC System and methods for multiple email services having a common domain
US9749886B1 (en) * 2015-02-16 2017-08-29 Amazon Technologies, Inc. System for determining metrics of voice communications
RU2576488C1 (ru) * 2015-02-17 2016-03-10 Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Нижегородский государственный технический университет им. Р.Е. Алексеева" (НГТУ) СПОСОБ ПОСТРОЕНИЯ СЕТЕЙ ПЕРЕДАЧИ ДАННЫХ С ПОВЫШЕННЫМ УРОВНЕМ ЗАЩИТЫ ОТ DDоS-АТАК
WO2016165083A1 (zh) * 2015-04-15 2016-10-20 华为技术有限公司 一种局域网内消息发送方法、局域网网关和可穿戴设备
US9819703B2 (en) 2015-09-23 2017-11-14 T-Mobile Usa, Inc. SIP server with multiple identifiers
US10277597B2 (en) 2015-11-09 2019-04-30 Silvercar, Inc. Vehicle access systems and methods
US10541900B2 (en) * 2016-02-01 2020-01-21 Arista Networks, Inc. Hierarchical time stamping
CA3016887A1 (en) * 2016-03-07 2017-09-14 Level 3 Communications, Llc Systems and methods for dynamically connecting network elements to enable a service
US11025428B2 (en) 2016-05-05 2021-06-01 Neustar, Inc. Systems and methods for enabling trusted communications between controllers
US11277439B2 (en) * 2016-05-05 2022-03-15 Neustar, Inc. Systems and methods for mitigating and/or preventing distributed denial-of-service attacks
US10958725B2 (en) 2016-05-05 2021-03-23 Neustar, Inc. Systems and methods for distributing partial data to subnetworks
US11108562B2 (en) 2016-05-05 2021-08-31 Neustar, Inc. Systems and methods for verifying a route taken by a communication
US9992679B1 (en) * 2016-08-25 2018-06-05 Sprint Communications Company L.P. Integrated authentication codes for user devices and communication networks
US10432595B2 (en) * 2017-03-08 2019-10-01 Bank Of America Corporation Secure session creation system utililizing multiple keys
US10374808B2 (en) 2017-03-08 2019-08-06 Bank Of America Corporation Verification system for creating a secure link
US10425417B2 (en) 2017-03-08 2019-09-24 Bank Of America Corporation Certificate system for verifying authorized and unauthorized secure sessions
US10361852B2 (en) 2017-03-08 2019-07-23 Bank Of America Corporation Secure verification system
ES2964955T3 (es) * 2017-05-09 2024-04-10 Network Next Inc Métodos de intercambio de paquetes bidireccional a través de vías nodales
US10554753B2 (en) * 2017-07-06 2020-02-04 Acronis International Gmbh System and method for service level agreement based data storage and verification
US11018872B2 (en) * 2018-07-17 2021-05-25 Verizon Patent And Licensing Inc. Validating and securing caller identification to prevent identity spoofing
US10811018B2 (en) * 2018-12-04 2020-10-20 Saudi Arabian Oil Company System and method for using a unidirectional watermark for information leak identification
US11269976B2 (en) 2019-03-20 2022-03-08 Saudi Arabian Oil Company Apparatus and method for watermarking a call signal
US11133938B2 (en) * 2019-04-17 2021-09-28 Verizon Patent And Licensing Inc. Validating and securing caller identification to prevent identity spoofing
GB2586785A (en) * 2019-08-30 2021-03-10 Mobilise Consulting Ltd Authentication
CN110572640A (zh) * 2019-09-30 2019-12-13 公安部第一研究所 一种基于gb35114标准的视频签名验签测评工具及方法
FR3105677A1 (fr) * 2019-12-20 2021-06-25 Orange Procédé d’acheminement de messages, équipement réseau associé
US11159497B2 (en) * 2020-01-29 2021-10-26 Citrix Systems, Inc. Secure message passing using semi-trusted intermediaries
US11777912B2 (en) * 2020-05-27 2023-10-03 Step Software Inc. Systems and methods for data communications
US20220166751A1 (en) * 2020-11-20 2022-05-26 Charter Communications Operating, Llc Phone call endpoint security

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5349642A (en) * 1992-11-03 1994-09-20 Novell, Inc. Method and apparatus for authentication of client server communication
US6275937B1 (en) * 1997-11-06 2001-08-14 International Business Machines Corporation Collaborative server processing of content and meta-information with application to virus checking in a server network
US6389532B1 (en) * 1998-04-20 2002-05-14 Sun Microsystems, Inc. Method and apparatus for using digital signatures to filter packets in a network
US6567915B1 (en) * 1998-10-23 2003-05-20 Microsoft Corporation Integrated circuit card with identity authentication table and authorization tables defining access rights based on Boolean expressions of authenticated identities
NO308019B1 (no) * 1998-11-27 2000-07-03 Ericsson Telefon Ab L M FremgangsmÕte for Õ utvide bruken av SIP (Session Initiation Protocol)
US6553422B1 (en) * 1999-04-26 2003-04-22 Hewlett-Packard Development Co., L.P. Reverse HTTP connections for device management outside a firewall
US6584567B1 (en) * 1999-06-30 2003-06-24 International Business Machines Corporation Dynamic connection to multiple origin servers in a transcoding proxy
US6434143B1 (en) * 1999-11-08 2002-08-13 Mci Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US8743892B2 (en) * 1999-11-08 2014-06-03 Verizon Business Global Llc Method and system for dynamic gateway selection in an IP telephony network
JP2002051248A (ja) * 2000-08-01 2002-02-15 Hitachi Ltd カメラ及び画像送信方法及び画像送受信方法
US6865681B2 (en) * 2000-12-29 2005-03-08 Nokia Mobile Phones Ltd. VoIP terminal security module, SIP stack with security manager, system and security methods
US6985958B2 (en) * 2001-03-14 2006-01-10 Microsoft Corporation Messaging infrastructure for identity-centric data access
US7284271B2 (en) * 2001-03-14 2007-10-16 Microsoft Corporation Authorizing a requesting entity to operate upon data structures
US20020141404A1 (en) * 2001-04-03 2002-10-03 Michael Wengrovitz Call routing using information in session initiation protocol messages
US7676430B2 (en) * 2001-05-09 2010-03-09 Lenovo (Singapore) Ptd. Ltd. System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset
US20020178240A1 (en) * 2001-05-24 2002-11-28 International Business Machines Corporation System and method for selectively confirming digital certificates in a virtual private network
US7243370B2 (en) * 2001-06-14 2007-07-10 Microsoft Corporation Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication
US7010727B1 (en) * 2001-06-15 2006-03-07 Nortel Networks Limited Method and system for negotiating compression techniques to be utilized in packet data communications
US20030009570A1 (en) * 2001-07-03 2003-01-09 International Business Machines Corporation Method and apparatus for segmented peer-to-peer computing
US20030084331A1 (en) * 2001-10-26 2003-05-01 Microsoft Corporation Method for providing user authentication/authorization and distributed firewall utilizing same
US7343490B2 (en) * 2001-11-30 2008-03-11 Nokia Siemens Networks Oy Apparatus, and associated method, for facilitating authentication of a mobile station with a core network
EP1452000A2 (en) * 2001-12-07 2004-09-01 Telefonaktiebolaget LM Ericsson (publ) Lawful interception of end-to-end encrypted data traffic
JP4349766B2 (ja) * 2001-12-07 2009-10-21 株式会社日立製作所 アドレス変換装置
KR100426306B1 (ko) * 2001-12-11 2004-04-08 한국전자통신연구원 인트라 도메인내에서의 ｓｉｐ 서버간 로드 분산 처리 방법
US7509425B1 (en) * 2002-01-15 2009-03-24 Dynamicsoft, Inc. Establishing and modifying network signaling protocols
CN100530026C (zh) * 2002-01-18 2009-08-19 艾利森电话股份有限公司 移动终端，把数据装入或上载到移动终端的方法和***
US7240366B2 (en) * 2002-05-17 2007-07-03 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US20040043756A1 (en) * 2002-09-03 2004-03-04 Tao Haukka Method and system for authentication in IP multimedia core network system (IMS)
US7406709B2 (en) * 2002-09-09 2008-07-29 Audiocodes, Inc. Apparatus and method for allowing peer-to-peer network traffic across enterprise firewalls
KR100472952B1 (ko) * 2002-10-30 2005-03-10 한국전자통신연구원 세션 초기화 프로토콜（ｓｉｐ）기반의 부하 분산장치 및방법
JP4338993B2 (ja) * 2003-02-28 2009-10-07 モトローラ・インコーポレイテッド 無線端末のセッション制御方法及びインターフェース設定方法
US7412521B2 (en) * 2003-03-12 2008-08-12 Microsoft Corporation End-point identifiers in SIP
US7421732B2 (en) * 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US6963635B1 (en) * 2003-05-06 2005-11-08 Sprint Spectrum L.P. Method and system for facilitating collection of subscriber past due balance
JP2004364141A (ja) * 2003-06-06 2004-12-24 Hitachi Communication Technologies Ltd Ｉｐアドレス変換装置およびパケット転送装置
US7142537B2 (en) * 2003-12-18 2006-11-28 Motorola, Inc. Interface call signaling protocol
US7535905B2 (en) * 2004-03-31 2009-05-19 Microsoft Corporation Signing and validating session initiation protocol routing headers
US8024476B2 (en) * 2004-05-21 2011-09-20 Microsoft Corporation Efficient message routing when using server pools
FR2902590B1 (fr) * 2006-06-16 2008-08-01 Alcatel Sa Detection de boucles au sein d'un element intermediaire de signalisation sip

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008040213A1 (fr) * 2006-09-08 2008-04-10 Huawei Technologies Co., Ltd. Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication
US9621353B2 (en) 2008-01-07 2017-04-11 Unify Gmbh & Co. Kg Method for authenticating key information between terminals of a communication link
CN101911645A (zh) * 2008-01-07 2010-12-08 西门子企业通讯有限责任两合公司 用于验证通信关系的端点之间的密钥信息的方法
US8745400B2 (en) 2008-01-07 2014-06-03 Siemens Enterprise Communications Gmbh & Co. Kg Method for authenticating key information between terminals of a communication link
US10701113B2 (en) 2011-10-25 2020-06-30 Nokia Technologies Oy Method for securing host configuration messages
CN103891329B (zh) * 2011-10-25 2017-11-28 诺基亚技术有限公司 用于保护主机配置消息的方法
CN103891329A (zh) * 2011-10-25 2014-06-25 诺基亚公司 用于保护主机配置消息的方法
CN108141704A (zh) * 2015-10-30 2018-06-08 微软技术许可有限责任公司 先前网络消息处理器的位置标识
CN108141704B (zh) * 2015-10-30 2021-01-15 微软技术许可有限责任公司 先前网络消息处理器的位置标识
CN107566328A (zh) * 2016-06-30 2018-01-09 瞻博网络公司 网络节点的签名的选择性验证
US10645095B2 (en) 2016-06-30 2020-05-05 Juniper Networks, Inc. Selective verification of signatures by network nodes
CN107566328B (zh) * 2016-06-30 2020-10-30 瞻博网络公司 一种网络节点的签名的选择性验证方法
CN112087457A (zh) * 2016-06-30 2020-12-15 瞻博网络公司 一种网络节点的签名的选择性验证方法
CN112087457B (zh) * 2016-06-30 2022-03-18 瞻博网络公司 用于处理消息的方法、网络节点和介质

Also Published As

Publication number Publication date
AU2005201046A1 (en) 2005-10-20
EP1583318B1 (en) 2012-10-10
BRPI0501297A (pt) 2005-11-08
EP1583318A3 (en) 2006-01-18
CA2811999C (en) 2016-02-02
CA2503289A1 (en) 2005-09-30
RU2005109222A (ru) 2006-10-10
EP1583318A2 (en) 2005-10-05
RU2378773C2 (ru) 2010-01-10
CN1677978B (zh) 2010-11-03
KR100932834B1 (ko) 2009-12-21
AU2005201046B2 (en) 2009-11-26
MXPA05003410A (es) 2005-10-05
US20050220095A1 (en) 2005-10-06
JP2005312026A (ja) 2005-11-04
CA2811999A1 (en) 2005-09-30
KR20060045393A (ko) 2006-05-17
CA2503289C (en) 2014-12-16
US7535905B2 (en) 2009-05-19
JP4800651B2 (ja) 2011-10-26

Similar Documents

Publication Publication Date Title
CN1677978A (zh) 会话启动协议路由标题的签署和确认
US7650383B2 (en) Electronic message system with federation of trusted senders
EP3913854B1 (en) Methods and systems for pki-based authentication
US8196186B2 (en) Security architecture for peer-to-peer storage system
CN1767507B (zh) 用于确认入站消息的方法和***
US8856525B2 (en) Authentication of email servers and personal computers
US11496319B2 (en) Method of identity authentication for voice over internet protocol call and related device
CN112711759A (zh) 一种防重放攻击漏洞安全防护的方法及***
CN1864384A (zh) 用于保护网络管理帧的***和方法
US10579809B2 (en) National identification number based authentication and content delivery
US8085937B1 (en) System and method for securing calls between endpoints
JP2007318806A (ja) 移動ネットワーク環境におけるデータトラフィックの保護方法
US20090113063A1 (en) Authentication method and apparatus for integrating ticket-granting service into session initiation protocol
KR20210126319A (ko) 키 관리 장치 및 방법
WO2005094264A2 (en) Method and apparatus for authenticating entities by non-registered users
NL2021222B1 (en) Method for secure encrypted digital services
Fett et al. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
Breuch Web Key Directory and other key exchange methods for OpenPGP
KR20080075270A (ko) ＶｏＩＰ 스팸 차단을 위한 프락시 서버와 ＵＡＳ간 발신자인증 기법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: MICROSOFT TECHNOLOGY LICENSING LLC

Free format text: FORMER OWNER: MICROSOFT CORP.

Effective date: 20150507

C41 Transfer of patent application or patent right or utility model
TR01 Transfer of patent right

Effective date of registration: 20150507

Address after: Washington State

Patentee after: Micro soft technique license Co., Ltd

Address before: Washington State

Patentee before: Microsoft Corp.